I spent some time talking about risk and failure in my last post, noting the pathogenic fear of failure endemic at most waterfall development organizations. To a person conditioned to such an environment, the above quote probably appears nihilistic or dangerously clueless. At traditional organizations, failure is hidden, denied, rationalized and otherwise treated in ways that ensure its continued reappearance in the most destructive ways. In other words, the culture of fear of failure prevents most organizations from using it not only to learn and improve, but also to innovate.

A powerful benefit of Scrum is that it provides an environment to fail safely, in small ways, and offers plenty of feedback loops to make sure you glean maximum learning from each fresh failure. Which is exactly the opposite of waterfall, which in isolating disciplines, creating lossy knowledge handoffs, and lengthening feedback loops, virtually guarantees that failures are big, messy, and happen too late for much good to be made of them, at least for the project in which they occur.

By keeping failures small, we defuse much of their danger, thereby increasing their relative enlightenment value, because arguably it is through failure that most learning and innovation occurs. Angry Birds, for example, was the 52^nd game the company created. All its predecessors more or less failed, but gave the company valuable feedback on what didn’t work. For contrast, take the sequel to the popular 1996 video game Duke Nukem (remember Duke?). They absolutely had to get the sequel right, at all costs. After twelve years with no release, it cost dearly indeed. And when it finally came out, nobody cared.

Nevertheless, the perception persists. A disappointingly common result – used in defense of reluctance to shed unproductive habits, roles, and expectations preventing organizations from being more agile – is an appeal for a need to ‘be pragmatic’. This is odd, because agile is the most pragmatic approach to software development anyone has yet articulated. It doesn’t conflate the inherently chaotic, unpredictable, creative process of building software with a stable, predictable process like building a house or a bridge. It doesn’t confuse the subjective and infinitely changeable – even personal – success criteria of most software development with the objective and immovable criteria of say, mathematics or physics.

Unfortunately none of this means it’s easy to implement against the inertia of existing structures and decades of embedded assumption. But at what point is ‘being pragmatic’ simply an excuse for not trying to change?

In the face of repeated failure, wouldn’t the pragmatic approach be to try something new that might offer a chance of improvement? Most large organizations investigating agile are in a crisis state of perpetual project failure already, so they’re not actually risking much except the ability to blame the usual suspects. It’s not the risk of failure they fear – It’s the discomfort of change that’s the scary part. It’s the pain they know versus the one they don’t.

So many react to agile like the Frenchman in the joke about an American and a Frenchman struggling to craft a solution to a complex problem: The American drafts a straightforward but unconventional solution and passes it to the Frenchman, who examines it, frowning and puzzling over it at length, rereading it again before shaking his head and passing it back, saying: “This solution works in practice, but I’m afraid it doesn’t  work in theory.”

1)      Reading a Book on Agile and Thinking It’s All You Need to Get on Track

Reading about Agile is useful and absolutely encouraged. However, reading alone does not provide the more esoteric elements of an Agile transformation. I have spoken with countless team members at large organizations who have read a few books and started doing Scrum without any professional guidance. Every single one of them has told me some version of the following: “We read some books and got started with Scrum teams and sprints, and after a year, we don’t feel like all of us are on the same page as to what Scrum should look like.”

People go to therapists because it is impossible to objectively analyze one’s self and provide appropriate guidance. Shouldn’t this be the same for organizations? My colleague, Angela Druckman, uses a more universal metaphor: Professional sports teams are made up of highly skilled athletes, but still require a coach to perform well and win. If highly paid, highly skilled professional athletes still require a coach, why shouldn’t we expect our organizations to require something similar to achieve greatness?

2)      Breaking the Rules Before You Give the Rules Time to Work

Ken Schwaber, Scrum co-founder, once said, “Scrum is like chess. You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played, or not.”

Scrum exposes various kinds of organizational dysfunction, but does not tell you how to resolve them. Often teams will modify the Scrum framework because it does not conform to an established business practice. This defeats the whole purpose of Scrum right from the outset. Scrum is supposed to feel uncomfortable and chaotic at first because the point is to uncover organizational issues that need addressing. Changing the rules in an attempt to fit them to existing processes leads an organization into a long period of doing “sort-of-Scrum” in which no discernible benefit is achieved and which usually causes the organization to quit after a year or two because “Scrum didn’t work.” Scrum works just fine, but only if you follow the rules. One of our clients who led a global Agile transformation effort involving hundreds of people on three continents likes to say, “I’m not smarter than Scrum, and neither are you.”

3)      Not Involving Anyone from the Business Outside of IT

High-performing Scrum teams have been compared to jazz ensembles because communicative self-organization is the hallmark of a good improvisational jazz. However, most organizations today are more appropriately characterized as orchestras in which the musicians play their parts as written on the sheet music in front of them. Having a start-to-finish plan is necessary for orchestras because their performances are replications of a completed product.

The orchestral methodology is impractical for nearly all business organizations, but many try to do it anyway rather than operating as a jazz ensemble. Imagine if an orchestra’s percussion section started playing in a different time signature in the middle of a piece. The whole performance would go off the rails. In a good jazz group, though, if a player abruptly changes the time signature, the other players will adapt and go with the flow.

Transitioning to Agile is a significant change that should affect the whole organization. Not everyone in the organization needs to be on a Scrum team, but everyone needs to be familiar with the values and benefits of Agile in order to play their parts in a communicative, collaborative way.

4)      Lack of Commitment

An Agile transformation requires organization-wide effort. At the outset, there is often a period of chaos and uncertainty which must be endured. This is something many beginning Agilists don’t understand and it can get them pretty freaked out once they realize what they’ve gotten into. If a company is not committed to learning about Agile, how to practice healthy Scrum, and how to resolve the organizational issues that are exposed, then there is no point in even trying to attempt an Agile transition. Yes, there will be people who do not want to learn yet another process. Yes, there will be people who are uninterested and unengaged. Find the people who are engaged, get them together and continue to push for more commitment, especially from upper management.

5)      Unwillingness to Mentor Talent to Achieve Long-Term Quality

An unfortunate practice in many organizations is the constant attempt to do too much with too little. This can be particularly short-sighted when it comes to personnel. Have you ever heard the phrase, “Stepping over a dollar to pick up a nickel”? When training budgets are cut and mentoring activities are shunned because management considers mentoring to be paying two people to do one person’s job, the long-term consequences can be disastrous. People will become stagnant in their skill sets, get frustrated and eventually move on to an organization where their natural desires to learn and produce will be fulfilled. If a company does not foster a sense of worth and appreciation for their employees and does not invest in training and mentoring programs, the company is bound to suffer losses large and small, sooner and later.

*****************************

This is by no means a comprehensive list, but it is something you can use to analyze your organization’s approach to an Agile transformation. Try self-assessing your organization on each of these 5 pitfalls and then prioritize them. If nothing else, it could get the right conversations going within your organization.

Agilists have long held that Agile transformations require buy-in from entire organizations, not just the IT and development teams which have adopted the most popular Agile framework, Scrum. To understand why this is, it is important to go back to Agile’s roots and understand what exactly Agile means.

As the Agile movement has expanded, misuse of the word itself has become common. It is easy to say, “We want our company to be more agile.” This stands to reason. No one wins over shareholders by saying something like, “We prefer to remain beholden to our processes and plan-driven approaches instead of focusing on innovation and high-quality delivery.” Typically then, an executive will decide the business needs to “be Agile” so that the company appears hip and lean to shareholders, and leaves it to the rest of the business to figure out what Agile is and how they’re supposed to do it.

Let’s go ahead and clear up a couple of common misconceptions:

First, Agile is a set a values, not a process. This is a critical point to understand, so I’ll go ahead and say it again: Agile is a set of values, not a process. There are Agile practices that enable Agile values to take hold. Agile does not prescribe any specific practices, but instead presents Agile values through the Agile Manifesto and the 12 Agile Principles (http://agilemanifesto.org/). An Agile organization adheres to these values and probably uses a combination of Agile frameworks such as Scrum and XP to foster an Agile environment. Agile prescribes human interaction, complete pieces of working product, collaboration and response to change over all the ways we’re used to documenting, planning and channeling product development by skill set and development cycle. Agilists understand that product development comes with inherent uncertainty and inevitable change to the original plan. Agilists welcome change and consider uncertainty a platform for creativity.

Second, Agile exposes organizational dysfunction, but it doesn’t tell you how to solve the problem. Agile practices can often prompt more questions than answers. Agile practices do not pretend to be silver bullet solutions. They are simply methods people have used to successfully ferret out organizational waste, technical debt and micro-management, while also focusing on high-quality, high-value delivery.
Organizations that have done the hard work of examining and adapting their internal structures to adhere to Agile values have had great success with higher quality, more frequent delivery. Organizations that have expected ingrained business processes to stay in place while also working toward a more Agile environment have not.

A problem many organizations are running into is that their Agile development teams are delivering high-quality product at such a rapid pace that the organization’s non-Agile teams cannot keep up. As an example, take the following scenario: Marketing is working on web pages based on the original, loose plan and does not know the development team was able to get more features into the release than originally anticipated. Legal has no idea the License Agreement needs an addendum as a result of the development team’s use of some new open source tools. Salespeople have been telling customers about the planned features for the new upgrade, but do not realize they could be selling even more desirable features to clients.

What is the point of delivering high-quality, high-value product based on consistent customer/stakeholder feedback if the parts of the organization responsible for marketing and selling the product rely on outdated and demonstrably false estimations and plans? Having Agile development teams working in conjunction with Agile marketing and sales teams is the next logical step for many companies in the midst of Agile transformations. For a business to reach its full potential as an Agile organization, it must jettison its outmoded business practices and bring all of its teams into the fold of Agile values.

It makes me sad to see that Scrum and Agile are often implemented as just another way to constrain people and squeeze work out of them. Innovation, intrinsic motivation, teamwork, and employee retention do not thrive in those environments, so eventually the companies that do this won’t be able to compete. But in the meanwhile, they’re sure causing a lot of pain in the name of Agile. One person with strong feelings about this wrote the following to me via LinkedIn:

Michael,

I like what you said, I appreciate the way you said it, and I am glad you were the one to respond to my comment on xp and scrum. In the agile world (and I demoted the “a” a long time ago out of frustration) all the pigs are the same. Only in the way scrum has devolved, some pigs are better that others.

I was hooked on XP after reading my very first agile book (…Embrace Change). Almost a decade later I am jaded, confused, saddened, and have lost the will to challenge the status-quo in agile. In one company I left, the scrumlord actually enforced the waterfall method for project management. (Rally lists and charts were far more important in the presentations to the client than our application or hearing their feedback.) And the company was proud of their “agile” teams. And pair programming, refactoring, TDD, revision control, version control, continuous build and all the rest was forbidden by the scrumlord. “Waste of time,” he always told the CEO.

Why has this happened?

My first guess is that the professional manager found a way to insert themselves into agile — in a particularly contrary move to the spirit of agile. My second guess is that to be a good scrumlord, you really do need to know the technical side and there are too few middle managers who are capable of that. Lastly, I would say that no practice, no methodology, and no trend can do away with the ego of the middle manager.

But, as I say, I’m jaded.

I suppose it was the end of me at that fateful job but I knew it was time to go when I told the scrumlord that a team with only XP can still produce a superior code product with few errors and little technical debt. But a team with only scrum cannot. It would have just been an opinion except I was proved correct in my hyperbole and they had to punish someone.

You use words in ways with which I was once familiar. It is the same melody that drew me to agile so long ago. Is it still being heard in some fair corners? Not where I’ve been. And I don’t look for it any time soon. If you truly live the words you write, then your team is fortunate. And your clients even more so.

So long as the command and control business model is more valuable to corporate leaders than their product and their people, I will keep spelling agile in the lower case.

[name omitted]

After I reported on this email, my friend Kane Mar sent another example of a someone who’s been burned by the discrepancy between what we say and what we do: http://www.halfarsedagilemanifesto.org/

One way to check whether your Scrum implementation is anything like what we had in mind is to go through the ScrumMaster Checklist. The items you mark with deltas may be organizational impediments worth discussing with the highest level person in your company who will listen. If they still won’t listen, please make the best of your short lifespan by finding people to work with who are more committed to human innovation.

–mj
(Michael)

Specifically, I covered:

• What a product backlog is and how to create product backlog items
• How to write good user stories
• How to estimate product backlog items
• How to groom the product backlog, and
• The importance of treating the product backlog as a living artifact

During the webinar, we encouraged our attendees to interact with us by asking questions for the live Q&A session that we had at the end of the presentation. As a result, we received many great questions that we just couldn’t get to during the live event so we have provided answers to the audience’s questions below.

If you missed the session live, you can watch the recording and download my slides.

Don’t forget to register for our upcoming webinars! CollabNet offers multiple webinars a month that cover a variety of topics related to software development.

As promised, here’s the follow up to some of the live audience questions we received:

Q: What was that 2nd user story you mentioned?  It was a good example – As a user I want to login to a website so that I can save my preferences…
A: We were pointing out how important it is to listen for not only what is said in a user story but also what is inferred.  Compare these two examples:

• “As a user, I want to log in to the website so I can use it.”
• “As a user, I want to log in to the website so I can save my preferences and don’t have to reenter them each time I visit.”

In the first story, the implication is if I don’t log in I cannot use the website at all.  The second story, however, implies that I can use the website without logging in but if I want it to remember me (and my preferences) I need to log in.  Agile teams need to get good at identifying not just what is stated in a user story but also what is inferred.

Q: Is everything in the Product Backlog in some “User Story” format?
A: While it is certainly not required to use the user story format to create product backlog item, it is a very popular and useful way to describe requirements.  However you choose to write your product backlog items, do try to keep them succinct for readability.  You can link backlog items to more detailed documentation when necessary.

Q: Does the level of detail contain something about the how?
A: As we said, user stories are about the “what”.  Tasks, created by the team, are about the “how”.  Acceptance criteria is right in the middle, with some characteristics of both.  Likewise, supporting documentation, such as design documents, may have strong elements of “how”.

Q: Are there instances where a backlog item is labeled as “L” or “XL” without it being an epic?
A:  I consider “L” and “XL” to be valid story sizes.  Anything bigger than that, however, would be an “epic” and the team would need to have that story broken down into more granular pieces before they could even consider including them in a sprint.

Q: What do you do when you have a Dev Manager that wants to use real numbers (in days) for User stories rather than story points? Mostly because he has 20 years in the business and feels he knows the workload well.
A: How does the team feel about it?  If a team is keen to try relative estimation (which they often are) as ScrumMaster I would work with the manager to help him understand that what really matters is getting the team to the point where they make sprint commitments they can successfully fulfill.  This is what will win over the Product Owner and, for that matter, the rest of the business.  I feel you are describing an individual who has not yet internalized agile values.  As long as the team is told how long work “should” take, they won’t truly self-manage.

Q: If the Product Owner role is a full time job, and you have a Product Owner that is not available full time – how do we make Scrum work? The Dev mgr has been grooming the backlog and the developers have been writing user stories in the Product Owners absence. This has been challenging for the team to understand the Product vision and to have “non-technical” user stories. Any advice?
A: A couple suggestions. First, stop doing this person’s job for him.  As long as you give the Product Owner “excessive” help, he will never do the job.  If you have not done so, start scheduling regular Story Time meetings to show him how to develop his backlog.  Many Product Owners fail because they have received no training and don’t really understand what is expected of them.  Next, work with the organization to make sure the Product Owner is held accountable for actually doing the job.  If he sees it as something to be squeezed in during his spare time, he will never give it the thought and effort it requires to be successful.

Q: How do you manage dependencies between stories?
A: Discuss them.  As a Product Owner, as soon as I did a preliminary ordering of my backlog the very next thing I wanted was feedback from my team.  Often, they has ideas for moving user stories around to reduce dependencies or gain some efficiencies.  I had final say on the order of the backlog but their input was priceless to me.

Q: Can we Use Case in place of User Story? What is the difference?
A: Use cases, at least most of the use cases I have worked with, a sometimes large, multi-page documents.  A user story is a succinct single sentence.  Use cases can support user stories but they are not the same thing.

Q: How do you prioritize based on “business need” driven by PO vs Dev need to develop high risk feature first.  Looking at risk/value grid!
A: The short answer is: through discussion.  A good Product Owner never works in a vacuum.  He wants input from all stakeholders and that includes the team.  But because the Product Owner is the one ultimately held accountable for the product, he has final say on priority.

Q: Who facilitates the Story Time session?  And who be involved?
A: The ScrumMaster facilitates the discussion, since SMs are often master facilitators!  However, the Product Owner should set the agenda.  The goal of the meeting is to improve the product backlog.  He should be intimately familiar with where it needs improving.  Stakeholders may attend this meeting at the PO’s discretion.  This meeting is a great tool for gathering requirements.  And, of course, Story Time meetings, like all agile meetings, should be time-boxed.  Regular meetings of 60-90 minutes are much more effective than one marathon session.

Q: Are there any guidelines around estimating the size of user stories, should the sprint length be taken into account?
A: Teams will come to consensus remarkably quickly on what, for example, constitutes a “medium” story.  Leave this up to the team.  But all stories must fit within a sprint.  If they do not, they are “epics” and must be broken down.

Q: How do we organize support-related work (assuming it’s performed by same team)?
A: Some teams reserve capacity in their backlog for support work, based on historical data.  But a necessary discussion to have when these “emergencies” pop up is “Can this wait until the next sprint?”  True, sometimes the answer is no.  But if you are doing, for example, 2-week sprints sometimes the “wait” would only be a few days.  Then the work can written in a user story and added to the backlog.

Q: What is the most effective way a ScrumMaster could do in order to help product owner to maintain and clean up product backlog?
A: Show them what to do but don’t do their job for them.  Writing the Product Backlog for your Product Owner only teaches him that, if he ignores his job, you will do it for him!

Q: As presented earlier the acceptance criteria should be negotiable. Does it mean that during demo meeting PO can change one of the acceptance criteria?
A: The “negotiating” of acceptance criteria happens in sprint planning, before any commitment has been made.

Q: Who or what types of people should attend the Story Time Meetings?
A: The ScrumMaster, Product Owner, Scrum team and any stakeholders invited by the Product Owner.  On larger projects, the PO may find it useful to have a business analyst there to help document user stories.

Q: If you use t-shirt sizes to estimate, how do you derive sprint velocity?
A: Teams that use t-shirt sizing often use a numeric “weight” for each size to calculate velocity.  The “powers of 2” scale is quite popular:

XS-1

S-2

M-4

L-8

XL-16

In this scenario, a team that committed to 1 large, 3 medium and 3 small user stories would have a sprint commitment of 26 story points.

Q: Can you please elaborate on what should happen during the planning meeting?
A: During the sprint planning meeting, the Product Owner wants the team to tell him how many user stories they are willing to commit to deliver in the upcoming sprint.  To do this, the team and Product Owner must establish acceptance criteria for each story, or what it will take to call the story “done”.  The team will also probably want to do estimation and also to begin task creation.  They may even start to plan the work of the sprint and who will do what.

Q: What are the criteria / conditions for a “groomed” story ready for Sprint Planning meeting?
A: A “groomed” user story is one that is clearly written and of reasonable size, meaning it can fit into a single sprint.

Q: What are the competences required to be a good product owner?
A: Thick skin!  Organizations almost always have more wants than they do money or time.  Product Owners have to make tough trade-offs to get the most value possible given those limitations.  Good Product Owners can make decisions, but never do so in a vacuum.  They know how to prioritize and maximize value.  And they take the job seriously.

Q: Regarding breaking down epics, is that process typically a PO effort or a team effort?
A: the Product Owner will almost always require help in breaking down epics.  If he could do it by himself he probably would have already.

Q: Do you think that all items of the backlog should be estimated or is not necessary for the items at the bottom?
A: It is nice, after teams get some experience with agile, to estimate out a few sprints.  This helps the Product Owner with planning.  Much more than that is probably so inaccurate as to be useless.

Q: Are there any additional pointers for a product with a backlog that is thousands of items big?
A: Close your eyes and delete!  Seriously, you need to winnow it down.  Assign a Low/ Medium/ High ranking to each item.  If it makes you nervous to actually delete items, move the “lows” to an “on hold” backlog.  I personally have never seen an actionable and well-organized product backlog with more than a couple hundred items at any given time.

Q: If product backlog ordering is done in backlog meetings then is this overlapping with the Sprint

Q: Good afternoon Angela, when are you brining PO training to NYC?
A: We currently do not have PO training in NYC, but I will pass along the request for it.

Q: Assuming you have several released stories, what if the product owner decides that these stories must be changed?
A: Then he can write new user stories for these changes—no problem whatsoever.

Q: We have some great Product owners and then we have some that won’t participate that we are having to be stand-ins for, is there one key thing we can do to make this more successful?
A: Make sure you have the right people in the job and that they have the tools to do that job.  Look at those “great” Product Owners and try to figure out why they are great.  What do they do or have that the others lack?  As an Agile coach, one of the top issues I am called in to help with is Product Owner problems.  When I arrive I often find POs that have not been trained, don’ t know what is expected of them and are not getting help and support.

Q: If you work at an organization where the executives want the final say on the order of backlog items, how would you handle that?
A: The Product Owner has final say on backlog order so, if an exec wants that privilege, she has to take on the rest of the PO role as well.  That usually doesn’t work out and eventually these individuals see they must delegate some authority.  Delegation should not be a foreign concept to the average executive.  Giving someone authority as Product Owner is just a form of delegation.

Q: Any hints about how to recognize if our backlog is “not in a good shape”? (Without reviewing each PBI one-by-one if possible)
A: A mature backlog has smaller, more detailed user stories at the top, less detail at the bottom.  It is “chunked” into bodies of work like releases.  It is full enough to keep a high-performing agile team busy.  If this is your backlog, you are on the right track!

Q: What role does a business analyst play on the product backlog?
A: Business analysts often help Product Owners understand and write backlog items.  They may also write supporting documentation and even help with testing.

Today I read an example of that happening with no resistance from the outer organization:

Hello Michael,

Thanks very much for your message.
I did not blog about this, because my blog is still under construction.
We are a software company employing about 50 people.
A few years ago, our CEO introduced a company wide bonus system, based on 5 KPI’s. The KPI’s were different for every department, to be determined by the manager of the departments, like Direct Sales, Helpdesk, Development.
I told the CEO that, as a Scrum Master (and manager of the Development department), I could not decide on these KPI’s myself (nor did I want to), so I “took it to the team”, to coin a popular (and rightly so!) Agile phrase.
We discussed it in multiple sessions (I did not “lead” these sessions, nor did I put my view across, I just asked questions), but the team kept coming to the same conclusion: Any KPI we could come up with, either infringed on the Scrum principles, or deferred the team from the continuous improvement principle.
And believe me, we brainstormed about a lot of possibilities: Number of story points gotten credit for per sprint, number of iterations per story or task, newly reported bugs per sprint, even lines (and characters) of code.
Our bottom line was, that it just doesn’t sound right, quantifying performance on any other criteria than working software. And, adult and intelligent as we obviously are (I mean, we’re Development, right?), there will still always be this “hidden agenda” in the back of one’s mind, that makes one, for example, report two defects in one bug, or write a routine differently, to make it larger, in order to positively influence the KPI’s. It’s all unwanted distractions, in the end.
So ultimately, we unanimously decided to kindly refuse the offer. Much to the surprise of the rest of the company, including management. Priceless to see the look on their faces. Funnily enough, no-one asked us to explain why. I reported it to the CEO, and he understood. He’s into Agile. Thank God.
Up to this day, we still don’t participate in the bonus system.

I’ve used this example on a few occasions myself, because it’s very illustrative.
You’re absolutely welcome to share it with other people, if it contributes to spreading the word.

Kind regards
[name omitted pending permission to identify]

I hope the example helps illustrate that teams do not need to tolerate counterproductive management practices. We do these things out of habit and fear, but people who love their work are driven by something else — and why would you hire the other sort? Esther Derby recently tweeted she’d never heard of anyone being fired for declining to participate in performance appraisals. I haven’t either.

–mj
(Michael)

The reader comments following the article are also quite unintentionally humorous. Many readers, obviously unfamiliar with Agile, trashed all over the idea of making people stand up for 15 minutes a day, while several earnest Agilists responded with attempts to show them the light. Some negative commentators were utterly infuriated that Agilists are strict about being on time to meetings! Seriously, how in the heck does one get so riled up over the notion of asking people to be on time out of respect for everyone else’s time and their shared objectives?

As Agile becomes more commonplace, those who have been involved in promoting healthy Agile practices for years likely realize that there is still a significant road ahead in ensuring organizations adopt the right practices for the right reasons. Agilists work hard to promote the concept that Agile is about constantly delivering business value and inserting many feedback loops into the development process to discover and reassess what business value truly is. The desired outcome is the delivery of timely, high-quality products which meet or exceed the objectives laid out by our customers. That concept sounds nice and businesslike, but certainly not as attention-grabbing as the Wall Street Journal article. A fluff piece describing people standing up during meetings, throwing medicine balls around, and squeaking rubber rats at each other will get more page views. And raise more hackles.

I recently had the opportunity to speak with a former CTO of a global technology company everyone has heard of and who currently works with a venture capital firm. I asked him what he thought about Agile and he was quick to express his frustrations with the practice. His main criticism was that there no longer exists such a thing as a schedule. How could he work with teams that refuse to commit to delivery dates? Of course, I’ve heard this complaint before and had to resist the desire to bang my head against the wall. Unfortunately, this executive is far from alone in having gotten the wrong impression of Agile. All too often, teams and entire organizations set out to practice Agile, but end up flailing because they take shortcuts, perform half-measures, and generally waste a lot of time and effort while trying to “customize” their own versions of Agile.

For the record, Agile demands great discipline. It also demands conversation and difficult decisions and there is such a thing as a schedule. We build the highest-value items first, and when a delivery date looms and the backlog is not completed, we conduct (hopefully) reasonable conversations about what we can do to meet the objectives in the backlog. In the meantime, our customer is happy because throughout the project the focus is delivering high-value, high-quality, finished (i.e., tested) product which is certain to be released in the customer’s time frame. Does it have everything the customer wanted? Probably not. Does the customer need everything they wanted? Again, probably not, but the top-priority objectives are completed and due focus can then turned to the lower part of the backlog where the “nice to haves” live.

As Agile gains traction, it is important to remember that for every great Agilist out there doing great work, there are far too many people who have good intentions but don’t know what they’re doing, and they are creating a public relations mess and leaving behind them a wake of failed Agile transformations. It’s a frustrating shame that their bad practices lead to misconceptions about Agile. As for the Wall Street Journal article, perhaps there is no such thing as bad publicity. Of course, rather than a fluff piece focused on the not at all revolutionary concept of standing up in meetings, I would love to see something in the Wall Street Journal about how Agile helps deliver high quality business outcomes while saving organizations money. But until then, we can appreciate that the word is getting out, and do our best to correct the malpractices and misinformation.

Merriam-Webster defines agile as:

1: marked by ready ability to move with quick easy grace <an agile dancer>

2: having a quick resourceful and adaptable character <an agile mind>

The Cambridge Dictionary defines it – in British (not American) English – as:

able to move your body quickly and easily <Monkeys are very agile climbers.> <You need to have agile fingers to do this kind of work.>

Notice that the key word here isn’t ‘fast’, but ‘quick’.  ‘Fast’ is a fraught word, and seems to be what most think will be the new nature of an otherwise traditional project – exhaustive, ill-informed, up-front specifications and all – once we just get agile.  But do we really want the whole train wreck to simply increase speed and arrive sooner?

Agile’s primary benefit isn’t speed but, rather, feedback – between development team members, the development team and the business, and the business and the market.  The most noted effect is greater understanding and insight into what’s working and desired (and what isn’t).  This allows course correction that wouldn’t be possible if you were only hurtling toward a mistaken destination ever faster.  Admittedly, over time and with experience, this difference does lead to a speed-related effect:  more frequent delivery of only the highest-value items.

But what’s delivered to the business and the market isn’t faster in the same sense as what’s expected; You won’t get a whole year’s worth of pre-agile production of code in only three months post-agile. And you wouldn’t want to, would you?  What you might get – with learning, practice, and experience – is a traditional year’s delivery of value in half or a third or even a quarter of the time.  But first you’ll have to get really good at listening to the feedback you elicit, involving your customers, and changing your mind and your plan.  But will you be faster? Which is more important?

While it’s understandable to want to allocate credit for the effort spent to the sprint to which it ‘belongs’, it’s important to remember why there’s no partial credit in Scrum: Because working software is the primary measure of progress (#7 of the principles behind the Agile Manifesto). The metric of record is therefore how much a team can complete to potentially-shippable quality each sprint, not how much they can complete to 90% finished status. This is a common occurrence with new Scrum teams. By the end of Sprint, they have a whole bunch of backlog items “90% complete” (whatever that means), which means they’ve got nothing done to potentially-shippable standard, which means they’ve delivered zero business value. In other words, they’re 0% done.

Attempting to ‘give credit where it’s due’ by tracking how much work was performed in which sprint skews the emphasis toward measuring how hard people tried to reach a goal, which isn’t what we want. We want to measure the goals reached: backlog item story points competed per sprint, or business value delivered if you’re using that metric.

The most common recommendation is that an unfinished backlog item gets returned to the product backlog, with its original estimate intact. When it gets committed to a new sprint and completed, the backlog item’s full effort estimate gets credited to the Velocity of the new sprint. While this may appear to skew the numbers, the numbers average out over time – and it’s this average velocity that a PO uses for forecasting and planning. Moreover, this practice adds an incentive for the team to do their best to discuss, negotiate, estimate, and commit to finishing backlog items to full completion in a sprint.

If management and finance want to track costs for purposes outside of managing a team (one that doesn’t need managing because it’s self-organizing) – say, for hourly client billing – then a task-level metric might be used. A carried-over backlog item’s constituent tasks done in the first sprint will remain counted as tasks completed (or task hours completed and remaining if you’re using those metrics) as part of graphing the sprint burndown in any good agile project management software such as ScrumWorks Pro.

This is a not-uncommon business need, although the practice is easily abused to “manage” agile teams’ “productivity”. The danger here is that it leads to a mentality (to use a relay-race analogy) of tracking the runner rather than tracking the baton. In Scrum it’s the baton that’s important – that is, story points of backlog items done to potentially-shippable completion each sprint (Velocity). Since ultimately that’s what we care about, then that’s what we should spend our expensive, limited time encouraging and focusing on.