This is a guest blog post from Maria Burton from Focus On Training…
As a software developer that’s been in the industry for over 20 years, I’ve seen a lot of processes come and go. When my software area decided to embrace an Agile methodology for our software development a few years ago, I remembered having the fleeting thought: Oh, here we go again. Fortunately, we’ve been on Agile long enough now that, not only do I think it has staying power, but I think it’s really making a difference in what we produce for our customers.
In this article, I share with you three misconceptions that my group had as we began our transition to Agile, and how time and experience proved them wrong. These misconceptions aren’t necessarily unique to our projects, but I think how these misconceptions broke down in the reality of doing the Agile process made our team and the process stronger.
When the Agile process was first described to my team, one of the more enticing aspects was that it appeared we no longer had to deal with huge requirements and design documents. In a way, that part turned out to be true. We definitely don’t create the same documentation that we did when we were doing the waterfall model process. However many of the folks that doubted the wisdom of the Agile process often commented that in Agile you don’t have to write documentation, and it just invited development chaos.
The reality for our Agile teams seems to be that we are writing more documentation. The documentation we write is much less formal but much more functional. We usually don’t write a document unless it’s absolutely necessary, and the story document is our core document. These story documents are often less than a page long, but they encompass a concise description of the business problem that needs to be solved with a synopsis of what design, architecture, or function can be introduced in our product to solve the problem. So, it seems we aren’t writing less documentation, but the documentation we do write has a lot more utility.
When we were doing the waterfall method, there was a lot of overhead around project management, product requirements, and other administrivia that really seemed to slow projects down especially at the beginning. Agile brought the promise of removing a lot of that overhead and freeing up more time that could be used to deliver more feature content.
What we found in practice, however, was that there were many Agile practices that we had never had in our previous process which actually seemed to eat away at the gains we thought we were going to make. For example, continuous code integration doesn’t just happen. It takes resources to enable that continuous integration, and that means time saved from the waterfall method overhead is invested in these foundation building activities. Other practices like test automation, peer reviews, scrum master, and end of sprint reviews take time as well. So initially, we weren’t more productive doing Agile, but instead we were less productive.
We found that the investments we made in these practices eventually paid off. Initial software releases were slower, but subsequent releases have been faster and more feature rich. So this misconception may actually now be a reality, but only because we were willing to pay the upfront costs.
Waterfall projects, especially long ones, are notorious for collecting signed-off requirements up front and then finding out that on project delivery they’ve really not given the customer what they need. With Agile there is lots of talk about getting ongoing stakeholder feedback to ensure that projects are doing the right features and to make course corrections as needed. The biggest concern I heard from both on-the-ground developers as well as product managers is whether we could get customers who were willing to provide that feedback.
Happily what we found was a core of customers who were not only willing but excited by the prospect that they could influence what we produced. Finally they didn’t have to wait months to get a software update that didn’t do what they really needed. From our perspective, we found the customers that gave the most feedback were also the most loyal, and they were a sale that we could count on when we put out our newest versions.
The journey we’ve made to Agile has not been the easiest, and we still work on improving the our process. Fortunately, none of our misconceptions held us back. Transitioning to Agile a few years ago has enabled us to produce higher quality software and be more responsive to our customers. We started off as skeptics, but now we’re evangelists.
Maria Burton is one of the coordinators for Focus On Training. Her roles include organising all PRINCE2 and Agile Training courses and also Keeping the company blog up to date. In her spare time Maria loves Reading Crime novels as well as watching horror movies at home.Follow @kelly_waters