I was at a client recently and one VP was convinced that Agile was “untrue” and there was no way it could possibly work. The problem was that he had never heard of backlog grooming or getting stories ready. Once he saw the infographic below, the penny finally dropped and he understood how this crazy thing called Scrum can possibly work with user stories.

Jeff Sutherland points out the the best way to go fast is to have a definition of done (or “done done”) that means the software is shippable (coded, tested, documented, etc.).

The second best accelerator is to get stories ready (or “ready ready”) before the sprint planning meeting. For me, “ready ready” means that people understand stories well enough for the team to have a productive Sprint Planning meeting. Not one that takes ages and ages and stops because people have to catch a train or pick up their kids at daycare.

The purpose of the diagram is to provide a conceptual model for how stories get to be in a “ready” state. People need to talk about them and maybe do a little leg work. Who is responsible for getting stories ready? The Team! (Not the Product Owner as some might say). So good teams spend ~10% or their time getting ready for the next Sprint and ~90% on the current Sprint. Please note the amount of time will vary by team and project – 10% is a conceptual number.

Of course, most teams fall into the trap of focussing so much energy on the current Sprint they fall into the vicious cycle of low quality planning meetings and disorganized Sprints.

What if it takes more than “a little work” to get a story ready or to spilt a story? No problem, just create a Technical Spike story so that the whole team can tackle this tough story together. The outcome or acceptance test of the spike is that the story is split and that all the upcoming stories are “ready”.

The next rows in the diagram show that some people on the team may spend more time getting stories ready than others. For example, architects, SME (Subject Matter Experts), etc.  User Experience designers are often focussed on the Sprint ahead while docs folks are mostly on the last Sprint. Again the numbers here are conceptual.

Here are some other good posts on getting stories Ready:

• The Definition of Ready
• Ready-ready: the Definition of Ready for User Stories going into sprint planning

Happy Scrum!

I am very excited that I just published my free book - An Agile Adoption and Transformation Survival Guide: Working with Organizational Culture on InfoQ. Agile change agents will find it valuable in helping companies succeed with Agile and avoiding failure.

About the Book

Struggling with Agile? Frustrated that people don’t really get it? Tired of fighting with organizational bureaucracy? Wondering how you could have been more successful? If so, then this book is for you!

The book provides a set of essential thinking tools for understanding Agile adoption and transformation: how they differ and what you need to know to know to avoid being another statistic in the widespread adoption failure. In particular, you will learn how to use culture to work more effectively with your organization.

It is called a survival guide since so many people have found the concepts to be invaluable in understanding their experiences when working with Agile.

This book includes:

• Identification of causes of the widespread Agile adoption failure
• A model for understanding Agile, Kanban, and Software Craftsmanship culture
• An outline of key adoption and transformation approaches
• A framework to help guide when to use these these approaches with your organization
• Real-life case studies of what has worked and what hasn’t

Electronic Version is Free

You can get a PDF or ePub version of the book for free on InfoQ. Why free? My primary goal is to change the world of work, and by making it free I can best achieve this goal. Of course, I would be really happy if you bought multiple copies of the print edition to give to your friends and clients to help them succeed as well as support my work.

Thank You

“If I have seen further, it is by standing on the shoulders of giants.” – Isaac Newton

I would like to thank Henrik Kniberg who has contributed so much open source material to the Agile community and inspired me to write a free eBook to pay it forward. I also appreciate him taking the time to write one of the forewords.

I would like to thank the attendees of workshops with early incarnations of this material – XPToronto, SoCal Lean Kanban, Agile Tour Toronto, and Agile New England. Your comments, challenges and reflections have helped in immeasurable ways.

Thanks to all the people who read my blog posts throughout 2011 on this topic and provided valuable feedback.

A big thanks to Michael Spayd for first introducing me to the Schneider culture model and for conducting a survey of Agilistas.

For sure this work would not exist but for Mike Cottemeyer’s differentiation of adoption and transformation.

Thank you to the review team for feedback: Chris Williams, Irene Kuhn, Armond Mehrabian, Krishan Mathis, Bernie Jansen, Ed Willis, Eric Willeke, Karl Scotland, Sabine Canditt, Todd Charron, Bob Sarni. Olaf Lewitz in particular deserves distinction by providing an extraordinary quantity of valuable comments, questions and challenges.

I would like to thank those who directly contributed to this work as well as reviewing: Olivier Gourment for contributing a case study; Jeff Anderson, Olaf Lewitz, Jon Stahl, and Karl Scotland and Alexei Zheglov for sharing their challenges and alternate visions in the appendix.

I would also like to thank Alistair McKinnell, Jason Little, Declan Whelan for providing feedback on the Methods & Tools article that formed a chapter in this book and to John McFadyen and Dave Snowden for feedback on the Cynefin section.

I am very appreciative of Jurgen Appelo for taking time out of his busy schedule to write a foreword.

And of course a big shout out for my daughter Scarlett who provided original art with the jigsaw puzzle and butterfly transformation drawings.

Wow! Even a small book such as this benefits from so much help.

- Michael Sahota

There is a lot of debate about Sprint Commitments in Scrum. In my mind, the notion of a Sprint Commitment is an anti-pattern. Of course, personal commitment is critical.

Every System has a Natural Velocity

Have you ever played or watched Deming’s Red Bead simulation? If not, watch video below. It’s pretty funny and a must-watch for anyone managing or coaching teams.

There is Variation in Knowledge Work

It is generally accepted that knowledge work has high variation – say in contrast to manufacturing.

Scrum is used in situations where there is imperfect knowledge about the work to be performed. A common practice such as user stories that follow the CCC (Card, Conversation, Confirmation) pattern implies that there is room to explore the definition of a story. As such, there will be variation in how long it takes to complete work.

Sometimes there are Emergencies

Yes. Believe it or not, some Scrum teams operate in the real world where there are emergencies. Sometimes these are personal in nature and sometimes these stem from production support situations that get out of hand.

There is a great post by Serge Beaumont on dealing with emergencies that talks about the alternatives for handling them. Serge argues that predictability is not the end goal of Agile – delivering valuable software is.

Fixing a critical production issue will generally have higher ROI than working on a feature for an upcoming release. Sure we want teams to get better at reducing production defects (failure demand), but this takes sustained investment in time and energy.

Making Commitments Leads to Undesirable Behaviours

1. Teams cutting quality to make the commitment.
2. Working overtime to deliver but causing longer-term harm due to disengagement or dissatisfaction. This will also lead to teams under-committing in the future.
3. Dropping “soft” scope items that really need to be there but will impair the customer experience.

Maybe XP has one solution to this problem. Always under-promise. Always hit the commitment. Use the slack time for important, non-urgent activities so that your team goes faster over time.

Why am I talking about this now?

This topic has been on my list of things to blog about for almost a year. I am writing about it now because Ken Schwaber and Jeff Sutherland updated the Scrum Guide and included dropping Sprint commitments as one of the significant changes.

Other Perspectives: Xavier Quesada Allue calls for “soft commitments” (but stops short of calling commitments an anti-pattern – from two years ago)

 Great video explaining Push vs. Pull

The video below provides a great explanation of push and it’s consequences as well as the benefits of pull.

Use Commitment for vision and values

Commitment in a healthy team or company is about doing our best each and every day in pursuit of our shared compelling vision. It is about demonstrating and following our shared values and working agreements. It is about kindly challenging others when they stray.

For me, this is more about a sense of personal responsibility and accountability along the lines of Christopher Avery’s work.

@tumma72 – “ I like to let commitment emerge from honor and respect in the teams I coach behavior vs words”

@dneighbours – “personally I believe shared commitment is 100% necessary for high performance..”

Guest post by Michael DePaoli

If your development team or manufacturing team is considering moving to using Kanban vs. Agile Scrum, one of the biggest decisions is choosing the right agile development methods for the job. Let’s discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
2. Establish and respect WIP(work in progress) limits in the value flow
3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams. These outcomes in turn destroy brands, ruin company reputations on Wall Street, increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability. But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice: ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

• Your organization’s product development and sales culture,
• The nature of the demand for service from product development,
• The competency of your organization to plan and execute change, and
• The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Michael DePaoli Bio

Over his 26 years in IT, Michael DePaoli’s experienced has included serving in different
traditional roles in highly respected companies. The roles have included analyst, software
engineer, quality engineer, development manager, project manager, Director of Engineering,
VP of R&D, CTO and Consultant in companies, such as American Express, Sprint, Deloitte
Consulting, Sapient, Knowledgepoint, Adobe Systems, AOL, NetApp and VersionOne. Michael
works as an agile / lean coach and product consultant with the VersionOne services group.

This post identifies concrete actions. See also: Acceptance Tests and Models for Success.

The final step was to identify concrete actions that the Scrum Alliance organization and membership can take to move toward the goals associated with specific parts of each model. This is the list we came up with. Each item was given a “thumbs up” or support vote. (There was only one thumbs down, but this was cleared with further discussion/explanation).

1. Create an initial Product Backlog of actions and desired future conditions. This list is a start.
2. Make that backlog visible to all members.
3. Create a mechanism to make it easy for members to volunteer for tasks associated with items on the backlog.
4. Find someone (or several persons) to facilitate the volunteer mechanism.
5. Develop ways to detect new trends and opportunities that may impact the SA and/or be influenced by the SA – eg. the new PMI/Agile certification program.
6. Develop a means for official public response to such trends and opportunities.
7. Start/continue building “bridges” with related communities involved with such trends and opportunities.
8. Apply Scrum/Lean/Agile tools (timeboxes, teams,  iterations, WIP limits) to work on these backlog items and management of the overall SA portfolio.

Participants

Note: Sorry we didn’t get everyone in the picture…

• Bob Allen
• Brad Swanson
• Chris Sims
• James Smith
• Heidi Helfand
• Mark Levison

This post identifies two visions for successful leadership within the Scrum Alliance. See also: Acceptance Tests and Concrete Actions (& Participants).

The group was divided into two teams. Each team independently went through the Strategic Play® visioning process:

1. Every team member built a model representing their ideas to support thought leadership.
2. In turn, each team member shared their ideas through the Lego model.
3. The models and ideas were integrated into a shared model. The results are shown below.

Shared Model from Team 1

Some Notes:

• Low barriers to entry
• Transparent
• A source of ideas (not only source)
• Listening to outside ideas
• Building bridges to other communities (PMI, Kanban, etc)
• Welcome other community members into our community
• Stepping places for learning and different approaches
• Many people working to move SA forward with coordination of effort and needs
• Let go of past
• Have awesome tools and capabilities within our community

Shared Model from Team 2

Some Notes:

• Simple machine with inputs and outputs
• Inputs are multiple communities through individuals and “antennas”
• Collect ideas in central backlog with adequate levels of transparency
• Courageous Leadership to move ideas forward
• Other leaders to spread ideas
• Assisting people with entry to so they can grow
• Building bridges with other communities

Discussion

There were a number of key differences between the models.  A few are discussed below.

What kind of leader? The inclusion of the Crown by one group was particularly challenging due to symbolic association to a king and absolute authority. Upon clarification, it was used to represent strong leadership that was inclusive of other voices and opinions. Something more than a facilitator and less than an authority.

What communities? The first group was much more oriented outwards to other parts of the Agile community and even wider. The second was focused more on the different communities or membership within the Scrum Alliance. So, both internal and external stakeholders are important.

This post identifies acceptance tests for successful thought leadership within the Scrum Alliance. See also: Models for Success and Concrete Actions (& Participants)

Process: Everyone built a model for an acceptance test and each group voted to select the two most valuable acceptance tests. So there are four acceptance tests in total.

Acceptance Test #1 – One Leader, one Message & people following

Acceptance Test #2 – Tuned in to community and able to influence it

Acceptance Test #3 – Build bridges between communities

Acceptance Test #4 – Start with one concrete thing supported by multiple communities

There will be a workshop at Agile 2011 on building ideas for improving thought leadership in the Scrum Alliance.

Workshop Logistics

Thursday 1:30 to 4:00pm in the Open Jam at Agile 2011.

We are very excited to have the managing director for the Scrum Alliance, Carol McEwan, participating in this activity.

Workshop Purpose

The purpose is to clarify acceptance tests and generate  ideas for how the Scrum Alliance can work effectively to provide thought leadership around Scrum.

We will use StrategicPlay® with Lego® to share points of view and build a shared vision of ways the Scrum Alliance can demonstrate leadership.

This vision will be shared with the wider community for feedback and action.

Ask not what your SA can do for you, but what you can do for your SA.

Workshop Results

It was decided that it would take to long to publish this via the Scrum Alliance website, so the results are posted here (on Agilitrix website) as an interim step.

1. Acceptance Tests
2. Models for Success
3. Concrete Actions (& Participants)

I learned in the last month that I don’t know what XP is.

As it turns out, I don’t really know what Scrum is either.

This is a good thing.

No, I am not on crack. Let me say more.

Putting my foot in my mouth in public

I made the unfortunate choice of selecting this post for submission through the Scrum Alliance: 5 Ways Scrum Creates Safety: Why One CSC Uses Scrum and XP Together to Avoid XP Risks. I have gotten more flak over this than a years worth of blog posts.

For sure, there are some inaccuracies (more on this below)

Also, some people have interpreted it as saying XP bad, Scrum good.

In hindsight, I can see how people may interpret the post this way.

Sorry

I am truly sorry for offending anyone. This was not my intent.

Scrum and XP are evolving targets

My big learning is that Scrum and XP are evolving and imprecise concepts.

Let’s take and example from Scrum. Retrospectives were not originally part of Scrum. I checked out Ken’s original book and it’s not there. Neither is definition of done. Of course, they were part of CSM as taught by Ken in 2004 when I learned Scrum. Scrum at least has a Scrum Guide (hosted at scrum.org!) to define what Scrum is today.

Let’s consider XP. I have heard the statement that Retrospectives are part of XP and have been since 2001. OK, how would I verify that? Well, how about checking the revised edition of Extreme Programming Explained (2005)? Interestingly, it does not mention retrospectives. Jim Shore’s book does but it’s the Art of Agile, not the Art of XP. AFAIK, there is no definitive source for XP the way there is for Scrum. This makes it really hard to have a conversation about what XP actually is. Based on this, I think it is fair to say that I don’t know what XP is and I probably never did. I’m not even sure how I would find out if I wanted to. (If you know, please let tell me).

This demonstrates how CSM and standardized training has done more to grow the Agile community than anything else. It helps to have a standard language and a common core. So, kudos to Ken Schwaber for this.

Practices vs. Brand

I agree with the comment that what is most important is not the Brand, it is the practices. I totally agree. The practices are more important than what we call them.

On the other hand, the brand is relevant too. It defines where we start with clients, the language we use, and the community we grow with. So for me, brand does matter. And the Scrum brand (for all it’s odour).

Many thanks to Lowell Lindstrom and Adam Sroka for commenting on my article and helping me learn something from this experience.

Just had my first article posted to Scrum Alliance website. (Click link to check it out). I originally wrote this 9 months ago to support my Certified Scrum Coach application, but that process finished first.

Here is the abstract:

Scrum contains a set of practices distinct from XP that are intended to enhance project safety. The Scrum framework is simple and intentionally incomplete. Scrum expects that teams will add in practices that are relevant to their specific context. For example, there is wide recognition within the Scrum community that XP engineering practices need to be added to Scrum to create sustainable software projects. So, Scrum and XP together is a good starting point.