Scrum of Scrums is an event *of* the Development Team, *by* the Development Teams, and *for* the Development Teams!

Hello ScrumCrazy readers,

I’m proud to announce that my article on the “Scrum of Scrums” practice got posted on Scrum.org.

In the article I give some advice on excellence in execution of the Scrum of Scrums practice, and how the Scrum of Scrums has been misinterpreted my many to be a status meeting. It’s an event of the Development Teams, by the Development Teams, and for the Development Teams!

Please give it a look and give me feedback here or there. Feedback welcome!

New and Improved User Story Lifeycle Diagram — Free Creative Commons PDF download!

I had a designer friend update my User Story Lifecycle diagram, and she did a fantastic job!  You can download the PDF here:  http://www.scrumcrazy.com/lifecycle

New and Improved Diagram:

UserStoryLifeCycle_final_lg

The Older Diagram(also still available at the above link):

UserStoryLifecyclexm

Other Good User Story Links

Daily Scrum Patterns: The Sprint Backlog at the Daily Scrum

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

“The Sprint Backlog at the Daily Scrum” Patterns

While it’s a popular and proven practice to <View the Sprint Backlog at the Daily Scrum>, it’s a controversial practice to <Update the Sprint Backlog at the Daily Scrum>, as the updating can detract from the true objectives and focus of the Daily Scrum in some situations.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

The Sprint Backlog at the Daily Scrum Patterns:

Daily Scrum Patterns: Who Attends the Daily Scrum?

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

Who Attends? Patterns

According to the Scrum Guide, the Development Team must attend. With many teams, and especially Shu level teams, the <Scrum Master Attends>. It’s usually a good practice if the <Product Owner Attends> so that they can help the Development Team if needed, often times at <The After Party>. It’s usually not good if an <Authority Figure Attends> on a regular basis.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Who Attends? Patterns:

Daily Scrum Patterns: Who Participates in the Daily Scrum?

This blog post is part of a series of blog posts on Daily Scrum patterns.  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Today we’ll talk about “Obstacle Resolution Patterns”

Notes:

Who Participates? Patterns

The Scrum Guide says that “the Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.” However, some practitioners think it might be ok if the <Product Owner Participates> in the Daily Scrum. Having said that, it is incorrect Scrum if a <Non Scrum Team Member Participates> in the Daily Scrum, so consider using <The After Party> to let non Scrum Team Members communicate with the Scrum Team.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Who Participates? Patterns:

Daily Scrum Patterns: Facilitation Patterns

This blog post is part of a series of blog posts on Daily Scrum patterns.  (More coming in future posts over the next weeks).  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Notes:

Facilitation Patterns

Most teams hold the Daily Scrum as a <Standup Meeting>, but this is not required in Scrum, and some teams that are distributed feel like it’s ok to hold a <Sit Down Meeting> so long as they are faithfully executing the objectives of the Daily Scrum.

Teams just starting with Scrum might benefit from a <Close Facilitator>, so long as that doesn’t turn into a <Controlling Facilitator>. A bad practice is facilitating a Daily Scrum such that it <Turns into a Waterfall Status Meeting>.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Facilitation Patterns:

Daily Scrum Patterns: Talk Order

This blog post is part of a series of blog posts on Daily Scrum patterns.  (More coming in future posts over the next weeks).  For some background, you might find it useful to read my previous article on a simple Scrum Patterns framework.  Daily Scrum Patterns fall under the category of “Scrum Technique Patterns”, as introduced in that article.

Notes:

Talk Order

Most teams start out with a <Round Robin> approach. Teams that are distributed or are highly self organizing might use the <Talking Stick> approach. Some teams become better at getting work done if they <Walk The Items> instead, but use caution as that approach can lead to a Daily Scrum that <Turns Into Waterfall Status Meeting>.

Also, don’t forget to be creative and <Create Your Own Pattern>, and don’t ever hesitate to use a technique that is not described by a documented pattern.

Talk Order Patterns:

Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

Last week I was a panelist at the Agile Denver meeting, where the title of the panel was Kanban vs. Scrum! The Big Smackdown!

If you click through the link, you’ll notice that the title was misleading, on purpose, as is the title of this article(“Kanban vs. Scrum…”).  However, I want to catch the attention of those who think that this is even a valid question or consideration.  The title also speaks to a common problem in the industry that has been around for several years, and won’t seem to go away.

There are a number of software teams and organizations that think they should choose between Kanban and Scrum as their software development process.  This is a GIANT and RISKY mistake, in my professional opinion.

It’s not an either/or proposition.  Scrum is about software development.  Kanban is about change management.

There are several reasons why choosing Kanban as your team’s software development process is a mistake.

1.  You are applying Kanban to the incorrect context.

Would you use a hammer to insert a screw in a wall?  You can, but you’ll probably damage your wall in the process, and the same is true of Kanban as a software development approach.  David Anderson, the creator of The Kanban Method, has apparently said this over and over again since 2005, but no one seems to listen.

Don’t take my word for it, listen to David:

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!” — David Anderson

“There is no kanban process for software development. At least I am not aware of one. I have never published one.”  — David Anderson

“It is actually not possible to develop with only Kanban.  The Kanban Method by itself does not contain practices sufficient to do product development.” — David Anderson*

(*The first two came from the “over and over..” link above.  The last quote was sent to me via email from someone at David’s company.  I think they just pasted in something David had already written)

I should also mention that others have mentioned to me that David talks out of both sides of his mouth about Kanban, Agile, and software development, perhaps trying to capitalize on the fame and success of Agile software development.  That may be true, but it may also be true that David has been saying all of these things for years and no one is paying attention to what he says, which is unfortunate.

2.  Kanban is modeled more after the assembly line and manufacturing.  Scrum is modeled more after creative product design.

Which do you think more closely resembles software development?  Laverne and Shirley on the assembly line at the Shotz Brewery? Or the group of NASA engineers on the ground who saved the lives of the Apollo 13 astronauts by coming up with a creative solution to a problem within a time-box?  If you think software rolls off of an assembly line, then I think that it is unfortunate that you’ve never worked in a creative software development environment — it’s AWESOME!

Maybe my Laverne and Shirley reference is oversimplified.  The reason to use Scrum instead of Kanban for software development delves down into process control theory, and the difference between a “defined process” and an “empirical process.”  In short, a defined process works better when the inputs and outputs to the process are well known and repeatable (like a manufacturing line).  An empirical process works better when the inputs and outputs to the process are less known and very difficult to repeat.  No two software features are alike.  This is why it’s darned near impossible to measure software productivity directly, even though some naive “bean counters” still try to.  Like the stock market, no one metric will predict it accurately, but a range of indicators can help predict it more accurately.  So, in summary, Scrum is based on empirical processes like product design.

One of the very key parts of empirical processes is the characteristic of inspecting and adapting the product.  Think of yourself making a pot of soup from scratch, without a recipe.  Think about all of the “taste-tweak ingredients-taste” experiments(feedback loops) you would need to get a pot of soup that tastes good.

Scrum has the frequent feedback loops built in, for a variety of audiences(Dev Team, Product Owner, Stakeholders, Users) , and for a variety of topics(process-Sprint Retro, product-Ordered Product Backlog, product-Sprint Review, product-Valuable/Releasable Increments).  Kanban has no such built in loops, but again, that’s because it wasn’t designed for software development!

3.  From a Complexity Science view, Kanban is for ‘complicated’ work while Scrum is for “complex” work.

I know the Kanban folks don’t like hearing this, but I think Ken Schwaber was right when he said this, and I think history will prove him right about Kanban as it was described in David Anderson’s book.  In short, the Cynefin model defines 5 domains, of which 2 of them are “complicated” and “complex” work.

‘Complicated’ work is best solved via ‘good practice’ and ‘experts’ who can find ’cause and effect’ fairly easily. When I think of ‘complicated’ work, I think of an the IT support person who sets up your computer or trouble shoots it.  Yes, you need an expert to solve these problems, and the vast majority of the time, the steps to solve these kinds of problems are fairly consistent and repeatable.  They are not exactly repeatable, just mostly repeatable.   If the steps were exactly repeatable then they would fall into the ‘Simple’ domain of Cynefin.

‘Complex’ work is best solved via ‘safe to fail experiments’ and one can only ascertain cause and effect after the fact.  Each Sprint in Scrum is a ‘safe to fail’ experiment because, while the Sprint increment is always releasable, the business side of the house makes the decision on whether it is safe/valuable to release it or not.  In the case of an increment that is un-safe, the team course corrects and comes back with an increment the next sprint that is hopefully safe or more-safe.  These safe to fail experiments can be repeated over and over again until it’s time to release the increment.

Applying Kanban Correctly

Having said all of the above, there IS a time and place for Kanban — a correct context, if you will.  If you’ve been reading closely, that context is as a change management process, which is ‘complicated’ work, and requires that there be already existing processes in place.  So, if your software team is doing XP, Scrum, Crystal, Waterfall, RUP, DSDM, FDD, etc, then you can layer Kanban on top of it to help find bottlenecks and waste.  Also, for all of those teams out there that don’t use a software development process(framework, approach, etc) that is named in the industry, you’re probably doing cowboy coding, ad-hoc, or command and control project management — none of which is a software development process either.  So, layering Kanban on top of crap will still yield crap.

For those that want to apply Kanban at the enterprise level to monitor the flow of work through their Scrum teams (Or XP, Crystal, etc), or want to use it for IT support or Dev Ops, I say have at it and I hope it helps you.  I imagine just visualizing your workflow alone will help in those contexts.  I myself have recommended and coached Kanban for a couple of teams — but only because those teams exhibited the right context for Kanban to be successful.

Bottom Line

Having said all of this, just visualizing your workflow and the other Kanban principles is not enough for software development.  Software development has things like business value, technical complexity, and user experience/acceptance/adoption — all of which are not addressed directly by Kanban.  Scrum does address these areas, as I have shown above.  But hey, let’s not forget, the Kanban Method is “not a way of making software or running projects that make software.”  Would you criticize a hammer for not doing a good job of being able to insert a screw into a wall?

Related Articles

ScrumCrazy.com update:

  • Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
  • Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!

Towards a Catalog of Scrum Patterns

I’ve been thinking a lot lately about Scrum patterns.  To that end, I’ve drafted a conceptual model, which is depicted in the below image.  (You may want to click the image twice to see a bigger view of it)

ScrumPatternsOverviewOnePage

“Sprint Progress Monitor” is my term for what used to be called the “Sprint Burndown.”  In the 2011 Scrum Guide, Sprint Burndowns were no longer required but some way of monitoring sprint progress, via summing the remaining work, was still required.  In the Scrum Guide, it is made clear that these practices can be implemented using several techniques, and “techniques may vary” from team to team.  So, this is what inspired me to use the term “Scrum Technique Pattern.”  A Scrum Technique Pattern(STP for short) implements the intentional gaps left by the Scrum Guide.  Teams can inspect and adapt their technique patterns, while still fulfilling the Scrum framework.  Said another way, there are intentional “variation points” in Scrum, and the STP’s are different ways of implementing those variation points.

“Optional Scrum Patterns” are patterns that can be used in conjunction with Scrum, but are not specific implementations of Scrum techniques as specified or required in the Scrum Guide.  These can be just about anything, but they must follow and/or support Scrum principles in order to be considered as an Optional Scrum Pattern.

I also see the need for the ability to create a “mashup” of different Scrum patterns to create a set of practices and techniques for a particular team or context.  For instance, we might start out with a Scrum Starter Kit that includes things like:

  • Holding a Release Planning meeting every 2-3 months (OSP)
  • 2 Week Sprints (STP)
  • Using Story Points to estimate Product Backlog Items(STP)
  • Using Ideal Hours to estimate Sprint Backlog plan items(STP)
  • Doing a typical burndown chart to sum the remaining work for the sprint(STP)
  • Representing Undone Work(OSP)
  • Doing the typical “round robin” style of the Daily Scrum(STP)
  • Doing a fairly typical “Plus-Delta” retrospective analysis(STP)

Any of the above patterns could be interchanged with other patterns, and the Scrum implementation would still conform to doing correct Scrum.  Presumably the change to different patterns would be an attempt to improve a team’s ability to delight their customers and users.

Who writes these patterns?  Where do they come from?

In a word, anywhere.  I’ve seen dozens of them on the internet and in books.  I’ve documented a few original ones myself(though many of mine are adapted from others, and I would make every reasonable attempt to give credit where credit is due).  I would not be attempting to create all of these patterns, but to assemble them and label them so Scrum practitioners can easily understand which of them are optional, and which are fulfilling required practices of Scrum.  Of course, it will also become helpful to understand where these patterns fit into the grand scheme of Scrum, and I have some ideas along those lines, too.

I will keep iterating on this concept, and I hope to get back to you with more on this topic in the future.

A Visual Diagram of the User Story Life Cycle

This blog post is now deprecated.  Please see the new updated blog post:

http://scrumcrazy.wordpress.com/2013/06/13/new-and-improved-user-story-lifeycle-diagram-free-creative-commons-pdf-download/

 

Follow

Get every new post delivered to your Inbox.

Join 276 other followers

%d bloggers like this: