I would like to welcome Ed Willis to our blog, as a guest blogger. I spent a couple of days with Ed and his team of internal coaches this Winter and I am glad to have him share some of their lessons from the field of large distributed Agile – Ryan
Question: What are we, as Scrum team members, committing to in a sprint?
The higher-level Sprint Goal or the more detailed set of selected Product Backlog? If you are a customer of the team, what is the team telling you it will do?
I recall being pretty confused about what the team was committing to in Sprint planning after reading Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, for the first time. There seemed to be some ambiguity around whether the Scrum Team commits to the set of selected Product Backlog items or to the Sprint Goal, which is a higher level and less precise concept. A couple of quotes from that book will help illuminate the situation:
“A team commits to achieving a Sprint Goal.”
“The Scrum Team commits to turn a selected set of Product Backlog into a working product.”
And this from Schwaber’s The Enterprise and Scrum: “… the team selects as much Product Backlog as it believes that it can transform into a completed increment of potentially shippable product functionality by the end of the Sprint. The team commits to the Product Owner to do its best to complete that amount of functionality.”
From the first book again, “The Sprint Goal is an objective that will be met through the implementation of the Product Backlog … The reason for having a Sprint Goal is to give the team some wiggle room regarding the functionality … If the work turns out to be harder than the team had expected, then the team might only partially implement the functionality. “
Note that that last quote appears nearly verbatim in a recent (Feb 2010) version of the Scrum Guide published on scrum.org.
Between the current Scrum Guide and 2001’s “Agile Software Development with Scrum”, Schwaber’s Agile Project Management with Scrum presents an overview of Scrum in its first chapter which does not discuss the Sprint Goal at all – similarly, “The Enterprise and Scrum” provides a summary of Scrum in an appendix that does not talk about the Sprint Goal.
So what are we, as Scrum team members, committing to: the higher-level Sprint Goal or to the more specific set of selected Product Backlog? And why am I so focused on Sprint-level commitments? I focus on commitments because my stakeholders and customers value them. Their plans are in part based on my team’s delivery and so being able to make and meet short-term commitments makes us a better partner to them – “don’t trouble your customer”.
Can You Commit to an Incomplete Sprint?
“Agile Software Development with Scrum” states, “Sometimes only a partial Sprint Backlog can be created … define the initial investigation, design, and architecture work in as much detail as possible, and leave reminders for work that will probably have to be done once the investigation or design has been completed.”
Both that quote and the earlier one on the purpose of the Sprint Goal suggest that the Scrum canon allows for both incomplete Sprint planning and a mechanism to de-scope the Sprint if the team falls behind. If you find yourself in a situation similar to mine (and I suspect many, many of us find ourselves in this situation) where your customers and stakeholders really do value the ability to make and meet high-level commitments in terms of working software that will be delivered at Sprint’s end, then I think that finding a way to do this more regularly is a path you can and should pursue. And it’s one my colleagues and I have embarked on wholeheartedly. All you really need to do to become a better partner in this regard is advance your Sprint planning practices and adapt the strategies you use when you discover you’ve fallen behind.
Reliably Committing to the Selected Product Backlog – One Group’s Perspective
Being able to reliably deliver against Product Backlog commitments isn’t hard conceptually – it starts with doing a better job in Sprint planning. There are probably many ways to do this but I thought I’d share what we’ve done to accomplish this.
Capacity Planning
Our Sprint planning starts with a detailed view into capacity. Is anyone on the team going to be away on training or vacation during the Sprint? Will the remainder of their time be focused on the Sprint? If not, how much do time they think they’ll have to spend in the Sprint? Knowing the total capacity of the team in the coming Sprint is the foundation of a solid Sprint plan.
Ideal Time Estimation
To estimate our Sprint Backlog tasks, we use “ideal time” as it is described in Planning Extreme Programming by Beck and Fowler: “Ideal time is time without interruption where you can concentrate on your work and feel fully productive.” Ideal time on any given task is in essence the answer to the question “how long would this task take you in a perfect world?” Ideal time is then converted into real time in a very similar manner to how story points are converted into expected duration for stories – you measure the velocity of the team. For example, if ideal time velocity of a team is measured at 0.66, then two ideal days of work has been seen in the past to be about three calendar days.
That use of past experience is critical because it rolls up estimation error, overhead, interruptions et al into a single factor used to improve the accuracy of the task estimates while only requiring of the people doing the estimates that they do so consistently. We’ve found it useful. Conceptually I also like it because, along with the use of story points and their corresponding velocity, it increases Scrum’s fractal, self-similar nature.
Assigning Tasks
Typically we assign all the tasks in the Sprint Backlog during the planning meeting. There’s probably enough divergence of thought on this point to warrant its own post, but to stick to the matter at hand, we do this for reasons relevant to the goal of producing more reliable Sprint plans. One major motivation is the fact that estimates provided by the person who will actually do the work are demonstrably more accurate. The second major motivation is our observation that, when trying to achieve greater work sharing and improve the flow of value to the customer by avoiding bottlenecking through specialists, we do a better job of supporting people who are branching out into unfamiliar territory if we know they’re going to do so a priori. Specifically, we can build time into our Sprints for the people who are more knowledgeable in a given area to mentor or review the work of those who are working in areas less familiar to them.
Spikes
We make frequent use of spikes to allow us to develop a better or more complete understanding of what a given story will entail thus giving us the insight needed to build more complete Sprint plans.
Reviewing the Sprint Plan
We review our Sprint plans to look for mistakes we commonly make. We’ve gone as far as enumerating the mistakes we make most often to help us look specifically for those as we do Sprint planning. Most of these are different flavors of not applying our “definition of done” and thus ending up with incomplete plans. If your goal is to develop challenging plans but plans that you’re likely to deliver on, then trying hard to ensure your plans are complete is important.
Note that none of the above should be intended to suggest that we value immutable Sprint Backlogs or task assignments. We can and do frequently grow and shrink the Sprint Backlog as the team uncovers more information about what’s needed to deliver the committed Product Backlog. Similarly, we shuffle (and re-estimate) tasks regularly. What we don’t do is allow significant parts of the work to go unplanned or unassigned at the point we decide what we’re committing to deliver.
Beyond Yes or No
Beyond improved Sprint planning, the second critical aspect for us in delivering committed Product Backlog in a Sprint is how we deal with falling behind. I frequently say in delivering Scrum training that if someone comes to you asking if a bunch of features can get done given fixed resourcing by a given date, that the best of all possible answers is “yes”. The worst of all possible answers is “no” – but not because you’re delivering bad news but rather because saying “no” reinforces the fallacy that that decision is really binary in nature and ignores the great value to be gained by digging into the details to see what’s actually possible.
Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.
We once had a Sprint on a tool development project that had fallen far behind – it appeared that no amount of plan scrubbing or task shuffling would allow us to deliver the committed Product Backlog by Sprint’s end. We met with the Product Owner with the intention of choosing Product Backlog to remove from the Sprint. In the course of conversation though, the Product Owner got a better feel for the approach the team was taking in developing one specific item – the item that was driving most of the over-run. Collectively, they realized that the approach was fancier than was really required and in short order sketched out an alternative. We immediately revised our Sprint Backlog to remove the old approach and built a plan for the new one – in about an hour, we went from hopelessly behind with no chance of delivering the complete set of Product Backlog to being close to on schedule. I think having a strong team desire to deliver the whole of the selected Product Backlog was key to making this happen.
Anecdotally, I can say that my colleagues and I worked hard to improve our Sprint planning and replanning practices and pretty quickly found ourselves doing much better in meeting our Product Backlog commitments. For example, during one ten month stretch, I counted 93% of Product Backlog items delivered on time in the Sprints in which they were planned. This isn’t the only thing that matters but it made a big difference to us and our stakeholders: it gave us confidence in the team.
Conclusions
Use the Sprint Goal to capture over-arching but incremental project goals if this concept is meaningful to you and if goals like these are more meaningful commitments than would be the selected Product Backlog – but definitely don’t use the Sprint Goal as a crutch to support poor Sprint planning practices.
Don’t let the Scrum canon hinder your team’s thinking when tuning your process to better satisfy your business needs – the canon wasn’t created to limit your thinking.
And above all, don’t believe that your team won’t be able to reliably commit to the selected Product Backlog Sprint over Sprint – you almost certainly can and, if your team and your stakeholders value this, then by all means pursue improvements in this area.
I’d like to thank Anne Greenhaw, Selaine Henriksen and Ryan Martens for their help in developing this post. Thanks to Ryan also for inviting me to post here.
About the Author:This is the first guest blog post of Ed Willis. Ed was a soldier, a cab driver, a security guard, a tree planter, an auto glass installer and shop manager, an employee of several bookstores, a house painter, a dish-washer, and a foot messenger, among at least a few other things before buying his first computer. Since then he has worked as a research assistant at Queen’s University, driven a data mining company into the ground and ridden Nortel Networks nearly all the way down. He currently works for company in telecommunications. Born in NY, NY, he now lives in Ottawa, Ontario.
Last summer, Rally started a video series called “Chalk Talks“.
I was fortunate enough to have filmed several“Chalk Talk” videos about some of the basics of Agile software development (The Agile Manifesto, Scrum Basics, Iteration Demo and Review Meeting, and other topics).
We also tapped into the wisdom of some of our other Agile Coaches: Julie Chickering, Mark Kilby, and Ken Clyne.
Our Rally Chalk Talks are informal videos, typically 3 – 5 minutes long, intended to provide quick, easy introductions to Agile topics.
Filmed in a short, tutorial format, these videos are great to share with your team as they are getting up to speed on Agile.
To get a feel for our latest work, here’s Rally Agile Coach Ronica Roth in her great Chalk Talk on User Stories. ( during which you can find out why a dog would want his own laptop :D)
Be sure to check out our entire catalog of Chalk Talks and subscribe to our YouTube channel if you’d like to be notified when we publish new videos. We already have two more Chalk Talks queued up: “Kanban and Scrum” and “Agile and Lean”.
As you look through our current catalog of talks, be sure to let us know what other topics you’d like us to cover in future talks.
For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”
I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie. There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile. Now is not the time to stop and eat.
For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.
I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :
a defined a bar that is deep in skill, knowledge and practice
a significant enough bar to engage College and University study and examination
research and curriculum that explore the tough questions in a scientific method
development of more flexible or “T” shaped individuals that can see and work beyond silo roles.
I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:
I encourage everyone in our community to figure out how to put energy toward one or more of these efforts. The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking. Thus broader education and difficult certification helps create a “Community of Thinkers.” And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.
According to the Systems Thinking Toolbox from Pegasus Communications,to break an Escalation structure, ask the following questions:
What is the relative measure that pits one party against the other and can you change it?
What are the significant delays in the system that may distort the true nature of the threat?
What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?
So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”
Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?
Here is an example:
I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post. I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.
I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.
Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.
In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.
Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.
So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend. If in our community we really “must win” in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.
What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.
Here is a simple formula for bringing your viewpoint to bear without escalation:
Show up. (Be willing to be engaged.)
Find out what has meaning to you. (Be willing to be honest about your perspective.)
Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
Let go of what happens. (Be courageous enough to allow others to agree or disagree.)
I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.
I have some more mental models I want to offer here. But they will wait for another post.
Thank you in advance for your considerations, insights, and comments.
In the last month, I have gotten the question “Where does Agile *not* work?” numerous times, mainly from large firms planning their first Agile rollout efforts. That question is quickly followed by, “And I don’t want to hear that it works everywhere!”
Admittedly, that’s a tough one for me. My answer is that Agile approaches can be applied anywhere – from your home moving project to the creation of space crafts. So I usually flip the question. If Agile conceivably could work anywhere, the question is really, “On which projects do you choose to start your Agile adoption?”
Where To Start
Jean and I and our fellow Rally coach Ronica Roth tend to apply two criteria: the strategic importance and risk of the effort. The iterative nature of Agile development is going to provide you with the tools to steer a risky and highly strategic project much better than phased development approach.
Our rendition from "Stand Back and Deliver"
In their new book Stand Back and Deliver, Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald provide a more elaborate portfolio model to assess your efforts. They map uncertainty versus complexity in a 2×2 matrix with nice labels of colts, bulls, sheepdogs and cows. I find the model is very effectively elaborated in the book and some very useful implications for staffing, selecting and managing the value flow are discussed. The variables used in the book include:
Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies
Three Perspectives
We agree with the authors, the best place to start using Agile practices are projects that are High Uncertainty (because you leverage Agile to learn as you go) and Low Complexity (to avoid the headaches of technical risk).
If the risk to the business is significant, such as eroding market share or the possibility the project will be canceled, then accept the technical risk and use Agile for a High Uncertainty-High Complexity project. The use of Agile will help with the uncertainty. It will be important on those projects to increase the discipline level around process and communication.
Projects of Low Uncertainty and Low Complexity rank third. They could easily transition to Agile and benefit from the improvements to productivity, quality, and collaboration. Yet they don’t need Agile to be successful. For these projects, the tie-breaker may be the next set of criteria – the environment.
Environmental Factors
Once the project is right for Agile by its nature, the next question is whether you can quickly create an environment for success. Many people talk about this as the organizational readiness for Agile or assess these concepts via Agile team assessments. Here is a snippet of that kind of team assessment:
Does the Product Owner have the right level of authority and influence? Are they…
Embedded with team?
Dedicated to the project?
Able to gain consensus from stakeholders on goals and features?
Able to evolve the product backlog (with training)?
Able to support the team through constant feedback and decision-making?
The team is dedicated to the work being planned using Agile (note: The team could actually work on multiple projects, as long as they are working a single backlog and work from all projects is scheduled via Agile planning cycles).
ScrumMaster, Product Owner, Product Development and Quality Assurance must be full-time dedicated resources.
Other resources might be part-time for any one Scrum team, but they should be spread across as few Scrum teams as possible. These include: Database, User Education, Apps Architect and Ops Architect.
Architects might be contributing members, or might be advisory.
Is the team co-located?
It’s not required, but can be a risk factor.
For distributed teams, it is important to have good communication constructs, and to have a leader in remote locations to partner with the ScrumMaster and Product Owner of the core team.
Do you have an Uber Product Owner and Uber ScrumMaster?
For multi-Scrum-team projects, it is important to have an overall Product Owner and ScrumMaster to own releases and communication across teams.
Is there a controlled build environment?
To ensure quality and a smooth flow of work, the team should be able to provide QA with builds multiple times during a two-week sprint.
As a Scrum team matures, and to increase velocity, the team will want to integrate code to a shared dev environment continuously (at least daily).
You can get a copy of Rally’s Team Agility Assessment and we welcome your feedback. I hope you will buy their book and try team assessments to help you map your own approach. To me, Agile works everywhere, it is just a question of how good do you want to be and by when.
“The greatest obstacle to discovery is not ignorance – it is the illusion of knowledge.” – Daniel J. Boorstin
Here’s something your team should look to avoid – Cargo Cult Scrum.
Members of the John Frum cargo cult
Cargo Cult Scrum is what happens when you adopt the practices, vocabulary, and artifacts of scrum but you don’t understand why or how they work. Cargo Cult scrum is bad. It is accidental and is based on ignorance.
Here’s a tiny piece of what Wikipedia has to say about cargo cults:
“A cargo cult is a type of religious practice that may appear in tribal societies in the wake of interaction with technologically advanced, non-native cultures. The cults are focused on obtaining the material wealth of the advanced culture through magical thinking, religious rituals and practices…”
When we talk about cargo cult implementations of scrum we are talking about people who seize on the advanced ideas of scrum and expect magical, unexplainable benefit to come from them, not realizing that informed usage is required in the bargain.
Craig Larman and Bas Vodde talk briefly about Cargo Cult Scrum adoption in their excellent book “Scaling Lean & Agile Development” in a section titled Avoid…Fake ScrumMasters. Fake ScrumMasters are created by “…Changing the title of someone to ‘ScrumMaster’ while he acts like – and is encouraged by the organization to act like – a project manager.”
They go on to describe the ultimate cargo cult scrum implementation:
“We adopted Scrum. Our Sprint length is the length of our project. The Product Owner decides the items in the Sprint and the project manager acts as ScrumMaster. He makes the Sprint Backlog and assigns the tasks to people in the team.”
So what does Cargo Cult Scrum look like?
Here are some examples that I’ve seen in the field:
I recently attended a meeting at a company that considers itself to be agile. It was a regular meeting that occurred every two weeks. It was not attended by a scrum team, but instead by a bunch of people from two different groups. The three questions were not used. The meeting was scheduled for, and took, 30 minutes. Yet the meeting was called a scrum. Other meetings at this company are called scrums, so much so that ’scrum’ has become a synonym for ‘meeting’. This is a cargo cult. The true meaning of ‘daily scrum’ has been lost, if it was ever apprehended in the first place.
I’ve also seen organizations in which people call every item on the Product Backlog a User Story (which is not the same thing as every item on the Product Backlog actually being a user story).
Another example is this actual [paraphrased] conversation I had with a potential customer:
Customer: Oh yes, we’ve been doing agile for a while. Coach: That’s great! So you haven’t had any trouble getting the Product Owner to work closely with the team? Customer: Well, we…uh…don’t really have a Product Owner. Coach: Oh. Well, who keeps the Product Backlog in shape? Customer: Well, we…uh…don’t really have a Product Backlog, per se. Coach: Oh. So how do you plan your sprints? Customer: Well, we really don’t do that in a very formal way. But we do meet every morning. That’s what it’s all about, right?
And my all time favorite. I was once told by a manager of a supposedly Agile group: “We like things the way they are. We know it’s not perfect. We don’t want to change.” Yikes. So much for Continuous Improvement.
Though you shouldn’t do Cargo Cult Scrum for any reason, the reality is that any step down the road to scrum is usually better than whatever preceded it.
Don’t feel bad if your scrum implementation isn’t the same as what’s in the books. Feel bad if you are have stopped trying to make it better.
About the Author: Alan Atlasis a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.
One of the replies on the Agile Alliance Group of Linked-Incountered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.
“The term Oxymoron originates from the Greekoxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.” Wikipedia’s Etymology for Oxymoron
Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.
Agile as an umbrella term
First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code. It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.
My rendition of the geneology of Software Development Approaches
Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.
I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.
Lean merges with capital-A Agile
I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.
Small batch sizes, short cycles that create rhythm
Reduction in queues through pull
Reduction in work in process inventory
Design quality in
Stop-the-line defect control
Value streams the link to the customer
Integrated learning through reflection
Last responsible moment decision making
These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD. I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me.
What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?
At Rally, we often get questions about how Agile fits in with a variety of other practices and processes, so the below questions about Agile and CMMI, Agile and RUP, and Agile and Architecture come as no surprise. Stay tuned for the final Q&A on Agile champions.
DW – is Dave West from Forrester
RAM – is Ryan Martens from Rally
How can Agile be integrated in a CMMI certified application in regards to the tremendous amounts of required CMMI artifacts (documentation)?
DW – The flippant answer is it can’t. ☺ But actually I have seen some great systems integrators use CMMI to help check list their processes of which some of those processes are Agile. Agile development works really well at the team level, but it needs to be surrounded with other processes. CMMI makes sure you remember those processes, some of which are inside the Agile team, others are not. The PA’s always seem to imply lots of documentation, but they do not have. You can keep the documentation to a minimum, but still deliver them. Do not, however, burden the Agile team with proving their compliance – Use the checklist, build the software and get others to prove they did what they said they did.
RAM – I am not quite as negative as Dave on this topic. CMMI and Agile combine just fine. There are a number of proof points that are easily found from past Agile conferences and by searching “Agile and CMMI.” The problem is that many folk misinterpret CMMI and are convinced that it mandates waterfall, heavy process and heavy documentation. According to SEI, it does not. Most teams would not adopt CMMI without a specific business need.
The other day, I noticed that the water is draining rather slowly out of my bathtub at home. That is annoying…
It means that I haven’t really kept my drain as clean as I should. Or perhaps I should be “snaking” the pipes more regularly. One thing for sure, if I don’t get this fixed, eventually my tub will stop flowing entirely. If I try to add water, my bathtub will just overflow and I won’t be able to use it without a major plumbing expense. Ugh!
What does this have to do with my latest topic of cutting costs with Agile development? Well, I’ve been reading a great little book by Linda Booth Sweeney, When a Butterfly Sneezes. It’s a sweet, simple way to learn about systems thinking by using children’s stories for examples of various systems’ archetypes. To kick things off she uses a bathtub analogy to explain stocks and flows and how they impact one another.
Aha! That is what I care about when I am developing software!
Imagine that the faucet to my tub is all the features I am putting into my product. My bathtub is my product stock. As I add features, my bathwater level goes up. Now think of the drain as the “flow” by which I get the “stock” out to my customers.
If my drain is clogged up even a little, I can’t get the flow of features, my value, out to my customers as quickly as I’d like. And if I have a really bad situation, then I actually can’t keep adding features into my stock (my bathtub) because it will just overflow. Features (value) will never get to my customers. They’ll just end up as a major mop up for me, lots of work that doesn’t deliver anything but frustration.
So what are the clogs in my software bathtub? Defects.
A few defects unattended to will just slow down my value delivery. Not too bad. But if I allow defects to accumulate, that technical debt can bring my value delivery to a crawl. I’ve got lots of stock and yet my inattention to defects has cut off flow to my customers. Crumb.
Agile cuts costs because it requires us to keep our drain clean, not let defects accumulate. Agile guides us to not over-emphasize adding features to our tub while disregarding accumulating defect residue. Rather, we are guided to add high-quality features with a zero-defect mentality. Think of it this way -
Adding a little Scrum will help you eliminate the scum.
Now, whenever you are ready to open the drain for a release of software, there are no last minute plumbing repairs necessary to let the value flow. Keeping the drain defect-free means I can keep adding features into my stock and let them flow out anytime I want. I can even have sustainable, even continuous, inflows and outflows to and from my stock. The cost of delivery of value slowly goes down, I have sustainable and reliable flow, and all because I was willing to do a little continuous bathtub maintenance.
Don’t let defects clog your feature bathwater. Use Agile to stop the defect clogs and keep the value water flowing!
RallyDev.com
I recall being pretty confused about what the team was committing to in Sprint planning after reading Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, for the first time. There seemed to be some ambiguity around whether the Scrum Team commits to the set of selected Product Backlog items or to the Sprint Goal, which is a higher level and less precise concept. A couple of quotes from that book will help illuminate the situation:
Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.
About the Author: This is the first guest blog post of Ed Willis. Ed was a soldier, a cab driver, a security guard, a tree planter, an auto glass installer and shop manager, an employee of several bookstores, a house painter, a dish-washer, and a foot messenger, among at least a few other things before buying his first computer. Since then he has worked as a research assistant at Queen’s University, driven a data mining company into the ground and ridden Nortel Networks nearly all the way down. He currently works for company in telecommunications. Born in NY, NY, he now lives in Ottawa, Ontario.
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
Efficiency
