State of Agile Survey 2015 - Version One

Annually Version One does an survey of the state of agile.  Very useful.

I am not sure it is a scientific survey, but it tries and it generally does give some useful insights, even though they cannot be said to be scientific truths.

See here.

To me, it says we are making progress.  That is, more people are using Agile, and lives are getting better.  Or that’s what I  infer from the survey and what I see.

Equally, we have a long way to go.  While a few teams are getting outstanding success, there are many many teams that could be doing agile far far better.  And their customers (and their firms) could be enjoying that success. And that greater success could be achieved by working fewer hours with less stress.

Why?  Or, what do we do about it?

1. Change the culture.  That is, our firms have a ‘waterfall’ culture that works counter to the success of agile.

2. Focus on the magic of the Team.  Hmmm. If you do not know what I mean, it is hard to explain.

3. Fix impediments aggressively.

4. Enable more self-organization and let the teams know they are responsible.

5. Do Scrum and agile more professionally.

6. Scale less.

7. Scale more professionally.  By this I mainly mean, add one pattern at a time, and get each pattern to work professionally before adding more ‘scaling stuff’.

6. Co-locate more. (By co-locate, I mean a team room. The data show this doubles team productivity.)

Note: We can reach hyper-productivity with scaled and distributed teams.  It is just much harder, and I think productivity is lower than it could have been. (But we have minimal data to confirm or deny my hypothesis. AFAIK, no one checks these facts in anything like a fair way.)

****

I would be interested in your ideas on how we move forward more successfully.

Scrum Requires Effort

It seems that many people expect Scrum to make magic happen by itself.

This is of course an illogical expectation, mostly.

It is true that Scrum (the roles, meetings and artifacts) will, with a bit of introduction, cause your team to get better without much additional effort or investment.

But the real power of Scrum comes when human energy really gets behind it.  And this does not always happen, and seldom happens if they just wait for the magic to happen.

The Scrum framework to some degree elicits that energy, but people also must be expecting to give the energy, be willing to do it, and  then actually do it.

How does this work?

1. Scrum has a subtle effect on the Team, so it becomes, a real Team.

In caring about each other and the customer, the Team works together effectively.  What I am trying to describe is a subtle but profound change in attitude by the Team.  One might say, about the work.  An attitude of full responsibility, helpfulness and fun.

There are many ways to describe this.  I fear my paragraph above is weak in comparison to the real effects that are possible.

Effort?  Well, the effort is the challenge….to change the paradigm you and your colleagues use.  This is difficult.  And no one has done it perfectly.

2. Make an impediment list, and work it.

The list comes from the Team, but the SM is making sure that someone is always working the list, whether that person or those people are inside the Team or outside the Team.

The first effort is to identify the real impediments, and put the moose on the table.

The next effort is to slice and dice the list, and order it appropriately.

Then take action on the top impediment over and over again, until the Team is ‘almost’ perfect.  The relentless pursuit of perfection takes a lot of guts to keep after.

As far as I know, there is no known limit to human improvement except that we limit ourselves.

To quote Henry Ford: “Whether you think you can or you can’t, you are right.”

3. The next great effort is to use metrics responsibly.

This does not, mean no metrics.  It means being critical of the metrics, and continually asking if they are accurate enough.  And are these the best metrics.

4. The final effort for today:  Using the 80-20 rule.

That is, focusing on the high value stuff (I call it the gold, platinum and diamond features) and releasing more quickly.  Then saying ‘no’ to the ‘dirt’ features, and moving on to the next mine shaft (the next product).

This takes extraordinary effort.  But it is extraordinarily valuable to everyone to do it.  This effort is led by the PO; but involves the whole Team, the business stakeholders, and others around the Team.  Typically, this notion is a huge ‘cultural transformation.’

Related to this cultural transformation is a shift from ‘doing everything at once’ ( for example, having too many projects in flight) to doing the top project ‘only’ (per team), and getting it delivered. (Similar to the Lean concept of single-piece continuous flow, but at the ‘project’ level… so companies new to this, think of it that way.)  Again, a huge but necessary transformation in so many companies I see.

Lots of effort that is NOT ‘just’ doing the Scrum framework.

***

Your comments please….

Short Scrum and Long Scrum

There are many many ways to play Scrum. In some sense Scrum is infinitely flexible.

But let us pretend for a moment that there are only two types of Scrum, which I will call Short Scrum and Long Scrum.

Short Scrum

In Short Scrum, maybe where a Sprint is completed in a day, we do not have a long Product Backlog. Maybe the Product Backlog only contains enough work for one day or maybe two days (one or two Sprints). Imagine also that a ‘whole product’ (however we define ‘product’) or release can be completed in one or two days (one or two Sprints) or less.

With the Sprint length of only 1 day, we might have ‘Daily Scrums’ every hour (e.g., over an 8 hour day). The Sprint Planning Meeting might last 20 minutes. And the Sprint Review at the end of the day might last 10 minutes. And the Retrospective again might be 10 minutes.

Short Scrum would be useful when a Team has lots of small things to do, and those things are changing quickly (e.g., daily, and maybe being identified during each day). (For now let us assume still that the Team is the ‘ideal’ size of 7.) And you want feedback very quickly (each day). And the Team can build ‘working product’ (something that can be demo-ed that is in some sense complete) in 1 day most of the time.

Obviously ‘Short Scrum’ is a special situation or set of situations. Still, there might be many situations in the US (or the world) like this. Thousands or millions.

And, obviously, some situations might be similar to this, but not have exactly these numbers.

Getting the feedback every day can be enormously helpful.

One classic example is a small family doing a set of chores over the weekend.

This model also implies a high level of interaction in the team, during the day.

Also note that the concept of ‘long term planning’ has little meaning. Maybe long-term planning might be planning for the week. And note that Scrum (the simple framework) does not mandate any Release Planning.

The Velocity concept might be minor or not there, especially if it is not useful. For example, if the

Team is taking on a different type of work each Sprint (each day), then Velocity is unlikely to be consistent. Also, since a ‘release’ is happening every day, there is probably less need or no need to have the forecasting knowledge that velocity can give the Team. Still, in terms of continuous improvement and perhaps for other reasons, velocity might still be useful.

Few or none of these ‘criteria’ are ‘hard and fast’, but one certainly can imagine situations like this.

Long Scrum

In Long Scrum, imagine the Sprint is 2 weeks long. And imagine that it will take several Sprints (e.g., 8) to complete the product (meaning possibly: release the first release of multiple releases).

The Product Backlog might be very long (e.g., 6 months of work or more), and might include items that we might never get to.

The Sprint Planning Meeting might be as long as 4 hours (although usually somewhat less), and a Sprint Review might last as long as 2 hours (if useful). And the Retrospective might last 90-120 minutes, and of course help the Team increase their velocity.

And we have the ‘normal’ 15 minute Daily Scrums.

This type of Scrum is more useful when the Team has a big mountain to climb, and has some understanding of the mountain beforehand. (The mountain is a ‘product’ with a decent vision of what the product will become. The product is anything that that Team might ‘build’… tangible or intangible, physical or electronic or ?. But we do want the pieces to be demonstrated.)

Imagine that the Team has the worked divided into 8 small pieces (small stories) for each Sprint. And it takes some time to get each piece to be working. But, at the end of 2 weeks, all 8 pieces can be working. And it is useful to get feedback from business stakeholders: ‘do you want what we have built so far?’ And the right people will come every 2 weeks (in part because we have built enough to interest them).

The Product Backlog might still be changing, but the basic scope of the product is not usually changing a lot, or at least we do not expect it to change that much. We at least think we know what to build each Sprint, although in the Demo we sometimes discover that the business stakeholders do not like some pieces (some stories).

In this situation the concept of long term planning (well, planning over the 6 months, which would definitely seem ‘long term’ to the Short Scrum team)… is useful. And needed, necessary. In part because the business and the customers and the marketplace require some relatively good prediction of when the product will arrive or that ‘it’ will arrive by X date. Time is quite key in this way, at least usually.

So, Velocity is more needed. And more do-able, in part because the work is relatively more
consistent. And the Team needs to stay together, so they have time to discover their real velocity.


***

I have three main points in describing Short Scrum versus Long Scrum.
1. Scrum can be played many very different ways, and yet all can be called Scrum.
2. Some of you will mainly be playing Short Scrum….where the work is changing frequently and being identified only a few days before it is done. Still, you can use Scrum.
3. Short Scrum can seem very different than Long Scrum (to both sets of people), and yet both are Scrum. There are also, of course, varieties of Scrum that are some hybrid of short and long.
Hope this is helpful.
Your comments please…