Scrum for Software Development

In my earlier post I explained why we needed this. In this one I’ll describe some principles and practices that should be in it

Use some degree of test-first. At a minimum, anytime a request is made the question “how will I know I’ve done that” should be asked

An understanding that delays in feedback, workflow and between getting and using information causes unplanned work

Continue reading “Scrum for Software Development”

Why we need a Scrum for Software Development Teams

Scrum proponents take pride in the fact that Scrum can work anywhere, in any domain. But keeping it in its generic form leaves big gaps in the practices people should be using.

The result of this is often that people have to reinvent things and don’t have ready access to concepts that would guide their adoption. These challenges are exacerbated when the immutable aspects of Scrum need to be modified a little. What often happens is people try to follow Scrum, often referring to the Scrum Guide and what they learned in their CSM class. They should be using Scrum as an open framework as it’s intended.

Continue reading “Why we need a Scrum for Software Development Teams”

Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question

originally posted July 2017. Co-written by Jim Sutton and Al Shalloway

Abstract: This blog suggests that instead of looking at whether we should choose between Scrum and Kanban, we can see Scrum and Kanban as process patterns and benefit from the best of both.

Scrum and Kanban are often presented as “solutions” for developing software within an organization. Yet every real organization combines unique histories, personalities, and individual skills and beliefs. Even the best off-the-shelf “solutions” require variations to fit the context of the real organization to which they are being applied. If the adopted approach is not designed for these variations, the results will be less than hoped for.

Continue reading “Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question”

Framework Tunnel Vision

Originally posts August 2013.

Disclaimer: I could have named this framework/method/process tunnel vision, but that seems a bit redundant. So don’t infer I mean to pick on any Agile approach that is a framework over one that is called a method or a process. I am just using the word framework generically. For the purposes of shortness, whenever I use “framework” in this blog, pretend I’ve said “framework/method/process/…”.

Continue reading “Framework Tunnel Vision”

How a framework just implying what needs to be done causes damage

Scrum proponents have long espoused that Scrum is intentionally simple and expect the teams to figure out what’s needed. I have never understood the validity of this approach. Simple is in the eyes of the beholder- a simple starting point may be simple for some but not for everybody. Being incomplete requires reinventing the wheel. Admittedly being more complete without adding complexity takes more effort to create. But that’s a methodologist’s job.

Continue reading “How a framework just implying what needs to be done causes damage”

Why We Need a New Meaning / Name for Kanban

Originally written July 2013.

What Is Kanban?

When Kanban first came out for software development, it was not the Kanban Method. It was A Kanban System for Software Engineering. It was a system for managing flow in software development and maintenance teams. It was developed over a few years by several different people at Microsoft and Corbis. It was essentially what I have sometimes referred to as “Team Kanban” and is actually what most folks mean by Kanban. David Anderson’s book, Kanban: Successful Evolutionary Change for Your Technology Business, introduced the Kanban method, a way of effecting evolutionary improvement. In many ways the Kanban Method is little more than Lean Kaizen with a particular starting approach and with some additional, sometimes useful, practices (e.g., service level agreements). I tried sorting this out a couple of years ago with my article Demystifying Kanban and several webinars on that theme that Kanban is an overloaded term meaning all of the following:

  • A signal card and usually referred to as “small k Kanban”
  • A team management method using Kanban to manage flow and usually referred to as capital K Kanban. This is essentially the original Kanban system for software engineering which I will refer to from this point on as Kanban Software Development
  • A thought process
  • A transition, or education, method (the Kanban Method)

While I have been troubled about this for years, even suggesting years back that we needed to come up with different terms for different things, I thought it mostly was an annoyance, but not dangerous. Recent insights and events has had me shift my thinking here.

It is quite clear that a number of Kanban consultants, particularly those in Lean Kanban University, are attempting to usurp the term to mean that Kanban is the Kanban Method and that any use of Kanban other than the Kanban Method is a “shallow implementation of Kanban.” I am not trying to draw any aspersions to their motivations for this. I am certain they feel they are doing what is in everyone’s best interest, as the Scrum folks did when they blurred the terms Scrum and Agile. But I do not agree that equating Kanban (in the sense of the original Kanban) with the Kanban Method is beneficial for most in the industry.

Kanban and Lean

I have long felt that Kanban (both software development and method) is a subset of Lean Software Development. Our industry will forever be indebted to David Anderson, Jim Benson, Corey Ladas, Darren Davis, and others who brought Kanban into existence. Kanban software development opened ways of doing Agile software development to companies for which cross-functional teams were either impossible or prohibitive or who couldn’t otherwise make the jump to Scrum.

Focus on the work, not the framework

Talk to most any team that is having trouble with Scrum and you’ll see some common patterns of problems:

  • can’t write small stories
  • work doesn’t get finished within a sprint
  • requirements are not clear

Learning how to write small stories with agreed upon acceptance criteria prior to writing code would be a good idea. Continue reading “Focus on the work, not the framework”

What We Can Learn From Mob Programming

Originally published Dec, 12, 2017

First, full disclosure. I have never used or even seen mob programming.  When its creator, Woody Zuill, first mentioned it to me I was intrigued but wasn’t sure it would work efficiently. But, knowing Woody, I didn’t doubt it worked. Just figured only for small, independent teams.  After talking to him recently I have changed my mind. This blog is my understanding of mob-programming now, inspired by Woody’s insights. Attribute anything valuable about mob-programming to Woody, anything incorrect to me.

The question for me about mob programming has always been – how big can you go with it?  I have known that paired programming was good (having done that).  Of course, people ask the same thing about that as well – how can two people doing the same thing be effective?  Of course, that’s a misunderstanding – they are not doing the same thing – they are working together. So, we already know that micro-mob programming (a mob of 2) works.  But what’s the upper limit?  How would you discover that?

In the conversation I just had Woody told me:

With some questions it’s very useful to identify an “opposite” question.  This can lead us to finding more meaningful questions. He said the first question he was ever asked while speaking about Mob Programming was “how can you be productive with five people sitting at one computer?“

The reverse question he came up with was “how can we be productive if we separate the people who should be working together?“ The purpose of asking the reverse question is to show that there are more possibilities in the questions we could ask, and in particular when the original question is not easily answerable. This led him to a slightly better question, which is “What are the things that destroy productivity?”   And of course, productivity is probably not a good thing to strive for, and he usually prefers to talk about effectiveness.

So what destroys productivity (or effectiveness)?

  1. Hand-offs
  2. Waiting
  3. Meetings
  4. Unfinished code that you’re not actively working on
  5. Unclear understanding between team members
  6. Delayed feedback on errors you’ve made
  7. Integration problems

There are probably other things not listed. Woody tells me these things don’t happen when you do mob programming.  While I have not seen it, I believe this to be true because Woody is a very trusted source whose only agenda is helping people. It also makes total sense when I stop to think about it.  Furthermore, when I look at teams whose individuals don’t work together I see these things taking up about 80% of their capacity. So even if mob-programming is a bit less efficient because of more people working together than is needed, the elimination of 80% of what teams normally do probably more than compensates for that.  It also produces higher quality code and a broader understanding of how it was built – meaning the team won’t run into the constraint of only one person knowing how it was written.

So how many is too many? I like the observation – “In theory, theory and practice are the same, but in practice they are different.”  So I’m not looking for a theoretical limit.  The real question is when are people not contributing?  Contributing doesn’t mean just doing the work but includes learning since that, as we mentioned, improves the people and the organization. Woody, of course, has thought this through. This is one of the great things about him – he’s not trying to promote or defend anything – he’s just looking for what works. So, the solution is easy – just people the option of self-selecting out when they feel they are not making a contribution. They will still be close by when needed.

There is another aspect to mob programming.  It sounds like fun.  So give it a try and pick a number you feel comfortable with.  Then try a little bigger (remember, people can self-select out).  Having fun has clear personal value, but also clear business value.

Al Shalloway
CEO, Net Objectives

Postscript: I talked to Woody at the Deliver Agile conference in Nashville this week. Here’s another point on mob-programming. It’s all about flow and true value delivery. When I consider that most organizations are running at around 5% efficiency (not a typo – five per cent) then mob-programming, even if it were a slight waste with 5 folks around at once, would be a massive improvement).

Step 1: Acknowledge the need to move from a team focus to systems thinking

“We cannot solve our problems with the same thinking we used when we created them” Einstein

The team focus of 2001 is no longer viable. Early adopters could adopt Scrum without regards to the bigger picture. The key was having a cross-functional team that Scrum and XP were designed for.

But as soon as Agile spread beyond one team, it ran into challenges. Team dynamics are different from organizational dynamics. Scrum ran into problems because forming cross-functional teams required committing someone who was needed on several teams to one team. Agilists didn’t have methods that solved this problem.

Continue reading “Step 1: Acknowledge the need to move from a team focus to systems thinking”