Category Archives: How-To Apply Agile

Practical or step-by-step advice and descriptions on how to do various agile practices.

10 Statements You’ll Hear In a Maturing Agile Team

Learn more about transforming people, process and culture with the Real Agility Program

players-playing

A maturing agile team functions quite differently than any other team environment. Here are 10 examples of statements you’ll hear in a developing agile team.

 

  1. “Change is to be expected. Change is welcomed and embraced.”
  2. “Your work is already fantastic but the team is growing. How can we support you in developing the skills to adapt to our advancing team?”
  3. “You need to change. So do we all. What can we put in place as an organization to support this advancement?”
  4. “Let’s do an experiment. It might be right or it might be wrong but we won’t know until we try, learn, reflect.”
  5. “No one is to blame.”
  6. “Sure. We have all made mistakes but pointing them out gets us nowhere. We can say instead, ‘I am learning how to do… ‘such and such’ in a more effective way,’ and move forward confidently.”
  7. “Let’s talk about this with the whole team.”
  8. “Let’s take a vote.”
  9. “Let’s keep doing our work as we sort this out. Maturing teams mature when individuals keep doing their positive work.”
  10. “You have a choice about what work you do, when and how.”

Scott Ambler writes more on Agile teams in his article Roles on Agile Teams: From Small to Large Teams and elaborates on how “generalizing specialists” are the key to successful cross-functional teams. He writes, ” Generalizing specialists are the sweet spot between the two extremes of specialists, people who know a lot about a narrow domain, and generalists who know a little about a wide range of topics.”


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Agile Teams Bend But They Don’t Break

Learn more about transforming people, process and culture with the Real Agility Program

In an out-dated model of work environments, there are clear “rights” and clear “wrongs.” Usually, the management or leadership determines this and they call it “Policies and Procedures” or “Mandates” or simple “Rules.” There are usually severe consequences for not following these, intentionally or accidentally.

In the new and emerging agile model, where team members focus their attention on taking action with little planning, reflecting, learning and planning frequently work environments are very different.

Instead of looking for people to blame when challenges emerge, an agile team looks for ways to learn and develop. The team can collectively embrace new ways to adapt to change together.

This is one of the things I am learning about in high-functioning agile teams.

I like the way Brian Milner addresses this in his article “6 Ways to Bring  Humility to your Agile Leadership Style.”


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Review: Switching to the Agile Mindset

Learn more about transforming people, process and culture with the Real Agility Program

Recently, I discovered a well-written article on Scrum Alliance posted from a member entitled “Switching to the Agile Mindset.” In this article, the author lists six key components of the transformation individuals and teams go through as they adapt more agile mindsets and approaches to their work. I found this article ideal for new coaches and also useful for people on the team who may feel challenged by the switch.

The part which stands out for me the most is the phrase, “Change acceptance develops agility in a team.”

This concept is enshrined in the Agile Manifesto itself. Being able to adapt well to change is the cornerstone of the new mindset and a high-functioning agile team.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Thinking About the Agile Manifesto

Learn more about transforming people, process and culture with the Real Agility Program

Often times, as I’ve been researching about agile methods and how to apply these to create real and sustainable change in an organization, I come across reference to the Agile Manifesto. I list it here today for those who are new to the field or who are getting back to the roots after trying a few things with different-than-expected results. It is an instrumental document. The values and principles listed here truly do shape the way agilists think and operate and to some degree or another the results appear to be better than before this founding document was introduced. So here is my “hats off” to this remarkable item which plays a pivotal role in cultural transformation.

The four key values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Personally, I find the first one the most meaningful of all. When we value individuals and interactions over process and tools we are truly improving in leaps and bounds in creating collaborative environments which are continuously improving.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Sometimes Waterfall is Needed to Become Agile, Scott Granieri

Learn more about transforming people, process and culture with the Real Agility Program

I like reading success stories. In fact, I wish there were more of them in the agile literature because a success story is “evidence” of doing something that works and it is not just an abstract idea or concept with potential. That’s one of the reasons I like Scott Granieri’s article featured on scrumalliance.org entitled, “Sometimes it just may take a waterfall to go agile.” In this article, Granieri describes a situation occurring at a corporate level to create software for a federal customer. He presents the background, the problem, the solution, the results and the lessons learned. I find this article to be well-written, thorough and engaging.

Here is an excerpt from his conclusion:

“The solution for creating a successful environment for Agile adoption lies within one of the principal tenets of the methodology itself: Inspect and adapt.” He also quotes Ken Schwaber, co-founder of Scrum, who Mishkin Berteig trained with more than a decade ago. But that can be something for you to discover when you read the article.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Craig Larman – Less Agile or LeSS Agile?

Learn more about transforming people, process and culture with the Real Agility Program

Certified Less Practitioner Badge

Craig Larman, co-creator of LeSS, recently wrote a riveting article about agility now featured on Scrum Alliance Spotlight. The article, entitled “Less Agile or LeSS Agile?” reminds readers of the beginning moments of agile and how this word was selected because it fundamentally described a condition of being able to adapt quickly to change.

About that founding meeting, he quotes Martin Fowler as saying, “We considered a bunch of names, and agreed eventually on “agile” as we felt that captured the adaptiveness and response to change which we felt was so important to our approach.” Larman continues to elaborate on how this agility is not meant to be a practice solely for the purpose of “creating more efficient teams who deliver high-quality faster,” although of course this is a natural outcome when teams are agile.

But he takes the concept to a deeper level. He writes, “I like to say that the goal of agile approaches, including Scrum, is to discover successful solutions by being able to … turn on a dime for a dime.”

Therein lies the beauty of being agile. When we are discovering successful solutions and implementing them quickly, even with very little planning, then we are embracing the fundamental essence of agility.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Decluttering Photographs: A Scrum Mindset

Learn more about transforming people, process and culture with the Real Agility Program

A common Scrum myth is that Scrum teams don’t keep documents. The many sticky notes on the wall of a scrum room can be anxiety-provoking to traditional suit-and-tie folks. Formal documentation is considered to be the hard product of real work. But the truth is two-fold.

First, Scrum teams do keep documents: The product backlog and the sprint backlog, which are two of Scrum’s artifacts, are key documents for a Scrum project. Each has a precise role in moving the scrum team from product conception to shippable increments. Different teams or organizations keep these artifacts in formats that suit them, but the point is that they do.

Second, it is not true that all formal documents are a faithful (or useful) reflection of work. More often than not, it is not clear what they’re for. Team members typically keep documents in the hundreds, outdated files are seldom deleted and clean versions are often mixed up with drafts. As with all clutter, the 80-20 rule applies rather well here: 20% of documents supports 80% of the work effort. So, 80% of formal documentation is in fact clutter.

Adopting Scrum will challenge organizations to focus on nothing other than completing deliverables of highest value to customers. This focus is in fact reflected by the few but super-useful documents that Scrum teams keep. But to move into this state of razor-sharp focus, we need a clutter-free environment. And while there are many forms of clutter on the job, documents are a big one. Why? Because the documents we keep and the way we use them reflect how well we understand our role. Much like a divinatory tool, the collection of documents you keep are very telling of how you do your work. Is there an orderly process as would be reflected by an orderly and well-organized set of a few focused documents? Or is it a firefighting role as would be reflected by a random set of documents contrived into folders?

Decluttering work documents compares rather precisely with decluttering photographs. Both clutter categories bring up very similar levels of emotional and intellectual charge as well as frustration with the sheer volume that needs to be processed and purged. And unlike the ease of throwing out something bulky like a broken chair or a dulled out piece of clothing, decluttering documents and photographs are very daunting tasks whose detail will bring anyone to tears.

Office documents are very much like a typical photo collection by enthusiastic parents: Several hundred photos of Maxi kicking ball, three dozen photos of the tenth birthday cake, one whole album of Auntie over for dinner, and so on. Photos will range from the incognito-fuzzy to the acceptably crisp. All are equal, however, and are kept in bulging pounds of photo albums or hard drives ranging in the terabytes – or both.

You can see the similarity with documents: Several hundred versions of the scorecard, three dozen presentations on the same topic, a few thousand archive files, and so on. ‘Fuzzy’ documents surely make up the majority. They include the many versions with corrections, inputs and errors, and the older versions to name just a few. The ‘crisper’ documents are typically the most recent ones and likely the ones shared with the VP. But these soon become ‘fuzzy’ as new versions are produced. The main issue with documents is knowing exactly what they’re for and how they support value-adding processes; a problem that doesn’t exist in a Scrum framework.

The main thread of comparison between photos and work documents is the degree of psychic severance that must take place in the mind in order to be capable of throwing out the useless lot. In truth, decluttering photographs is one of the hardest categories to tackle and does not happen until one has built a strong decluttering muscle with simpler categories like clothes, shoes, pots, pans and the like. Because photographs fall under the ‘sentimental’ umbrella, it takes much more than simply assessing functionality. Instead, it requires:

  1. An assimilated understanding of how to declutter, which means having built the decluttering muscle with simpler categories of stuff and having the gut to make sharp decluttering decisions,
  2. A willingness to look squarely at the past and contrast it with today, which basically means grieving and all the complex steps that alone involves, and
  3. A decision about what will be taken into the future, which must be actively considered as opposed to simply assuming that it’s what remains after decluttering the unwanted.

Releasing the way we create, share and keep documents is tantamount to releasing the way we work. That’s why decluttering documents is loaded with anxiety about how the future modus operandi will look like. An additional consideration here is to do this before anything is archived because if all the old is just moved into an archive, no one will open it because everyone subconsciously knows of all the mold that’s growing in there. So better not postpone the pain and roll with the punches. Taking a sword at opening each and every single file and processing for keep-dump-or-change, takes a lot of gut and staying power. Our attachment to documents is quite entrenched but it must be severed for the sake of agility.

The result of genuinely decluttering photographs is astonishing. The grieving process can be very intense; not only are issues resolved and dropped but pieces of the past are recalled into the present and the spirit regains integrity. The past is forgiven and the remains of the day are a powerful collection of sharp moments that are very much alive. Photographs are no longer nostalgic snapshots of the past but evidence of an assimilated experience in effect today. And with that, something very special happens: Fewer and fewer photographs are taken as soaking up a moment becomes far more precious than clunking through photographing it. This vulnerability to the passing of time is a key ingredient for living life intelligently.

Can you draw the parallels with documents? We spend most of our days at work. So, let me invite you to start tackling your collection and see how your newfound awareness pours into every other area of your life.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Question: Product Owner and Technical Debt

Learn more about transforming people, process and culture with the Real Agility Program

Question from Meredith:

As a product owner, what are the best ways to record technical debt and what are some approaches to prioritizing that work amid the continuous delivery of working software?

Answer:

Hi Meredith! This is an interesting question. I’ll start by answering the second part of your question first.  The two most common ways of handling technical debt, quality debt and legacy debt are:

  1. Fix as you go. The Scrum Team works on new PBIs every Sprint, but every time a PBI touches a technical, quality or legacy debt area, the team fixes “just enough” to make the PBI implementation have no debt.  This means that refactoring and the creation of automated tests (usually through TDD) are done on the parts of the product/system that have the problems.
  2. Allocate a percentage. In this scenario, the Scrum Team reduces its velocity (sometimes significantly) to allow for time to deal with the technical, quality and legacy issues. This reduction could be adjusted every Sprint, but is usually consistent for several Sprints in a row.

In both approaches, the business is paying for the debt accumulated, and the cost includes an “interest” fee.  In other words, the sooner you fix technical, quality and legacy debt, the less it costs.  This approach to thinking about your product/system is essential for long-term sustainability.  One organization I worked with took three years working on their system to clean it up without being able to add any new features!  Don’t let your system get to that point.

Now to the first part of your question…

As a Product Owner, you shouldn’t really be making decisions about this cleanup work. Your authority is limited to the Product Backlog which should not include technical items. The only grey area here is with defects which may be hard to classify as either fully business or fully technical. But technical design, duplication of code, technical defects, and legacy code all are under the full authority of the Scrum Development Team. Practically, this means that every Sprint the team has the authority to choose however few PBIs they feel they can take while considering the technical state of the product/system.  We trust and respect the team to make wise decisions.

Therefore, your main job as a Product Owner is to provide the team with as much information as possible about the business consequences of the work they are doing.  With strong communication and collaboration about this aspect of their work, the technical members of your team can make good trade-off decisions, and balance the need for new features with the need to clean up previous compromises in quality.

A final note: in order for this to work well, it is critical that the team not be pushed to further sacrifice quality and that they are given the support to learn the techniques and skills to create debt-free code.  (You might consider sending someone to our CSD training to learn these techniques and skills.)

Using these techniques, I have been able to help teams get very close to defect-free software deliveries (defect rates of 1 or 2 in production per year!)

Let me know in the comments if you would like any further clarification.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Real Daily Scrum

Learn more about transforming people, process and culture with the Real Agility Program

On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

9 Agile Estimation Techniques

Learn more about transforming people, process and culture with the Real Agility Program

Many people have used a variation of Planning Poker to do Agile estimation.  Here is a reference of 9 different Agile estimation techniques for different circumstances.  I have seen all of these techniques work in practice, except one.  Try a new one each Sprint!

Planning Poker

Participants use specially-numbered playing cards to vote for an estimate of an item.  Voting repeats with discussion until all votes are unanimous.  There are lots of minor variations on Planning Poker.  Good technique to estimate a very small number of items (2 to 10).

The Bucket System

Using the same sequence as Planning Poker, a group or a team estimate items by placing them in “buckets”.  The Bucket System is a much faster Agile estimation technique than Planning Poker because there is a “divide-and-conquer” phase.  The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated (50 to 500).

Big/Uncertain/Small

For super-fast Agile estimation, the items to be estimated are simply placed by the group in one of three categories: big, uncertain and small.  The group starts by discussing a few together, and then, like the Bucket System, uses divide-and-conquer to go through the rest of the items.

TFB / NFC / 1 (Sprint)

This Agile estimation technique is similar to Big/Uncertain/Small but puts a specific “size” into the mix, namely 1 Sprint.  The categories are “Too F-ing Big”, “No F-ing Clue” and “1” Sprint (or less).  I learned this one recently from someone in one of my CSPO classes.

Dot Voting

Dot voting is usually considered a decision-making tool, not an Agile estimation technique.  However, for estimating small numbers of items, dot voting can be a super-simple and effective technique.  Each person gets a small number of “dots” and uses them as votes to indicate the size of an item; more dots means bigger.

T-Shirt Sizes

Items are categorized into t-shirt sizes: XS, S, M, L, XL.  The sizes can, if needed, be given numerical values after the estimation is done.  This is a very informal technique, and can be used quickly with a large number of items.  Usually, the decisions about the size are based on open, collaborative discussion, possibly with the occasional vote to break a stalemate.  There is a brief description of T-Shirt Sizes here.

Affinity Mapping

Items are grouped by similarity – where similarity is some dimension that needs to be estimated.  This is usually a very physical activity and requires a relatively small number of items (20 to 50 is a pretty good range).  The groupings are then associated with numerical estimates if desired.

Ordering Protocol

Items are placed in a random order on a scale labeled simply “low” to “high”.  Each person participating takes turns making a “move”.  A move involves one of the following actions: change the position of an item by one spot lower or one spot higher, talking about an item, or passing.  If everyone passes, the ordering is done.  The Challenge, Estimate, Override and the Relative Mass Valuation methods are variations on the ordering protocol.

Divide until Maximum Size or Less

The group decides on a maximum size for items (e.g. 1 person-day of effort).  Each item is discussed to determine if it is already that size or less.  If the item is larger than the maximum size, then the group breaks the item into sub-items and repeats the process with the sub-items.  This continues until all items are in the allowed size range.

Principles of Agile Estimation

Agile estimation techniques are collaborative.  All appropriate people are included in the process.  For example the whole Scrum team participates in estimating effort of Product Backlog Items.  Collaborative techniques are also designed so that it is impossible to blame someone for an incorrect estimate: there is no way to trace who estimated what.

Agile estimation techniques are designed to be fast (-er than traditional techniques) and deliberately trade off accuracy.  We are not trying to learn to predict the future… or get better at estimation. Instead, we recognize that estimation is a non-value added activity and minimize it as much as possible.

Most Agile estimation techniques use relative units.  This means that we don’t try to estimate dollars or days directly.  Instead, we use “points” or even qualitative labels and simply compare the items we are estimating to each other.  This takes advantage of the human capacity to compare things to each other and avoids our difficulty in comparing something to an abstract concept (such as dollars or days).

Check out my recent “Agile Planning in a Nutshell” article.

What Other Agile Estimation Methods Are There?  Please let me know in the comments and feel free to include a link!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Collaborative Estimation Technique: Challenge, Estimate or Override (CEO)

Learn more about transforming people, process and culture with the Real Agility Program

Great technique described by Shahin Sheidaei on his blog: Challenge, Estimate or Override (CEO) Game for Effective Estimations.  It is much quicker than the Planning Game, and probably a bit slower than the Bucket System.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Insight from a new Scrum Master

Learn more about transforming people, process and culture with the Real Agility Program

I recently had the pleasure of doing some coaching with someone who is new to Scrum and has taking on the role of the Scrum Master as part of a team of teachers.

Edwin Portfillo - Scrum Master
Edwin Portillo  – (c) Copyright Edwin Portillo, 2015

Last week, I unexpectedly received this email from him. I wanted to share it as a thought for other new Scrum Masters in the making…..

I’m beginning to understand that being a SM involves me not coercing people into following a specific task but guiding them into  deciding as a group what must be done for the team to move efficiently.

“We never want to be in a position where 100% of the work is 80% done.

On the other hand, if 80% of the work is 100% done, you have a qualified success.”

 Edwin Portillo
High School teacher (Scrum Master – The Teaching Team)
Hope High School / Blueprint Education

As you can see, Edwin has come a long way already in his understanding of the role. Please feel free to share your Positive comments with Edwin if you wish.  I’m sure he’ll appreciate it :->

I’ll start…  Thanks Edwin for taking the time to really think about how your actions should impact your team. Thank you for sharing your ideas with new Scrum Masters in such a simple and effective way.

Mike Caspar
Passionate About Agile

References: 

Scrum – http://www.scrumalliance.org
Hope High School – https://www.facebook.com/hhsdiamonds
Blueprint Education – https://www.blueprinteducation.org/about


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Planning in a Nutshell

Learn more about transforming people, process and culture with the Real Agility Program

Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans.  However, many teams desire a long-term plan.  This can be thought of as a roadmap or schedule or a release plan.  Agile planning helps us build and maintain long-term plans.

Agile Planning Process

The steps to do this are actually very simple:

  1. Write down all the work to be done.  In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
  2. Do some estimation of the work items.  Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes.  These tools can be applied to many types of estimation.  There are three kinds of estimation that are important for Agile Planning:
    1. Estimating relative business value.  Usually done with the business people including customers and users.
    2. Estimating relative effort.  Usually done by the Agile team that will deliver the work.
    3. Estimating team capacity.  Also done by the Agile team (this is sometimes called “velocity”).
  3. Create the long-term plan.  Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work.  (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.)  Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.

Agile planning allows a team to update estimates at any time.  Therefore, the techniques used above should not be thought of as a strict sequence.  Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated.  Scrum refers to this ongoing process at “Product Backlog Refinement”.

Principles of Agile Planning

In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:

  1. Speed over accuracy.  We don’t want to waste time on planning!  Planning in and of itself does not deliver value.  Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
  2. Collaborative techniques.  We don’t want to be able to blame individuals if something goes wrong.  Instead, we create safe estimation and planning techniques.  Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
  3. Relative units.  We don’t try to estimate and plan based on “real” units such as dollars or hours.  Instead, we use ordering, relative estimation and other relative techniques to compare between options.  Humans are bad at estimating in absolute units.  We are much better at relative estimation and planning.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Change On-the-Fly Learnings Into Lasting Improvements

Learn more about transforming people, process and culture with the Real Agility Program

Teams encounter and solve many EP!C challenges as they deliver their Product Backlog items. During Retrospectives, teams may struggle to recall their challenges/learnings and may miss an opportunity to adapt their behaviour for future work cycles.

I thought of two fun ideas to help teams keep this EP!C stuff top of mind:

  1. Get a milk carton with a cut out (call it a “Treasure Chest”), supply some sticky notes and sharpies, and have the team deposit new notes as they happen during their work.
    • When the team gathers for a Retrospective they can retrieve these treasures and discuss them.
  2. Create a “Parking Lot” on the wall in the team area where they can post sticky notes during their work periods. These 3 questions can help them focus items that they post:
    • What did you learn during this Sprint/Cycle that you want to share with the team?
    • What did you learn during this Sprint/Cycle that you want to share with other teams?
    • How might your stakeholders help or support your team and how might dialogue with them be initiated?

I pitched these ideas to my team and they loved both and they decided to experiment with the 2nd above. On Day 2 of a recent Sprint, I was amazed to see how many ideas had been posted in just 2 days. Not only does it include learnings/challenges, but it also includes items that can integrated into our Definition of Done in the future.

Submitted by Lisa Serrentino.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Pitfall of Scrum: Stretch Goals

Learn more about transforming people, process and culture with the Real Agility Program

The team decides on how much work it will do in a Sprint. No one should bring pressure on the team to over-commit. This simply builds resentment, distrust and encourages low-quality work. That said, of course teams can be inspired by challenging overall project or product goals. A stretch goal for a Sprint is just a way to 100% guarantee failure. Even the team should not set its own stretch goals.

There are a few interesting principles that apply here. For example, the Agile Manifesto mentions sustainability:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The Agile Manifesto also points out the importance of trust:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Stretch goals are incompatible with both of these principles from the Agile Manifesto.

There are two types of stretch goals. The first type are those assigned by outsiders to the team. The second type are those which a team sets for itself. Both types are bad.

Stretch Goals Assigned by Outsiders

The worst extreme of this type of stretch goal is also the most common! This is the fixed-scope-fixed-date project deadline. In this type of stretch goal, the project team, doing Scrum or not, is forced to work backwards from the deadline to figure out how to get the work done. If the team can’t figure this out, managers often say things like “re-estimate” or “just get it done.” (Note: another thing that managers do in this situation is even worse: adding people to the project! Check out “The Mythical Man-Month” by F. Brooks for a great analysis of this problem.)

My anecdotal experience with this sort of thing is simple: quality suffers or sustainability suffers. I once worked with three other people on a mission critical project to help two banks with their merger. There was a regulatory deadline for completing the integration of the two existing systems for things like trading, etc. Fixed-scope-fixed-date. Coffee and sleepless nights were our solution since we tried not to sacrifice quality. We actually ended up working in my home for the last few 24-hour stretches so that we would have access to a shower. Suffice it to say, there’s no way we could have sustained that pace. It’s anti-Agile.

A quick search for ideas and opinions about stretch goals makes it very clear that there is no commonly agreed “correct” answer. However, from an Agile perspective stretch goals assigned by outsiders are clearly against the principles of the Agile Manifesto.

Stretch Goals Set by the Scrum Team

The Scrum Guide states:

The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

For emphasis: what it can accomplish – not what it (the Development Team) wants to accomplish, or what it should accomplish, or what it could accomplish if everything goes perfectly. A Development Team should be accomplishing their Sprint plan successfully (all Product Backlog Items done) on a regular basis. Of course, exceptional circumstances may intervene from time to time, but the team should be building trust with stakeholders. Here’s another story:

I had a good friend. We would always go out for coffee together. We just hung out – chatted about life, projects, relationships. Of course, from time-to-time one or the other of us would cancel our plans. That’s just life too. But there came a time when my friend started cancelling more often than not. There was always a good excuse: I’m sick, unexpected visitors, work emergency, whatever. After a little while of this I started to think that cancelling would be the default. I even got to the point where I was making alternative plans even if my friend and I had plans. I got to the point where I no longer trusted my friend. It didn’t matter that the excuses were always good. Trust was broken.

It doesn’t matter why a team fails to meet a goal. It reduces trust. It doesn’t matter why a team succeeds in meeting a goal. It builds trust. Even among team members. A team setting stretch goals is setting itself up for regular failure. Even if the team doesn’t share those stretch goals with outsiders.

Stretch goals destroy trust within the team.

Think about that. When a team fails to meet its own stretch goal, team members will start to look for someone to blame. People look for explanations, for stories. The team will create its own narrative about why a stretch goal was missed. If it happens over and over, that narrative will start to become doubt about the team’s own capacity either by pin-pointing an individual or in a gestalt team sense.

Trust and Agility

The importance of trust cannot be over-stated. In order for individuals to work effectively together, they must trust each other. How much trust? Well, the Agile Manifesto directly addresses trust:

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

Here is my recent YouTube video about stretch goals… check it out and subscribe to our channel!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail