I left my job as a programmer in 2005 to become a business analyst. I did this for the simple reason that, in my company at the time, the only way to improve the requirements for the software I was creating was to write them. I took naturally to the job of business analysis. I consider business analysis to be searching for and finding problems through conversations with clients and other research methods, then setting about laying out what is needed to solve those problems. This is, essentially, how I became Agile.
After doing business analysis within the Waterfall process for a couple of years, I noticed recurring problems. I was writing large business requirement documents either by myself or after reconciling the work of other business analysts and putting together a holistic requirements document. But, people don’t like reading large documents. No matter how much effort I put into making the documents shorter, they were still too long for busy people to read thoroughly.
There were many other problems that I noticed. I realized I could and should determine how to test the software while I was writing the requirements, but the process we were following put that work towards the end and entirely in someone else’s hands. When requirements changed while I was documenting them, it was a pain to update the many sections of the document that needed it. But, once I was done documenting the requirements, it became even harder for the team to accept changes. The risk and expense of accepting a change increased as the project progressed. Another problem, and perhaps the most significant, was that the Waterfall process relies on one step building off the preceding step. Since the steps don’t involve real software until the end, translation errors creep in all over the place much like a game of telephone.
These problems found me. I just had to find ways to solve them. I began a project to analyze our software development lifecycle. I took measurements everywhere that I could. Point blank; our overall cycle time was atrocious. We were not responsive to the needs of our customers. It was during this research that I found Agile. I led that team into a transition to Agile development. And I’ve led other teams through the transition since then. It’s through these experiences that my career has curved towards that of an Agile coach.
Agile solves all of the problems I noticed with Waterfall. And common practices of Agile teams also solve problems that I now see in retrospect. Large business requirements are replaced with small, self-contained, vertical slices of fried gold typically written as user stories that the user (And anyone else!) can see the value in. Because they’re small and mostly independent it is much easier to accept change. Rewrite, throw out, or split anything that hasn’t been worked on yet. Iterate on things that have been worked on until they’re good. Learn about the problem as you’re solving it and apply that learning back into your list of to-dos by rewriting pieces of it or reshaping it–a practice often called backlog grooming.
User stories also take care of that testing problem I mentioned. Instead of figuring that out towards the bottom of the waterfall, knowing how you’ll test each piece becomes a part of the analysis to understand the goal and is written down so that everyone on the team knows what needs to be done and what needs to be tested.
Getting rid of all of those cascading documents, writing down just enough for the team to accomplish their goals, and increasing team communication means that you’re much less likely to have misunderstandings and bad translations. The longer I’m involved in software development, the more I believe that reducing the chances for misinterpretations, catching, and correcting them quickly are the most important things you can do.
With Waterfall, change is risky. The farther you get into the process, the riskier it becomes to accept change. That’s why there are change control processes. In reality, not changing is risky. Just ask BlackBerry. The good news is that Agile teams can respond to change swiftly, without disruption, in a sustainable manner. Once an Agile team has built their first few increments of software, risk drops and is essentially flat for the rest of the time. Delivering work in smaller pieces, over shorter timeframes, all the while testing the results are why well performing Agile teams don’t experience escalating risk.
Another problem that common Agile techniques can help address is the fact that all estimates are bad. People just aren’t that good at estimating how long something will take. But, we can get better at it when we’re estimating something by comparing it to something we did in the past. Estimating with abstract story points makes the best out of this. Teams typically use a scale that has an increasing spread between numbers in the set. The Fibonacci sequence is a popular choice. This ever larger spread between numbers represents the increasing uncertainty in estimates for larger efforts. Once user stories have points assigned to them relative to previous work, and once the team has completed stories within a set period of time, the team can calculate how much work they can actually accomplish during a fixed period of time in terms of story points. (This is called Velocity, but that’s a horrible name for it) And using that, the team can then make predictions about how long it will take to complete the rest of the work with increasing certainty over time.
As you can see, I’m enthusiastic about Agile. But, I’m not a fan of treating it as a set process instead of a framework. If you’re “doing” Agile at your workplace, but the process is preventing you from doing something that is best for the product or team, then you’re not being Agile. Agile is more of a way of thinking than a way of doing. There are many different ways to work within the spirit of the Agile principles. And there are a lot of great practices that are commonly used by Agile teams–pick the ones that work well for your situation–they are not all the best practice for every team.
