Business Analysts have to stick around now...

Karmark96 is a budding business analyst in a company starting to borrow practices from Agile. He was surprised that his new role follows the product life past definition and through testing and support.

I explained how this was true while at Siemens after going agile also. My nugget:
"Before we went agile, the BA would write documents and then dump it on the dev and test teams to deliver and fix. In this scenario, a lot of flaws were found in the requirements and the BA could be long gone onto the next project. Agile was about removing this waterfall and bringing these timelines together."

Learn Agile by yourself...

Can it be done? Jon Strickler started the debate. I'm hoping to take the topic to Agile 2008 and see what other people think.

I believe it is a lot easier to learn agile with a coach or someone who has experienced it. It's so easy to get it wrong by following the practices without achieving or understanding the principles or values. But the real question is, can it be done without help?

Many people reply that someone figured it out the first time and they were alone. But I disagree. How many people signed the manifesto? Hasn't the community been about raising new ideas and challenging each other? Don't we grow the community through evolution and collaboration instead of education?

What do you think? I'm turning comments off on this one so you are forced to add to our debate on Jon's blog.

Trust is the core of it...

Agile Tools put up a great post about the degrading relationships on a team when manager/leaders don't trust the team. Estimates are sandbagged, scope is padded, deadlines are moved around, all sorts of games are played to compensate.

Wouldn't it be much simpler to work on the trust issues and move forward. I agree with the author that mistrust is as much your problem as it is theirs. Someone has to extend trust first to build a good relationship.

If you want to be entertained, then click through to the post and read my short play (in the comments) describing my interaction with a Product Owner who had ridiculous ideas about how to game the system rather than overcome the trust and commitment issues.

Must Agile PM's be technical?

So... I ran across a post that implied to some level that Agile projects need a technically inclined person to be running them. simplicity12345678 even pointed to a recent experience where the PM was the issue.

I struggle with this a little bit. I understand the added value that my technical education and experiences provide me while working on software projects, but to imply it is a requirement?

Now, I don't know how strongly this post meant to convey this opinion. There's a wide scale between advantageous, desired, and required.

Some of the best project managers I've ever worked with jumped into a failing project and saved it in a short time without understanding the domain or the technology. They simply relied on the people on the team to provide the right information and worked on the real project issues which typically revolve around people, politics, or culture issues.

Maybe I don't have an answer or opinion on this, I'm just pushing back if the belief is that a agile project manager MUST be technically-savvy.

The team contract...

Jon Strickler triggered a great discussion about team charters and the items a team needs to be successful from the start. He focused on things like the why, what, who, and when questions.

I had to contribute a few Agile specific items to the list. I feel it is important that the team not only have a charter that governs it from above, but also a contract that governs it from within. For example:
"How will they handle failed tests or failed builds? Are they committed to pair programming or TDD? Are customer demo’s done at sprint review or throughout the iteration? Do standing meetings start on time or when everyone is present? Without these agreements, the team won’t be in sync with one another."

How to handle interruptions...

There is a great discussion about how to handle interruptions on InfoQ. In many environments, teams have to not only build a product, but also support that product's existing customer base. Fires arise all the time that diminish productivity and velocity for the team. How can this be handled?

Suggestions included:

• separate backlogs
• emergencies (work stops)
• manage support like features
• sacrifice someone

Having seen Alistair's presentation at Agile 2007, this was one of the points I wanted to add to in the discussion. The "sacrifice one" idea is described properly in the post as: "assign one person dedicatedly to take care of that interruption. Though, this one person would feel sacrificed, rest of the team can make progress by working on the primary task."

My thoughts:
"As for Alistair's idea to sacrifice one team member, I do believe he supports that this is a rotating role (per iteration or sub-time window)... and that it is important to assign your most important person first to make it clear that it is an important role and is not dumped on the newer/weaker people in the team. Otherwise, it can become something that breaks the team dynamics into a group of superstars (those that create) and pledges (those that support)."

The Boundaries of a Sprint...

How do non-developers get involved in the iteration rhythm? How does a business or UI person have all the answers on the first day of the sprint when developers need them? This is a great problem and people learning scrum seem to evolve through different levels over time.

This was the point to Karl Scotland's MMF post, and he did a great job of modeling it for easy digestion.

I commented on the sprint boundaries in general and my experiences through this process in other teams and how it was predicted by our agile coaches at the time.