Here is an attempt to demystify some of the common myths around agile. If you have more myths to share, will be happy to explain them here as well.
‘Agile development is not disciplined’
Agile developers are the most disciplined when it comes to development practices and rituals, as explained by the disciplines they follow, all of it is time-bound and committed:
– Engineering disciplines like continuous integration, refactoring, test driven development, behavioral driven development, pair programming and peer reviews, ensuring clean code on a daily basis
– Project management disciplines like daily scrum, sizing and re-sizing, sprint planning, retrospectives, gatekeeping velocity
– Product management disciplines like maintaining updated product backlog, end-user demos
Agile teams are successful when the disciplines are maintained, else it becomes chaotic
‘Agile Teams do not Plan’
Constant planning is in inherent part of Agile. The difference between traditional and agile is that while in traditional, the detailed planning happens up-front. But in Agile, this is how planning happens:
– Project plan: The high-level planning happens at the beginning and release milestones are defined. The basis of this can be the specification or the product backlog if it exists
– Release plan: The product backlog is analyzed along with the product owner. The product owner suggests which features should go in each release. Normally the earlier releases are planned in detail while the later releases are defined as per how the business demands evolve
– Sprint plan: Once the releases are planned, (normally, a release would span across few sprints unless you are practicing continous delivery) the features in the releases are broken into user stories and the stories are prioritised along with the product owner. The stories that are most risky, dependent, and of highest business value are chosen for the earlier sprints.
The plan is strictly followed through using indicators like release burn-down, sprint-burn-down, feature burn-up charts etc.
now, who says we don’t plan ? 😉
‘Agile development is not predictable’
Customer behaviors are changing; businesses are changing, markets are changing, competition is changing, needs are changing, products are changing..
Change is a way of life now.. Gone are the days when predictability was in, these are the days when we have to manage unpredictability. It is a paradox when we invent a method specifically to manage this unpredictability and complain that you cannot chart out what agile will deliver to you next year on a particular day. Make up your mind 🙂 If you wanted predictability, you should have spent few months writing detailed specs, do the task breakdown of few thousand tasks, get into a fixed price contract with few hundred fine-print clauses, and track the earned value, manage the mpp etc.. all of these or a combination where you have a predictable methodology working with 100% predictable requirements.
Ok, now that we have established that agile manages unpredictability, it does not mean agile is unpredictable. With the right kind of planning and tracking (see above the planning section), the value delivered can be planned and tracked much better than the traditional methods which get into tunnel effect. In agile, we do not rely on watermelon reports ( green outside; red inside) to measure progress; rather the product evolution speaks for itself.
The other factor that helps solve the unpredictability is the agile metrics and KPIs. Will write another detailed section about it later. If we measure the right metrics on the engineering side and product evolution, and integrate the right tools to measure product quality and feature progress, the predictability of the agile delivery is extremely high.
‘Agile means I can change my mind whenever I want to’
This is one of the biggest misnomers in Agile. We have had experience in the past with product owners who use agile team as an ‘experimental lab’.
“Oh let’s try this in next iteration and see if it works ; let’s try something else next time; why don’t we revert back to something you showed me 3 months ago as I think it was looking better than this ”
I wouldn’t blame the developers if they run away from such projects. Being agile doesn’t mean that the product owner changes mind all the time and ask re-work of the stories as per whims and fancies. The flexibility in agile is to pick and choose stories to execute as per the highest business value. But when people are not business focused, the above situation arises. Where we lose out is that the business value will never get delivered; stories will get re-worked over and over again; developers will get frustrated; and the planning will go for a toss.
It is extremely important to make up your mind about what you want delivered from the development team, the acceptance criteria of the same, get it delivered, validate it and deploy it to the business.
‘Agile means you never have to write documentation’
I would rephrase this as – Agile means you dont have to write ‘useless’ documentation that nobody reads, or get obsolete in few months. Traditionally we have made large specifications, flow diagrams, low level design documents, requirements traceability matrix, user manuals, understanding documents etc. How many of these actually get read? How many of these are updated, and after few versions of the product is released, how many of these still make sense, or just lying in some nicely organized folder in a document repository?
In agile, we encourage documentation that will be naturally managed. In-line documentation, architecture and design documents evolved out of functional architecture, wikis, social team spaces, lean online user manuals etc. take precedence.
In the testing space, rather than making elaborate test strategies, we rely heavily on test automation, defining and automating acceptance criteria through BDD tools, test reports and historical reports that come out of deployment pipeline..
It is not that there is no documentation in agile. It is just that the documentation is more useful, meaningful, naturally evolving and just about enough. In fact, our engineers are hired and paid to produce innovative products, aren’t they ? or to produce pages of beautiful documents ?
‘Agile means teams cannot be controlled by management’
The question is: do ‘teams’ need to be controlled by the management? or is it the ‘project’ that we need to control? Agile teams are built to be self-managed, empowered and motivated. Due to the fact that the team works closely with end-users, product owners and the business, and the fact that they have to deliver in small time-frame, the ownership level in agile teams is pretty high as compared to traditional.
If the focus is on controlling the team, the team tends to take less ownership of deliveries. On the other hand, having extreme level of discipline in agile teams is extremely important as the discipline will help to control the ‘project progress’ and the ‘quality of the deliveries’.
Agile principles are built around ‘intrinsic motivation factors’. The people working on the project are skilled and they take lot of pride in being the ‘best software engineers’ delivering high-quality deliveries using state-of-the-art techniques. The focus of the management here should not be to ‘control’ the people, but to facilitate the team by providing high-end functional infrastructure that supports agility, open work space, freedom to experiment with productivity frameworks, freedom to speak up for themselves, and most important of all, an environment where they can learn. When these factors are there, there will be an intrinsic control, and management doesn’t have to control any particular person. The focus is not on pointing fingers, the focus is on the product progress, on the client, and quality. And the people who do not fit into this high-paced culture, they get isolated in the team and eventually fall off the wagon, it is a self-cleansing environment.
‘Agile works only for small projects; it does not scale’
The recent researched have show that agile has been succesfully used in large scale mission critical projects. Many os the large failed projects have been retrospected and realized that if agile methods were adopted, the chances of failure would not have been there.
World-wide survey conducted by seven large institutions with over 5000 respondents prove that the number of developers switching over to agile is increasing, and Agile is not just confined to small organizations; size of organizations using agile is getting larger.
(Source : The Business Value of Agile Software Methods)The ability of the organization to have the vision of the product, organize the team into highly productive human sized teams, and to facilitate them with right amount of coaching to run agile at scale decides the fate of your large scale projects in future.
‘Agile development is just another fad / hype’
Gartner had predicted that Agile would be embraced by 40% of all software development teams by 2012. It is a fact that the adoption of agile has been slower than that, especially in large IT service companies. The first and early adopters of pure agile are product companies and internet businesses, and trading businesses like investment banks. The business is so volatile and demands agility that IT has no way but to adapt itself to this fast pace and demand for quality. So, for these early adopters, it was a necessity.
For the next set of people, it was seen as a good, logical and sensible way of building software. For the ‘lean thinkers’, it was just a natural progression to onboard agile. While a good part of the western world embraced agile, some parts of the world were just waking up. For regions like India where there are factory models of hundreds of people doing development, passing on to hundreds of testers etc, it is getting to be difficult to change the service model overnite. Yet, even in large services companies, there is a huge push to be agile from the overseas clients. We have yet to see the large scale transformation in these settings.
Nevertheless, the movement towards agile is large and undeniable. The movement is only in ‘one direction’. i.e, people who have embraced agile once hardly ever go back. and from the other side, more and more poeple are getting onboarded. It is only a matter of few short years before we see the death of old methodologies.
‘Agile teams do not work hard; they just play foosball’
I am not going to write and explain about this myth, you just need to come and see our people at work ! 🙂
Author
Co-founder of People10, a 'total agile' software development and consulting company.