Here are the slides and reference links for the session Gino Marckx and I are giving at Agile 2010 in August

Triangle Model

Selecting and delivering the most important work is a critical success factor in Agile projects. But how do you know what is important? Unless you are psychic, some help would come in handy. Consider the diagram below to help make sense of the wide variety of strategies and tools.

We explain three different perspectives: Company, Customer, Team.

Team Perspective

The product backlog needs to be structured so that it informs the team of the vision and the work. Whenever the company or the customer priorities are not clear, the team will need to rely on general information and it’s common sense.

Theme Scoring & Screening - Relative or numerical weighting based on criteria (Mike Cohn)

• Video of Mike Cohn at Agile 2008 and Slides
• Agile Estimation and Planning (book)

Story Map – structure the work in a grid that reflects actual product usage (Jeff Patton)

• Jeff Patton’s blog
• Presentation

Software By Numbers – prioritize work by Net Present Value of Minimum Marketable Feature

• Software By Numbers (book)

Customer Perspective

The product backlog prioritization is done from the customer’s perspective, from the perspective of whoever is paying for the product in the first place, whether this customer is internal or external to the company doesn’t really matter. What is most valuable to the customer will be on top. Techniques focussing of this view require strong product domain knowledge, and a good understanding of the impact of specific features on the business.

Kano Analysys - Structured Questionaire to determine feature relevance: Mandatory, Linear, Exciter

• See materials of Mike Cohn from Team Perspective: Theme Scoring & Screening

Innovation Games® - 12 Games to better understand your product and what’s important (Luke Hohmann)

• For Speedboat® and Buy A Feature® + more - innovationgames.com and Book

Company Perspective

Companies need to find a balance in distributing the effort over multiple customers and/or products. But they also need to take the company and product strategies into account, deprioritizing features that might be very valuable for customers but aren’t in line with the company’s vision. As well, this takes into account stakeholders other than customers and sales – support, professional services, etc.

Company and Stakeholder Strategy

• Aligning and Balancing Your Backlog
• Blog: Why Prioritizing Your Product Backlog for ROI Doesn’t Work

Business Value Game – Simulation to illustrate how organizations can define their own business value model.

• Game instructions

Allocation Model - helpful to balance priorities with divergent or competing interests

• See example by Alisson Vale: Slides 40-49

Where to go from here?

The most common questions we have gotten after presenting these techniques are “How do I decide where to start?” and “How do these work together?”

These are complementary techniques and are used to solve related problems. Our recommendation is to start with the area that is the biggest challenge for your project. Maybe this means talking to stakeholders you normally don’t talk to. Maybe it means putting a Story Map up on the wall. It depends.

Slides

For years I have preferred Scrum as a starting place rather than XP since it is easier to adopt. One of the patterns of Fearless Change is to take small steps. Scrum is a much smaller step than XP. That’s old news. Lot’s of folks like to start with XP, that’s OK by me.

Probably a good thing to clarify at the start is that Kanban is part of the Agile family of processes.

Kanban is easier to adopt than Scrum

Way easier. Like almost trivial. Let’s see: no process change, no role change, no change in team structure. Just make the work visible. Wow! There is so much value in just making the work visible. Lot’s of little problems can be fixed and voila – productivity and cycle time gains.

Kanban uses Kaizen = Continuous Improvement

Kaizen is about continuous improvement. Define a standard process and then start improving. Take smalls steps. Get everyone involved. Kanban is a standardized process flow that starts with the existing process.

In the graph of performance vs time on the left, kaizen will result in improvements that will asymptotically approach the limit within that paradigm.

As teams mature, they may go beyond this into the place where Scrum/XP start…

Scrum/XP is Kaikaku = Radical Overhaul

Kaikaku is discontinuous improvement. It is about a revolution in the way things are done. It is also called Breakthrough Kaizen.

Can anyone say Scrum or eXtreme Programming? It changes work groups, job titles, roles, and project basics. For contexts where Scrum is a good fit, it is a high-value, high-cost game-changing move. James Shore has a great post on Kaizen and Kaikaku where he argues that this is a better starting place if you want a high-performance team.

What does this look like in terms of performance? See graph below. It looks like Virginia Satir’s Change Model.

In the Lean world, companies use both kaizen and kaikaku depending on circumstances as they are complementary approaches.

Why a gateway drug?

The gateway drug theory states that softer drugs (Kanban) can lead to harder drugs (Scrum, XP). This is a great metaphor because this theory has been proven as well as dis-proven. To quote David Anderson “we are only beginning to understand the differences between Scrum and Kanban”.

Do I believe in the the theory? I’m not sure that I care – as long as people are working to improve their work environments at a pace that works for them, that is good enough for me. For me, any Agile is good –  it does not need to be one particular style.

Let’s face it – lot’s of organizations are ready for a radical overhaul. For companies like these, Kanban is a great place to start. Getting off the sofa and going for a marathon may not be a good idea. For some it may be better to start by jogging around the block.

Other Perspectives

David Anderson has a contemporaneous post (go read it, it’s good) supporting the notion that Kanban is primarily focussed on continuous evolution until the organization has enough maturity for more radical changes.

Ken Schwaber is continuing the drum beat that Scrum is the one true path.

I am really excited to have two sessions accepted at Agile 2010 in Orlando. As I am a big fan of pairing to get high quality, I am happy to say these are both pair-designed and will be be pair-led with other great coaches.

The biggest bang for the buck! Strategies to organize & prioritize your backlog – with Gino Marckx is an introductory tutorial and simulation that is part of the Product Management Stage. (Dry run at XPToronto meeting in June)

Look before you leap – Agile readiness assessments done right – with Gerry Kirk is an expert-level workshop that is part of the Agile Adoption Stage. (Dry run at Agile Coach Camp Canada) Check out the program links for more details.

I would like to thank everyone who provided input on the draft sessions in the wave, as well as the comments from reviewers. Oh, yeah, and a big thanks to Gino and Gerry for partnering with me on this.

BTW, there is no official Agile 2010 Speaker logo that I am aware of – I made up the one above

I recently attended a ThoughtWorks QTB – Rapid, Reliable Releases (AKA It’s not making money until its in production) by Rolf Russell and Andy Duncan. It was a solid presentation around the importance of managing environments effectively.

I will walk through the diagram below starting with …

a reliable continuous integration system creates a foundation for rapid reliable releases. It provides early integration and gives the teams rapid feedback on how they are doing. Everything else follows from this.

A key ingredient for successful management of production and other environments is collaboration with dev and ops. There is even a new type of role appearing – DevOps – that handles both development and operations. Either way, someone needs to champion this important interface.

The next topic was about using value stream mapping to see what it takes to actually get something into production (I heartily agree with this approach as I have found it very effective). What we often see as a result is that the work is optimized for each department and is not aligned with the best needs of the whole business and there are lot’s of delays and handoffs.

The next step is to envision future state - what items can go in parallel to get feedback as soon as possible. In one environment is was functional testing, performance testing, and UAT.

A practical idea is to use the cloud for scalable parallel Continuous Integration. In this situation we need lot’s of computers for a short burst, so this lines up nicely with the cloud’s pay per use model and lets testing go really fast.

The final bits of advice were around creating deployment recipes that go with the code (including database changes). In order to accomplish this you will need to create consistent environments and encapsulate differences (such as number of servers, specialized hardware, etc). Once you explicitly handle all the risky bits, then it is easy to support reliable and automated deploys.

If you haven’t done this sort of thing before, then it may seem like a lot of work. For me, it’s seems just normal. I personally implemented a lot of this when I worked at a startup in 2000 and have been using it ever since. I can say firsthand that work on this really pays off.

Video is available on InfoQ.

At DeepAgile in Boston, I played Yellow Brick Road: Fresh InsightsThrough Peer Coaching. The game was led by it’s inventor – Portia Tung who did a great job even with a very large group. If you haven’t played this, I suggest you make the time.

The game teaches people skills and resources to be effective coaches by practicing with peers. In the game, people take turns in one of 3 roles: Client (with a problem), Coach, and Observer.

Solve real problems

In the role of Client/Dorothy, you get to be yourself and bring up a problem that you want to work on. Over several iterations, new perspectives help you access the resources you already have. So a cool side-effect of this game is that you get fresh insights into whatever problem you want to work on.

Coach practices questions

The coach gets to practice listening and asking questions. We discovered that listening is something we need to practice since we are so used to jumping in with our expert opinion and solutions.

We also get practice with different types of questions (image by Portia Tung):

Observer provides depth

The observer roles gives you a chance to step back from the situation and really notice what is going on. Portia’s picture captures the simplicity of the task:

I was reminded that observation is a very helpful debugging technique. It is also less than easy – especially if you are like most of us and out of practice.

As the observer, I was able to get much deeper insights.

Go play this game

I am going to play this game again for myself and to help those I am coaching. The complete game instructions and presentation is available for download, so give it a go! I’m sure you will get value out of it. Even better, get Portia to come play with you so you can see some of the finer points.

(This is part of a series on DeepAgile 2010 Games Weekend).

Alternate Title: A model for understanding Scrum and Kanban

(Cool diagram below – skip down if you are in a rush

As I flew home after LSSC10, I wondered how Kanban-style software development would shape my world in the years to come. I self-identify as an Agile/Lean Coach and wondered what the road ahead looks like for me.

Someone at the conference commented that Kanban was going to dominate discourse in our community. Some people in the Kanban community say it is more widely applicable and is a more rigourous approach. Another commented that software processes historically have a 7 year run and so it is time for the age of Scrum to wane. The arguement goes that even if Kanban isn’t better, the community needs a new buzz to keep things going. All this made me wonder.

Is this true? If it is true, what does this mean for me? How can I reconcile this with what I know works? Before we delve deep, I need to share where I am coming from.

I use Agile

I have used Scrum for many years as a starting point for Agile transitions. It is compact, creates visibility, and builds a team culture. I also use XP practices.

I use Lean/Kanban

I have been using Lean concepts for many years and very heavily in the last year. I have made extensive use of Kanban-style Scrumboards as well as pure Kanban boards for business and support groups. I have had great success with other tools as well: root cause analysis, the A3 technique, and value stream mapping. This winter, I implemented Kanban with a 18 person software group and shifted behaviour with a cumulative flow diagram.

For me, Agile includes Kanban

When I read the Agile Manifesto and principles, I don’t see anything that excludes Kanban. All the XP technical practices still apply – perhaps even more so. Scrum notions of Product Owner, Product Backlog, and Retrospectives still hold value. Iterations may be gone, but they have left a trail of useful concepts of tools that the Kanban community enjoys. Maybe 80% is the same. Why am I making this point? Some proponents on Lean and Kanban highlight the differences rather than relationships: “Kanban is new!” “We are post-Agile” – as if that were cool. Our community is better served by focussing on the positive in every approach.

What I learned at LSSC10 that shifted my thinking.

At LSSC10, I started noticing contexts – what environments and circumstances encourage Kanban-style Agile.

Support Kanban What blew me away was a keynote case study on Kanban turned out to be about a couple of support groups who figured out that Scrum is not a good fit when there are lots of interrupts and emergencies. Ah, um, … not really news. This is the canonical case for Kanban.

Naked Planning or using XP for single-piece flow is about creativity and cross-functional teams swarming work (MMFs). The context here appears to be a team with a lot of focus working on innovations. This is much more similar to Scrum/traditional Agile rather than Kanban.

(Vanilla) Kanban Mike Fitterman and Rick Simmons of Constant Contact told the story of how Scrum wasn’t working out. Two development teams shared QA and product people and found there was too much planning and communication overhead. (Ooops, sounds like ScrumBut.) Anyway, the context in which they applied Kanban was with one with specialists and group that was too large to be a team.

Vale Kanban Alisson Vale described an environment with small work packages that come from a variety of demand channels. (See also video). It very much sounded like system evolution rather than discontinuous innovation. Interestingly, his model does not follow work decomposition by role but rather allows flexible routing and story swarming much like XP.

Production Line Kanban and (Vanilla) Scrum Most insightful of all for me to outline contexts was Clinton Keith’s session on video game development (go read it). He used a timebox for creative work both with takt-time in production-line style Kanban and with Scrum during design and problem solving phases. So, in this situation, they see Scrum for exploration and Kanban for cranking stuff out.

Scrum and Kanban fit different contexts

• Kanban can handle a lot of interrupts
• Kanban supports specialized roles with divergent skill sets
• Kanban excels at repeatable work such as a production line
• Kanban works fine for groups larger than 7+/-2 since communication and planning overhead is lower

• Scrum excels at projects requiring deep collaboration and innovation
• Scrum works best with small cross-functional teams (7+/-2)
• Scrum is great for providing shared goals and work context
• Scrum encourages generalists

For a more comprehensive list of similarities and differences see Kanban and Scrum – making the most of both. See also Jason Yip’s recent observations.

A model for thinking about Scrum and Kanban

I am a visual thinker so I need a picture to put it all together:

• The vertical axis differentiates environments with a strong focus from those with many interrupts and divergent needs.
• The horizontal axis indicates the spectrum from defined, repeatable work to exploratory and innovative work that benefits from swarming.

Every process has a sweet spot

I have indicated where I see various process styles play best. (For example, Scrum is good when there is focus and exploration.) The dashed lines suggest  that these are not hard boundaries. The regions and shapes are more illustrative than literal.

In this model, Kanban is at centre stage. I have repeatedly witnessed first hand that Kanban is very easy to implement and provides great benefits.

I also have seen the value in creating small, focussed teams using Scrum. For sure it is harder and yet very rewarding. On the downside: it doesn’t fit all contexts.

In truth, I am not 100% satisfied with the fidelity of this model, however, it helps me understand how to approach work with my clients

We need to know both Scrum/XP and Kanban

If all you have is a hammer, everything looks like a nail.

What tools do you have in your belt?

Henrik Kniberg gives the metaphor of comparing a knife with a fork. Which one is better depends on the situation. We need need to know both Scrum and Kanban. XP, too, but that goes without saying.

As an Agile coach I need to understand a client’s situation to know whether to start with Kanban or Scrum or both. Miyamoto Musashi – a famous Japanese Samurai spoke regarding choice of tools – said “You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough.”

Let’s build community

For my Scrum and XP friends, Kanban is here to stay and it is going to continue to grow; let’s embrace it and help mature it.

For my Kanban friends, let’s build bridges and create a strong inclusive community.

Hungry for More?

• Kanban and Scrum – making the most of both by Henrik Kniberg and Mattias Skarin
• Kanban by David J Anderson (Just released)
• Scrumban – Essays on Kanban Systems for Lean Software Development by Corey Ladas

Thanks

Many thanks to Jason Yip for helping me refine my thoughts and to Siraj Sirajuddin for getting me to attend LSSC10.

What do you think?

The picture I am painting may be missing something. Please share comments or get in touch with me directly to build a better model.

Siraj Sirajuddin shared a deeply insightful reflection on the nature of Agile/Lean coaching. Lot’s of insights for me.

Below, I have a few notes that just scratch the surface.

A big take-away for me is that every day and every meeting I need to:

1. Learn
2. Make a difference
3. Have fun

Another concept is Clean State Fridays where everyone goes home without emotional baggage so they can start fresh on the following Monday.

He also reminded me that we play a dance with courage and grace to achieve great outcomes.

Strongly suggest you check out the full presentation or find a way to see him in person.

This is a review of Luke Hohmann’s excellent blog series on Product Backlog Prioritization. As usual, I have captured what I believe to be the salient points in a visual note.  The main points are to:

1. Align with Company Strategy
2. Balance stakeholder demands
3. Drive Profit

Starting at the top left and going clockwise…

Company Strategy.  Do you know what it is?  Do you know the top 3 priorities. Do you know the product strategy? As product owners, we want to eliminate the work that does not align with these. We also want to focus on those that are most strongly aligned with strategy.

Software By Numbers is a great concept but is difficult to use in practice. Firstly, no one has then numbers and secondly business value models need to account for intangibles.

Driving PROFIT is one aspect of a healthy model. Several different approaches (customer pipeline, market research, etc) can be used to identify key business drivers. Hohmann argues that these are at the theme or epic level rather than an MMF (minimum marketable feature).

Finally, it is critical that product releases satisfy internal and external stakeholders. For me, this is perhaps the deepest insight in this blog. Product owners need to listen to and support a wide constituency for a product to reach its potential value to an organization. In my work as a coach, I sadly notice internal stakeholders such as architecture, support and services are frequently ignored. If you haven’t already used them, Innovation Games® are a great way to understand and make choices.

Below is the presentation I gave at STC (Society for Technical Communication) Management Day in Toronto last week. Technical communications as a field is moving out of just documentation into more value-added activities such as facilitating shared understanding and agreement between diverse groups. As well, getting involved early to reduce documentation required by helping ensure software aligns with users needs.

Ken Schwaber has a great presentation where he talks about the Innovator’s Dillemma and how companies build a (design) dead core.

A typical (success) story

• Management – we need to hit the date.
• Developers – OK, we’ll cut quality but won’t tell you.
• Success! We made the date. We’re heroes!

BUT, this is a horrible long term strategy because you get a design-dead core and can no longer ship product.

Design-dead core

Do you have  a design-dead core?  Here’s a quick checklist (see mindmap below):

1. The code is fragile: difficult to work with and things break unpredictably
2. Little or no automated test harness.
3. Few experts who really understand the technology.

Innovator’s Dilemma

The purported dilemma is that you need to choose between fast delivery and maintainability. So, if you want to get to market fast you need to take shortcuts that are going to hinder you in the long run.

This is also called the inventor’s dilemma.

Agile to the Rescue

Teams that follow Agile practices avoid this peril in two ways.

By managing features and scope, teams can find the most valuable software to deliver by a certain date.

Technical practices such as automated testing, continuous integration and refactoring keep a code base healthy and maintainable. They also helps teams go faster.

Release Burndown to illustrate the Innovator’s Dilemma

Consider the chart below. Companies start at burndown line A. If they use Agile, they will stay there. Most companies don’t. So, release by release, they accumulate technical debt and the code base decays.  After a few years, they build a design-dead core.

As a coach, I like to show teams the chart below and vote on their code base. Many companies are at line C with some area’s that are D.

Help! I have a dead core!

OK, so you’ve got a dead core. Sad news. There are ways to recover. I’d suggest you start with Michael Feather’s book Working Effectively with Legacy Code.

Watch the video

The whole video is great, but for the part explaining the Innovator’s dilemma check out:

• Start: 35:38
• Stop: 45:07