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.

Related posts:

1. Kanban aligns with Control Culture In my last post, I looked at how Agile Culture...
2. Kanban is Like an Oreo Cookie Kanban is like an Oreo Cookie: Dark Crunchy Control on...
3. Agile Fits Better in Some Company Cultures than Others At XPDays Benelux last November, Pascal Van Cauwenberghe told me...

Related posts brought to you by Yet Another Related Posts Plugin.

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

Related posts:

1. Scrum Alliance Leadership – Acceptance Tests This post identifies acceptance tests for successful thought leadership within...
2. Scrum Alliance Leadership – Models for Success This post identifies two visions for successful leadership within the...
3. Scrum Alliance Thought Leadership Workshop There will be a workshop at Agile 2011 on building...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

Related posts:

1. Scrum Alliance Leadership – Acceptance Tests This post identifies acceptance tests for successful thought leadership within...
2. Scrum Alliance Thought Leadership Workshop There will be a workshop at Agile 2011 on building...
3. Agile 2011 Preview – Innovation Games and Strategic Play with Lego I am heading off to Agile 2011 and I wanted...

Related posts brought to you by Yet Another Related Posts Plugin.

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

Related posts:

1. Scrum Alliance Thought Leadership Workshop There will be a workshop at Agile 2011 on building...
2. Agile 2011 Preview – Innovation Games and Strategic Play with Lego I am heading off to Agile 2011 and I wanted...
3. Scrum and XP are not what you think I learned in the last month that I don’t know...

Related posts brought to you by Yet Another Related Posts Plugin.

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)

Related posts:

1. 5 Ways Scrum Creates Safety (vs. XP) Just had my first article posted to Scrum Alliance website....
2. Agile 2011 Preview – Innovation Games and Strategic Play with Lego I am heading off to Agile 2011 and I wanted...
3. Scrum and XP are not what you think I learned in the last month that I don’t know...

Related posts brought to you by Yet Another Related Posts Plugin.

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.

Related posts:

1. 5 Ways Scrum Creates Safety (vs. XP) Just had my first article posted to Scrum Alliance website....

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

• Scrum or Kanban? YES! and
• Kanban is a Gateway Drug

Here it is:

You may wish to check out the other lightning talks.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I am a big fan of Scrum, however, the notion that there are no interruptions during a sprint is simply not realistic in many environments – especially teams adopting Scrum.

Let’s dream of perfection

A key concept from Lean is to dream of perfection. In this case, perfection is “no interruptions”. This is good as a goal but not as a starting point.

Deliver Value

Let’s face it, there is a lot of business value in keeping a production environment up and running. Almost universally, this is more important than getting that new feature out. Unfortunately, this value is usually a form of waste since there may have been things that we could have done to avoid production issues in the first place. It even has a name: failure demand. When we dream of perfection, we dream of zero production issues.

Oops. We live in a world where there are external events. Yep. It’s true. Even Scrum teams. Maybe it’s more useful to drop a story or shallow out some functionality when some important external interrupt happens rather than abort the entire Sprint.

Ken Schwaber told the story of getting kicked out of a client close to home for attempting to veto the company picnic in favour of focus on the Sprint commitment. I keep telling the teams that they are part of a bigger picture and they need to be in tune with that.

I follow the rule of letting Product Owners swap out unstarted stories for new ones if the team agrees. This comes from XP. Darn, broke another Scrum rule in order to maximize business value.

A separate support team is an anti-pattern

I keep getting asked – hey, can’t we have a separate support team?  Then there won’t be any interruptions. NO! Funny thing is that most technical folks don’t want to be on the support team. But the main reason is that it is very useful to have people developing software fix their own bugs and appreciate what it takes to get something working in production. Otherwise defect rates will climb steadily and that’s the wrong direction to go. We want zero defects, not more.

Most Scrum teams need a Kanban board

For as long as I can remember most teams I have worked with have had a support board where we track the actual hours spent on support. Why actual hours? This gives us history and the ability to predict support workload – very handy information during a Sprint Planning Meeting.

More recently I have used a Kanban board for managing support issues.  See sample photo below.

So now, my thinking is that most new Scrum teams probably need a Support Kanban. How about at your company?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.