I finally bottled that smoked porter homebrew last night. That's going to be good.

As I bottled that beer, I was thinking through the Agile methodology information I have read recently. While I have been familiar with Agile for some time, I haven't really been in a situation where I needed to utilize it, or implement it in depth. However, that time has come with some changes at a client site. They want more maturity in their development, fewer defects, more predictable timelines - you've heard the story 1000 times.

First question - why is it so difficult to get development done right when we all know the answers to better development? While I think it has something to do with developer motivation, I think it is primarily a management issue. In organizations where the management is unwilling to trust development, and to work closely with them on a "methodology" that seems like just another "latest thing", a framework like Agile cannot take hold. Old fashioned results orientation around artifacts and PM tasks that development doesn't really want to invest in are still demanded by management. Furthermore, there is no tolerance for learning curve time to implement the changes. Half-hearted or non-existent mangement investment leads to a failure of implementation in the development department. This leads management to declare victory on it being a useless methodology change, and then to cry again about results.

So, I guess my first answer to my first question is that "WE" all know how development should be done, but not everyone in the organization agrees with us.

The second answer might be that we don't actually know how to do it, or agree on what's best. In my experience, the ability to gain understanding of a potential implementation is limited by undertstanding of the scope of the development effort, and what pieces of the latest methodologies will be used, and to what depth. Are we trying to be CMMI level 5, level 1, or nowhere near it? How much can we expect our PMs and Business Owners to engage in scenario definitions? What will the resulting documents look like? So, even as developers we tend to mill around trying to answer management's questions and needs, along with how it will work for us. Often the effort ends here, or again becomes half-hearted.

Basically, these issues cause me to want to find a way to ease into this methodology change. I can see the Agile paradigm being broken into two methodology sections - management methodologies (both team and project) and development. Development methodologies might include things like TDD, SCRUM, and pairing. Management methodologies include managing special cause variations and the related tracking, velocity tracking, sprial workplans, etc. In discussing this with a friend from the client in question, he had a good idea on how to work with this as it relates to managemnt - treat the output to management as an interface. Give them the same old stuff based on information we gather however we want at the development team level. This is sound I think, and even matches some of what I was reading from David Anderson about meeting CMMI requirements with MSF Agile.

In any event, the question then becomes "What are the essentials to getting started with an Agile development team?". Can we do SCRUM without stakeholder buyin? No. Can we do TDD without management buyin? Maybe. Can we track velocity without changing the project tracking software management just purchased? Maybe. The answers to the 'maybe' questions becomes, "What does development control as a department" and "How high up in Development can we get buy in". I think in this situation development controls all PM activities, and we can get buy in all the way up. That means we can define tasks in terms of scenarios, we can estimate timelines for management while not tracking our own progress this way. Maybe along the way we will even be able to give them better information, and so win them over. But we'll hold that goal patiently. For now, we also control development methodology, so we can being with TDD and pairing. A few buyin issues do exists here however; it takes time to build test harnesses, and changes must be made to the physical space to facilitate pairing - perhaps even common development machines purchased.

Well, we are going to try. I can't say the team is optimistic yet about their chances. Management has crushed the spirit a bit. Hopefully, I can keep you posted on the progress, and not the failure of this initiative.