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.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
41 Corsham Street
London
N1 6DR
United Kingdom

Manchester

101 Ways Limited
No.1 Spinningfields
Quay Street
Manchester
M3 3JE
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.