For me, the hardest part of moving from a waterfall to an Agile environment has been “What are they doing there?” factor.
In a waterfall environment, I received requirements documents that I translated into technical documentation, which in turn translated into time estimates. There were meetings. Many meetings. Everyone signed everything after reviewing the documentation. Only after that process, which sometimes took months, did we start to code something. After the code was written, it was reviewed and then sent to a QA division for testing. I remember this process taking over 6 months on more than one occasion before a single line of code was written.
In Agile, most of that is done in a span of about ten business days. That period is called a Sprint.
Design work is largely done during an all-day Sprint Planning session on the first day of the Sprint. The customer drives the product through Sprint Reviews ten days later, where he has the opportunity to use the software that works and tell him if he did it right. Nothing is presented to the customer until he meets the Sprint Teams Definition of Done; No smoking or mirrors. Documentation is still important, but the emphasis is very much on functional software.
All the requirements documentation, tech specs, code reviews, testing, and high performance mean absolutely nothing if your code isn’t what the customer wants. Consequently, the Agile team works directly with the client in two-week increments to help ensure they are programming something with a high ROI.
So. I said all that to write about the “leap of faith” in the title post.
There is a pride of ownership that develops in an Agile team that I have never seen form between people in a waterfall environment. I’ve worked with many, many talented developers who take a lot of pride in what they’re working on (and have some of the best ideas I’ve ever seen), but they might be working alongside someone who doesn’t care. -and in the end both suffer the consequences in relation to the performance of the product in the market.
In Agile, all members of a team are responsible for the code that the team produces and displays. The trick is to take that leap of faith and let the team solve the problems themselves and help foster pride of ownership. How? Don’t direct the team to solve a problem in a particular way because you become the person to blame when your way causes the project to fail. Conversely, if the project is successful, the team cannot take credit for solving a problem because you told them how to do it. You lose either way. You have to learn not to worry so much about how they’re doing something, just because the team is producing working software at a volume that you, and more importantly, the customer, are happy with.
All agile teams will do things in a different way. Sure, everyone will follow the basic rules: standups, storyboards, sprint reviews, etc. but each team will develop its own culture; what works for one team won’t work for all.
Give the team the tools they need to get the job done and get out of the way.
