3 Major Misconceptions About Agile

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.

Write More Code; Write Less (or No) Documentation

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.

More Features Delivered Faster

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.

Customers Are Too Busy To Participate

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.

Leave a Reply

What is 7 + 7 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”