I want to address some common misconceptions about Agile. We’ve all been told to “just be more agile”. But what does that mean? What can we do about it? And how can we ensure that we derive the appropriate value from our “agile processes”, whatever that means? I’ll look at those questions in future posts, but first I have to eliminate some common misconceptions about agile and about Scrum in particular. This post will address myths around agile itself, part two will address myths around scrum in particular, and the last entry will finally uncover what agile is and how to get value out of it.
Myth: Agile came first
The legend says that in 2001 a group of seventeen software engineers got together in Snowbird, Utah to find a better way of developing software. When they came out of their black box several days later, they emerged with The Agile Manifesto, and a new era of software was born. Specific methodologies to achieve the values of this new and glorious Gospel soon emerged: Scrum, Kanban, and XP.
The truth is that Scrum was practiced at Toyota in the 1980s and on various software projects in the 1990s. Kanban also has its origins at Toyota in manufacturing, and XP has been around since at least 1996.
As for the meeting in 2001, it did happen. Scrum and XP practitioners were in attendance, as well as many others. However, the point of the meeting was not to develop a new way of engineering software; it was to unite various communities with various methodologies already proven to be successful in order to discover the common elements between their different practices which contributed to their teams’ success. In OOP terms, the “concrete classes” of Scrum, Kanban, and XP already existed; the purpose of the Snowbird meeting was to extract out the “common interface” between them, not to develop a new “interface” that new methodologies would derive from. In other words, Agile owes its success to the prior success of Scrum, XP, and the like, not the other way around.
Myth: Agile is just a set of values
Most developers read the agile manifesto and come away thinking something like this:
“We are uncovering”…blah-blah-blah…”individuals and interactions over processes and tools”, yeah, I like that! The company should value its people more than some rigid process and be understanding when things start to take longer as a project gets bigger. “Working software over comprehensive documentation”. Tell me about it! Our stuff never works, and I don’t really like doing documentation anyway. “Customer collaboration over contract negotiation” is ok I guess, but that sounds more business-y than developer-y, so I don’t know what it has to do with me. “Responding to change over following a plan” sounds good. Maybe. I’m not a fan of changing requirements, though. Cool, so this is just saying that agile is a set of these values. They sound mostly OK, so I guess since I value these things, too, I must be agile, too!
Well, there are at least some half-truths in there, but agile is about more than valuing these four things. It has reasons for valuing those things, and it explicitly decries the claim that the things they are valued “over” are valueless. But, for starters, there are the twelve agile principles. I won’t iterate over all of them in this post, but the imaginary developer I quoted above might not appreciate the ones about how agile “welcome[s] changing requirements, even late in development” and how “the sponsors, developers, and users should be able to maintain a constant pace indefinitely”. Even the lauded value of “working software” might become less appreciated when the ramifications become clear and no excuses are accepted for producing software that doesn’t work.
You can get a picture of agile by reading the manifesto itself, but to get a clear picture you need to understand how those values stem from the twelve principles.
Myth: Agile helps teams code faster with a smaller team.
I don’t know where this myth came from, but I hear it all the time, mostly from business people. Let me state this once and for all:
Agile aims for a consistent velocity, not a higher velocity.
There is a problem that occurs in big software projects. You know the one. Everything goes along just great for the first month or six. Then you get into some of the deeper weeds and discover that you need some extra logic in a piece of code that was written by someone else three months ago and hasn’t been touched since. The feature continues to churn, but it’s churning through a sludge that gets thicker with every commit. Eventually it’s such a clusterredacted that the entire engineering team is recommending starting over from scratch. This happens especially often on government contracts.
The problem I just described is a large one, and (the non-technical) part of it is what Agile aims to solve. If your pace is already consistent and your problem is not that your pace is decreasing but that your team isn’t making progress fast enough for the business’s liking, then that’s a headcount problem, not an agile problem, and no methodology under the sun is going to fix it. But if you’re encountering the Big Ball of Mud, then a combination of Agile and better engineering practices could do wonders for you.
Myth: The opposite of Agile is Waterfall.
The problem with waterfall is not the existence of plans or estimates or budgets. The problem with waterfall is not solely in the idea of doing a large amount of design up front. The problem with waterfall is that the large investment in those plans makes people tend to rely on them and resist changing them, even when conditions and variables change or are discovered to have a different value than originally thought.
This tends not to matter in most engineering disciplines because it’s expected for things to change infrequently and to cost a lot when they do. If you are building a house, and the customer suddenly decides they want an extra room, it is well understood that this marks a substantial change to the engineering plan (not just structural but electrical, possibly plumbing, etc…) and will incur significant additional costs. However, the methods of integrating this change into the plan and how to execute them are well understood by the architect, because he has made this exact change to hundreds of other projects.
In software, it is different. Customers don’t understand when changes cost large amounts of money because “it’s just code; it should take you, like, five minutes”. Furthermore, the change may take even longer than would reasonably be expected in software. That is, since each piece of software is different, the engineer hasn’t made this same change hundreds of times before like the building architect has. He has to try to think through the possible repercussions throughout this particular code base of this particular change. Yes, various patterns emerge, making experience invaluable. But this code base is still unique and presents unique challenges. Does another module depend on this behavior? Does another module use this same code for a different purpose? The engineer must answer these questions and many more without a standard means of doing so. If he does not consider these items, or if he tries and fails to consider all their ramifications (which he almost certainly will), then making the change may appear to be successful but actually cause a bug in a seemingly unrelated part of the system which won’t be discovered for weeks or months.
In Agile, because the plan is more flexible, we do not need to start over so frequently when the plan changes. As such, agile welcomes changing requirements, even late in development.
Myth: Agile teams must have daily stand-ups.
Most Agile teams have stand-ups. Successful Agile teams usually have a stand-up that functions as a planning meeting for the day. Scrum and XP both prescribe a daily meeting for this purpose. It tends to be called a “stand-up” because it is supposed to be kept short and therefore a common rule is that the meeting must be held with everyone standing up.
In asking how to achieve the goals of the daily stand-up, the most common advice is to begin with some basic questions. What did you do yesterday? What will you do today? What are your roadblocks? These questions are fine, but what usually happens is that everyone starts to think of the daily stand-up as a progress report instead of a planning meeting. It becomes boring and is quickly resented.
The fact is that some of the highest functioning scrum teams do not have a daily stand-up. This is because they’ve mastered communication and planning to such a level that they get it done as needed instead of requiring a formal opportunity to do so. Most teams, however, need some form of daily planning, so they implement stand-ups. Unfortunately, they usually do so without a clear idea of why they are doing it and of how to get the proper value out of it.
Myth: Agile discourages planning and documentation
Plans are good. Plans are essential. Documentation is needed and can be a time-saver or even a life-saver. Agile does not disparage these things.
What Agile does say about plans is that change happens. This does not mean that the plan was not worth making in the first place; it means that the plan should have been made to be flexible. It means that the plan has to change and has to be able to change. It means that the organization cannot worship the original plan as an end unto itself. Large government contracts tend to do this especially.
What Agile does say about documentation is that–given a choice between software that works now or software that is fully documented now–the former is more valuable. This is meant to address the time sink that is creating a comprehensive 300-page tome of documentation that will never be updated and hardly ever used. It is not meant to disparage the need for some amount of documentation.
Summary
Agile is actually a simple system. It involves communication: the team reflecting on their way of doing work in order to improve it, the team and customers reflecting together on their product in order to improve it, and ensuring that value and feedback are delivered fast. Next week I’ll investigate some myths related to Scrum in particular, and I’ll return to the series on .NET Testing Frameworks after that.
The Developing Coder 