4 Announcements

We are happy to announce 4 things.

1. New LeanPub Book: Joe’s Agile Release Planning.

Some of you may have seen a prior draft. It is revised now. And published. I expect to have some further revisions.  I seek your feedback.
You can see it here.

2. New Workshop: Story Splitting (Feature Decomposition)

This is a 1/2 day workshop, with David Muldoon. We are doing this workshop first in Toronto, Oct 11, in conjunction with a CSM Course (Oct 8-11).  We will be doing it at other locations soon.  See Courses at LeanAgileTraining.com.  See here for details about the workshop content.

3. New Workshop: Scaling

This is also a 1/2 day workshop, with David Muldoon. We are doing it first in Toronto, Oct 11, in conjunction with a CSM Course (Oct 8-11).  (This and the Story Splitting workshop form a 1 day workshop offering.)   We will be doing it at other locations soon.  See Courses at LeanAgileTraining.com.  See here for details about the workshop content.

4. Lean Agile Training page on LinkedIn

We have started a Lean Agile Training page on LinkedIn, here. Please visit and follow us. And please tell us what you think we should provide there.  What do you like?  What should we add?  What should we subtract?

More success with Scrum - How to get it

Fernando Cuenca has an excellent blog post, here.  He discusses what he learned at Agile 2013.

I will summarize his learnings in my words.

1. The ultimate question is: how to have a better life for yourself, your Team, and your Customers.  And then, specifically at work, using Scrum.
2. Measure velocity. And specifically, look for increases in velocity. Otherwise known as: acceleration.  Measure velocity in Story Points.  But don't become obsessed by a number -- look at the bigger picture.
3. Get the user stories 'ready, ready' before the Sprint Planning Meeting.  It will increase velocity. In part by reducing churn in the sprint.
4. Have a clear DOD.  Definition of Done.  Being ready, ready will help you get to done, done.
5. Do a better Daily Stand-up.  Who knew the Daily Scrum was for the Team to self-organize and self-manage?  (I am teasing all of us -- not teasing Fernando at all.) I like this formulation:  'what did I complete yesterday that helps the Team achieve our sprint goal?'  The Team focus is important.
6. Measure Team happiness. (See Jeff Sutherland's Scrum Log.)  If they aren't happier, you aren't doing Scrum right.
7. Focus on fixing the top impediment.  By the ScrumMaster (who is driving it), by the Team, by people outside the Team. Non-trivial work.  You have a biggest impediment until you are perfect.  And even after you win the Super Bowl, you are not perfect. (20 push-ups for imagining that your Team won the 'Super Bowl of Scrum' when you have never even compared your Team to a 'best in my city' Scrum team.)
8. No bugs (use XP practices, etc). Ok, 'no identified bug survives the sprint'. May seem impossible to some of you, but it is not. (Yes, some few bugs will still be identified in production.)
9. Clean, well-refactored code base. (use XP practices, etc). Makes it almost easy to change.
10. Develop a 'continuous delivery' capability. (By removing impediments over time.) Almost always, this pays tremendous dividends, even if you almost never deploy after each sprint.  At least you will be able to decide when to deploy (when you have a Minimum Marketable Feature Set) and then deploy 'instantly'. One reason: The bad news doesn't get better with age.

This is a great list of 10 'things to do.'

Fernando adds some comments about the cost of implementing the XP practices. To me, these costs seem too high and the benefits are delayed too much.  In my experience, at least.  But, he is right to say that the costs are significant. Still, the benefits are far more significant!

Hope these ideas help you, your Team, your Customers.  You can get a lot better (we all can).

Story Splitting (Feature Decomposition)

We have added a 1 day Workshop to our course in Toronto. And will add this to courses in some other cities.  The one day is composed of 1/2 Day on Story Splitting. And 1/2 Day on Scaling.

What.  Story Splitting is always required. We always need smaller stories in the Sprint. Some experienced Teams do this regularly and quite effectively, but lots of less experienced Teams struggle with this. So, the immediate purpose of the workshop is to move them beyond the 'struggle' stage more quickly.

Value. Story Splitting is not the only factor that can assist your Team to achieve the following benefits, but it is important, and often key.

• More reliability. When they 'commit' to 20 story points, with the smaller stories, they are more likely to hit 20 story points.
• Faster velocity. It seems paradoxical, but by taking the effort to get to smaller stories, the Team can get more done. If they do it professionally and cleverly.  Many reasons for this. One of my favorites is: "The bad news doesn't get better with age."  Also, the Lean community explains this well.
• Fewer and smaller failures. Sometimes a Team will not get a story completed in a Sprint, as they 'committed.'  To some degree, this is normal in innovation work. Unexpected things come up.  If we have small stories, first the likelihood of failure goes down.  Second, the degree of failure is smaller. We don't fail on 50% of the work, but rather on only 13% of the work (as an example).
• Team Morale is better. For the reasons stated above. Sometimes the Team will not at first understand the value of small stories; and it may seem like extra work to them at first. This must be explained. But once they are over that hurdle, Team morale should go up.
• The sense of 'traction' is better. As suggested above. Almost every day we can see a small story being completed.

See here for a fuller description of the Workshop.

Impediments - From the Charlotte Class in Sept.

Here are some impediments identified in an exercise by the Charlotte CSM Class in September.

Some duplicates (or very close to), some overlaps.

May this list make your Team more creative about identifying impediments. May it lead to your Team fixing the highest priority impediment first.  Which might be: making a public impediment list.  And then working on the top item each day.

The List:

• Personal Agenda
• Hierarchical approach
• Understand tasks (tasks not understood, I think)
• Structure (too much)
• Micro Mgmt
• Pressure & Stress (too much)
• Over-communication
• Mtgs (too many)
• Priorities all-over (...the place)
• Undefined requirements
• Complexity
• Synergy issues (dysfunctional team)
• Skill sets (Engineers & DBAs)
• Focus
• Resource Constraint
• Customer Sat.
• People and Resource Availability
• Lack of stakeholder buy-in
• Waterfall
• Too many priorities
• No business value
• Multi-tasking
• Lack of Mgmt Support
• Lack of communication
• Conflicting Priorities
• Out of Scope
• Limited Resources & People
• Lack of Resources & People
• Over-budget
• Mgmt Disagreement
• Unclear Requirements
• Lack of Requirements (in some areas)
• Inaccurate requirements
• Ego
• Leadership
• Lack of Buy-in (by Team)
• Lack of budget

Getting the right people in the Team - Richard Branson

For useful innovation, truly good and fast innovation, we think a Team is essential.  They must do knowledge creation in a Team. As Takeuchi and Nonaka have explained pretty darn well.

A real team, not a group of individuals.

As a friend just reminded me, probably the most important thing in getting a Team started is to bring a good Team together. Get the right people.  Frankly, with a great team, you probably could use almost any process, and succeed (although I have a strong bias and experience that suggests that Scrum is the better 'process framework' for them -- if they will do it decently).

And each Team is different.

Here is a post by Richard Branson in LinkedIn that I thought was really good.  He talks about focusing on 'personality'.  Well, at least do not put too much emphasis on the skill sets (aka knowledge domains currently mastered).

And he talks about introverts.

Full disclosure: I am rated an extrovert by Myers-Briggs. Not sure I believe it. I feel a lot like an introvert these days.  In any case, I love introverts (people more introverted than I)... and I learn more about other kinds of people each day.  Every type has something to offer. Fascinating.

Some of you may actually know an introvert or two. ;-)

Anyway, Branson gives some good advice about how to judge introverts. And how to work with people more generally.  For example, your Team may need a 'maverick.'

Enjoy the post.

Scaling: Don't forget the Team

What do you have if you have good scaling but all the Teams are terrible?  Nothing.

What do you have if you have lame scaling, but all the Teams are good?  Something that is still pretty darn powerful.

***

What often happens when 'everyone' is talking about scaling?  They forget about the Teams.  And the Teams often feel "we're not important anymore -- we don't do anything important".

As Tolstoy described well in War & Peace, the HQ people in the military always think that 'they' really fight the war.  It is the natural and inevitable tendency of these people to think they are important.

When in fact the battle is won or lost in the trenches.  By the small units on the field.  Or so Tolstoy thought (or at least Prince Andrei thought).

Another problem: When we scale we put really smart, overly-clever people in charge of 'figure out the scaling'. Well, it does feel like a complex problem.

But guess what?  The biggest thing we need in scaling is... Simplicity!  A simple clear way of communicating between the Teams.  Something where everyone knows 'how the machinery basically works'.

And guess what the clever guys do: They make it so complex, that only they understand it. And everyone in the Teams feels lost.

So, my advice is simple. No matter what I say, many of you will still do scaling and too much 'scaling'.

So: Remember to put (keep) most of the focus on the individual Teams.

***

This is not to say I am against all scaling. If Napoleon is invading, I will get as big an army as I can get to fight him.  (And there is a rough analogy to our work.)  But God, watch out for the law of unintended consequences.  Focus on the small units. And build your Seal Team 6... and 1, 2, 3, 4, 5, 7, 8, 9....  Loose, self-organizing units that can self-organize (a lot) how to interact with each other.

Frameworks to Scale Agile – Some comments

First, here is a page that starts to explain SAFe.  SAFe is one of the better known ‘scaling agile’ frameworks.  http://scaledagileframework.com/

You should also look at Larman and Vodde’s book: Scaling Lean and Agile Development.  See also their LeSS (Large-Scale Scrum) framework, here.

Next, Jeff Sutherland and Jim Coplien and others have worked hard on ScrumPLOP.  This is the patterns around Scrum.  This deals with more than scaling, but includes many scaling patterns.  See here. As one example, see the Chief Product Owner pattern.

Next, here is a blog post by Ken Schwaber.  Many of you know that Mr. Schwaber is one of the co-creators of Scrum.
http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/#!

Next, here is a longer blog post by David Anderson.  Many of you know that Mr. Anderson is the main advocate behind the agile “Kanban” method. (I say it that way because I think of kanban first as the ‘signcard’ idea that Lean uses.  Which is notably different.)
http://www.djaa.com/kanban-anti-safe-almost-decade-already#!

A few comments by me:

First, I think Dean Leffingwell is a good guy who is trying to help.  Some want to paint him as the devil, which seems silly. But whether all our ideas that ‘wish’ to help are, in the end, truly helpful…. that is another question.

There are a lot of ideas in SAFe that I know and love. What troubles me more is the ‘weight’ of the whole framework, not individual things in it.  The implications of the whole thing.

In general, I think Anderson and Schwaber don’t agree very much on ‘things’ in general. Hence, I am struck by is how much they agree about SAFe.  Their concerns to me are very similar.

I simplify their shared concern as this: ‘SAFe has some good ideas within it — maybe even all the individual ideas are good — , but the strong bias will be to implement it as a single big turn-key heavy almost ‘waterfall’ solution. No matter what the stated ‘intention’.  And no matter what the particular situation. And this is likely, in several ways, to be unhelpful.’

I want to note that I understand Dean Leffingwell has said that he does not want SAFe implemented that way.  To which Schwaber and Anderson might say: ‘Well, he may say that, but de facto something else happens. I’d rather discuss the reality than his words.’

My general biases are these:
* some scaling in some situations is inevitable.
* In general, some scaling is not really necessary or useful. The answer should often be: “One real Team, one really good Team, would be better for this.”  How much is ‘some scaling’?
* in general, all scaling is ‘ugly’ (my technical term for it, which I need to explain more).  Mainly because communication across more than 7 people is really hard.  No amount of lipstick on the pig will make it less ugly. Still, some things might make it ‘more effective’.
* in general, all scaling would benefit by a KISS approach — keep it absolutely even more simple than you can possibly imagine.
* all talk of scaling inevitably mis-directs attention away from the core engine of activity: the Team.  This is not good; minimize it!!!
* inevitably, ‘smart people’ involved in ‘the scaling part’ want to assume more importance and more control than they should.  Greater importance and control should be given to the Teams.
* in the end, there are trade-offs.  OK, you must decide your trade-offs in your situation. BUT: KISS. KISS! KISS!!!

Some notes:
* I think that the term scaling should be restricted to having multiple [Scrum] teams work together.

* I think ‘broader agile adoption’ should be used when you want to have more and more teams use Agile. Perhaps all teams.

* I think Agile Transformation should mainly mean having the whole organization become truly agile, in values, principles, and practices.  Not just the ‘development’ department (or whatever your firm calls it).  However, it is fair to say that just introducing Scrum to a few teams almost inevitably leads to a kind of ‘transformation’.  It tends to affect, as we say, ‘everything.’

* I think Distributed Agile or Scrum should be restricted to these two situations: (a) one team has members in more than one location (ideally only two locations and only one time zone), or (b) two+ teams must work together, and each Team is in a different location.  I would prefer that (a) was called ‘distributed team’ only.

* As it is now, all these terms are used quite loosely.  So that real communication is low and mis-understanding is likely high.

* In general, many firms attempt (a) Scaling, (b) broader agile adoption, (c) Agile transformation, (d) distributed agile (both versions) — all at once. As soon as one recognizes this, the benefits of KISS are apparent. (One hopes the benefits are apparent.)  As if by magic, the word cluster-bomb comes to mind.

What does Scrum do?

To be honest, Scrum doesn’t ‘do’ anything.  Scrum is just a basic framework (which includes some values and principles).  It depends completely on the people on the field.

In a similar way, Bill Belichick doesn’t do anything.  (Belichick is the coach for the New England Patriots, which while he has been there, has been a very successful football team. Someone thinks he is worth a couple of million per year.)  He does not play football. He does not win any games. Himself.  His teams, on the field, executing his ideas and following his program and his coaches, they win the games. (Or lose. They have lost some Superbowl games, even.)

Scrum is just a bare framework.

You and your team must add things to it.

You and your team must execute well.
You and your team must remove impediments (ex: big fierce burly enemy linemen).
You and your team must run up the middle.
You are your team must risk an interception.
You and your team must recover from mistakes on the field.

But Scrum helps.

What can be said for Scrum?

Well, it replaced all the “stupid, in the way, bothering-us” stuff with a fairly light framework.

This is actually a huge improvement. At least with Scrum we are no longer held back by all the stupid stuff that was waterfall (or maybe the chaos of our homegrown ‘no-process’). That is actually a huge plus. But that part is only a win in the sense of removing a huge negative.

Scrum is mostly ‘not in the way’.  Helps us see.  And, if we agree to see the truth, Scrum will help us see the real situation we are in each day, and at the end of each Sprint.

In other words, Scrum sets up a basic learning process.

You and your team must actually see, learn, improve.  And then win.
You and your team must use the tool well.

***

To be honest, I see some people who expect Scrum to magically fix everything. It does not.

Scrum helps you see (and mire than just see), …but still you and the Team must do the hard work of fixing, one thing at a time, all the impediments. For example.

Starting agile adoption

Imagine that you have gotten some interest in Agile. Perhaps you read a book, and talked with a friend who is doing it at his firm.

And then you take a Scrum course.

Now what do you do?

Let’s take a middle of the road case, where you have a software development group of 80 or so, and business people for another 20 people. You are one of the 80.  You’ve come back to the office on Friday morning. You want to do something with Scrum, but you are unclear where to start.

Here are some ideas.

1. Take a deep breath.
You are a beginner. You won’t do everything in one day, and there is no need to do everything in one day.

It will be a long, up-and-down climb. Get ready.

2. Convince some people to do a pilot.

Talk to some people who seem interested. Get them more interested.  Ask if they would like to try it.

Talk to a boss, and ask if he would be ok to try it. Maybe 6 Sprints (2 weeks each).  One Team.  Probably the pilot would be longer than 6 sprints, but you ask him to commit to at least 6 sprints as a fair trial.

3. Do the pilot

One team, 7 volunteers.  Get people who want to try it.

Work hard to make it successful.  Get some important impediments removed!

Almost surely, by 6 sprints the Team will be clearly better than what you all used to do.

4. Tell good stories

You have to tell the stories of success. Of how and why it was better.  About some happy people.
About some good numbers.  Depends partly on your culture.

5. Continue the first pilot and start a 2nd pilot

Make these a success.  Again, get volunteers.

6. Consider a Open Space event

About now, you may have some momentum.  And also a sense that some things must change to make this new thing (agile) work better around here.  Use the Open Space event to identify and attack those key impediments.

Both impediments to the 2 existing teams and impediments to a broader agile adoption.

7. Deepen the existing 2 Teams

The deeper and stronger they become, the more they become hardened ships that can cut through the deepest arctic icebergs.

Build their stories till the stories start to sing themselves.

8. Widen the teams.

Add another 2 teams. Do not widen too fast.  Take care of these teams. Remember that they are new.  They need more help.  The culture is now feeling a threat, and is starting to resist.  The volunteers are not quite a gung-ho.  The overall complexity is mounting.

Do not widen the agile too fast. Give yourself (and those you have gathered) enough bandwidth to support these new teams properly. And still support the 2 original teams.

9. Start an management IRT

IRT stands for ‘impediment removal team.’  This Team (and it may be part-time) takes as its backlog some of the impediments from the 4 existing teams. And the managers in this team must deliver, sprint by sprint, solutions to impediments.  Implemented solutions to reasonably sized impediments. One each sprint.

It keeps the managers off the streets. Gets them actively supporting agile.

10. Rinse and repeat.

Well, there are many more things that could be said.

But continuing to do these same things, as the adoption widens, is not a bad idea.

And it allows me to close this blog post for today.

The ScrumButt Test (4): You know who the product owner is

In this series, we are going over each question in the ScrumButt Test.

The first section (the first 3 items) of the ScrumButt Test is a quick determination: are you doing incremental development? Then second section is: are you doing Scrum?

We are now up to the first question in the second section is: Do you know who your Product Owner is?

Clearly, it is not just “do you know his or her name?”

The most important goal of the Product Owner is to maximize the Business Value delivered by the Team to the Customers.  (Note: We did not define the time frame to do that in. But the PO must define that, or get it defined.)

The Product Owner has these responsibilities in Scrum:

• Defines the features that will make it into the product, decides each release date and content – gets product backlog ready
• Is responsible for the profitability of the product (ROI)
• Prioritizes features according to market value or business value (mainly)
• Can change features and priorities at the next Sprint
• Accepts or rejects work results

A few comments.

The Product Owner is the main voice of the business side into the Team. She is responsible to assure that the team understands everything the business can tell them about the effort (high level and low level).

The Product Owner is the main risk manager, since most risks are ultimately business risks, and must be managed as trade-offs against other things (values, risks, costs, etc). At the same time, the team members are seen as business people also (they signed up to deliver business value), so in some ways managing risk is a collaboration. But when the final decision must be made, she (the PO) must decide (at least, if it is decided within the team).

The Product Owner is part of the team. (This was debated for awhile in the Agile/Scrum community; the PO is part of the team.)

The Product Owner also has outward facing responsibilities. Most of the team members work within the team, in most senses of that word. The PO is also responsible for understanding the customers (eg, end-users). This takes constant work, since the customers are always changing.

The Product Owner manages the business stakeholders. The business stakeholders are people outside the team (‘chickens’) who have a stake or a say in the product being created. Maybe the product is mainly for external customers, but operations must use it also. Maybe Legal or Compliance has some say, etc, etc. In large corporations, these business stakeholders take a lot of work (or so it seems to be required). A key area in managing the business stakeholders is getting down to one prioritized Product Backlog, at least the Product Backlog items for the next Sprint.

So, how much time does the Product Owner spend with the Team? There is no precise answer to this question; it depends and it varies. But the Product Owner should work with the Team at least as much as the Team wants. And the Team should want the PO as much as having her will improve the product (speed, accuracy, more value, better, cheaper, etc). It is seldom that one can learn too fast or too much.

The typical situation I find is this. The Product Owner (the person) and the Team start out not used to working together. And not seeing a lot of value in working together much. But they learn about the value over time. Toward the end of the first effort, the PO will usually say “Wow, this takes a lot of my time to be with the team, but it pays such great benefits! It is well worth the effort.”

Perhaps this ScrumButt Test item should read: “The Product Owner and the Team collaborate well.”

Advice from an experienced successful PO

I was doing a course with Dave Muldoon in Ottawa. And Rich O’Grady visited us.

He had become a very successful product owner in a difficult environment where others had failed (not done well enough).  He mentioned 6 ‘top tips’ on that day, and then he wrote me explaining them a bit more.  What he wrote was pretty much what he said that day.

Here is what he wrote (I added some numbers):

 

1, Transparency

- When I took over there were several teams. Some had backlogs and some claimed to have backlogs. The ones that had “backlogs” were usually owned by the manager, updated by the manager and only viewable by the manager.

- I ran a workshop to create a new backlog for the whole organisation (~40 persons) and it was placed on a wall initially. We had to put it into a tool (JIRA) due to the fact I work on a different continent.

- Everything is on my backlog including defects.

- My backlog is viewable by anyone in the entire company but only I can change an item’s priority.

- This simple exercise in transparency allowed everyone to see what we would be working on and to simply build trust.

 

2. Only my Product Backlog

- Another part of the above exercise was to give a very clear message. The team members can only work from my backlog. If they work on anything else they are wasting my money.

- I forced a couple of teams to stop what they were doing by having executive approval to stop their work. I them told them to look at my backlog and consider what they could do from the top. At this point half the teams actually self reorganized as the team make ups at that point could not fullfil my backlog.

- I encourage team members to generate ideas on how we can improve what we do or how we do it (actually wrt ‘how we work’ – I always listen to them first). However, I want to hear about these ideas when they are at the whiteboard stage.

Continuous Value Analysis

- I built and used a simple and quick spreadsheet.

- I educated my stakeholders about the illusion of accuracy.

- My stakeholders enjoyed being shown at an EPIC level the different relative value points (I can’t easily attach dollars to what I do so I simply used a weighting system across a broad range of categories).

- My stakeholders are now in the routine of a quarterly review where they get to see at an EPIC level progress and if we are still getting value.

- With my teams I do this on a sprint basis. Some times it’s subjective other times there are very clear objective measurements. On a sprint basis I continually prioritize the backlog looking to keep the most valueable at the top.

3. Not the Manager

- I am not the manager (of the people in the Team). I am the Product Owner.

- As a coach to other POs, I noticed this recurring time and time again. The PO would simply be too involved in the team and dealing with issues the team should be dealing with.

- A number of POs were ex-managers so perhaps they were still trying to work as a manager?

 

4. Feedback/DOD (Def of Done)

- Always good!

- Don’t be afraid to say something is not done (0 points and back to the backlog).

- It’s a clear message.

- Essential here is a clear and collaboratively formed DOD and good acceptance criteria.

- POs make mistakes too (we’re all human) and shouldn’t be too proud to admit they got it wrong as well (nice short sprints or attendance to some standups would help).

5. I had a vision

- I had a vision formed by listening with my teams, users and stakeholders.

- It is clear and concise.

- From here “we” formed nice clear objectives (written in the conextra story format).

- Every item of work on my backlog can be linked to one of those objectives.

- It allows us to see the connection from top to bottom as to WHY we do what we are doing (and not doing).

6. Small Items

- I didn’t actually talk about this one but I wish I had.

- Small to me is about 1 week of work for the whole team.

[Ed. Note: The firm was used to 'features' that we often 6 months of work for 1 team. So, these stories are much much smaller.]

- It takes a lot of work to keep the backlog manageable when everyone is trying to add so many tiny tasks on to the backlog.

- Several times I have ‘collapsed’ PBIs else the backlog gets unmanageable very quickly.
- Also I have several teams so I can manage about 20-30 items per sprint but not 70.

 

***

 

Thanks Rich!

Adopting Agile: Ask questions

Some of you know I like Yogi Berra.  And, as a side note, here is a lots of his quotes. I hope you laugh. (Laughter is a great way to influence people.)

Ok, so Yogi Berra reminded us by saying: “Some people, if they don’t already know it, you can’t explain it to them.”  Taiichi Ohno said about the same thing.  You can talk at them for a while, but pretty soon it does no more good.

So, what do you do next?

Well, the Wall Street Journal just published another column by Dan Ariely.  I like that guy.  Here’s the column, which has answers to real questions.

The second question is this:

Dear Dan,

 My daughter started dating a lazy, dumb guy. How can we tell her gently that he is wrong for her without preaching to her, causing her to ignore us or go against our advice?

—Concerned Mother

Guess what he says?  He says preaching at her won’t help much.

He says: Ask her questions. (He assumes, for the sake of argument, that the mother is right.)  They need to be fairly honest, fair questions. And Ariely admits this is a tad manipulative….

Nevertheless, don’t tell your daughter your opinion and instead ask her questions. Naturally, people tend not to ask themselves certain questions. But if someone else asks them, these questions get planted in their minds, and it is hard to keep from thinking about them.

This seemed brilliant to me.

He concludes, helpfully:

And maybe she will reach the same conclusions you have.

To be honest, this is not as helpful as I want. I have two daughters.

But it beats the heck out of no help at all.

I could lie to you, and promise that you can force all the opponents of the change you have in minds to understand that ‘resistance is futile.’ But the sad fact is that they are free to be silly and wrong and foolish.  So, over time, you have to convince them.

Perhaps you wait for that ‘teachable moment’, when the complete wrongheadedness of her position becomes apparent and unavoidable.

But do not wait too long.

What’s wrong with that impediment list?

Let’s pretend that the impediment list that I just posted (the one from the Charleston class) was a real public impediment list.

What would be wrong with it?

First, the most important thing to say is GREAT!  Finally, we have a public list of key things we can work on.  And, if we work on them well, it will make us MUCH better.

But again, imagine it is a list for only one Team…what’s wrong with the picture?

Here are a few ideas…

1. Too many items.

It just is not useful to have more than 20 or so items in a list for a Team.  Then, if new items come up, you ask “Is it more important than anything on our top 20?”  Usually the answer will be no. Until the Top 20 list gets to be maybe 18 left.  In which case, you might add an item to the bottom. (smile)

2. Not prioritized.

Well, you didn’t know that, but I know that they did not prioritize them. And, if you thought about it, I doubt you would have prioritized them that way for your team.

3. Not ordered.

By prioritized, we mean that the list is in order of what ‘slows down the whole team the most’.  By ordered we mean additional ideas: cost-benefit analysis has been included. Dependencies between impediment fixes has been considered. The items have been sliced appropriately (eg, small enough). Etc, etc.  They are in an order that will lead to the greatest improvement in the least time. Cf TOC.

Cost-benefit analysis means that someone (or more than one) has made some effort to consider the cost of fixing each of the items. This might be done intuitively or more formally.

4. Not well described.

Well, first I will mention again that some items are huge, and hence too vague to be useful.  So, part of describing them well is to make them smaller.  Some are more symptoms than causes. At the very least, the Team should be much more clear than you and I are about what they really mean. Often they were written quickly, and after you discuss ‘what did you really mean’, you realize that different words would say it better.

5. No RCA

The list does not make visible whether any Root Cause Analysis has been done. And of course that must be done.  And the biggest root cause must be fixed first.

6. Small enough?

This is important to say yet again a different way.  The items at the top at least should be small enough …. so that, the top one can be ‘fixed’ or mitigated in one Sprint, and people can feel the benefit in that sprint or the following sprint.  Usually.
Small and actionable. (Where did we hear this idea before?)

7. Take action?

Yes, Virginia, some people use a list NOT to take action.  The list is to enable them to forget about the top item, and NOT to take action on it.

So, hopefully it is obvious to you, me, your Team and company……the list must represent the tacit commitment to take aggressive action on the top SINGLE item. One at a time. And not to take any action on lower items (until the top one is fixed).  And that action always (in general at least) must include a commitment from people outside the Team as well (for money, for maybe some more people, for approval).  (Managers outside the Team won’t be involved in every impediment, but often enough they will have to be involved in some of them.)

Of course, the ‘single-piece-flow’ idea must be applied with common sense. We might have 3 impediments ‘in flight’ in this way: The SM is working on one, the Team is working on one, and Managers outside the Team are working on another.  Maybe this is ok, even good. It depends on common sense.

Impediments: from the Charleston CSM class in September

As you may know, I think it is key in Scrum to aggressively attack impediments.

I think each Team should have a (mostly) public impediment list. I think the SM should be attacking the top impediment each day.  I think this ‘kaizen’ should lead to improvements in velocity. I think every Team can get better. Always.

An impediment is anything (anything) that is slowing the Team down (or stopping the Team).

So, I asked the Charleston class to list their top impediments. It was a diverse crowd, representing many teams and several companies.  Here are the stickies that they showed each other:

• Deflection
• Skill set (lack of…)
• Identifying risks upfront (lack of…)
• Market (changes?)
• Interest (by the Team??)
• Eliminating scope creep (ok, I think now they would say ‘reducing’)
• Notification of deadlines
• Communication
• Hardware defective
• Environments not ready
• Task slippage (too much)
• Too many items open at once
• Not co-located
• No project rooms
• DBA backlog
• Too much talking – too little action
• Operational responsibilities
• No staffing in critical areas
• Lack of documentation
• Status updates
• No prioritization
• Wrong product selection
• Night job; people working day jobs fit it in when they can
• Wrong Tech skills
• Too aggressive a schedule
• Not enough people
• Customer won’t accept product
• Unclear scope
• Not knowing what the customer wants
• Unclear product owner
• Risks were not mitigated
• Changing end goal mid project (and it didn’t make enough sense)
• Mgmt issues
• Poor process
• Poor planning
• No project methodology
• Market value (effort had a ‘low’….)
• Not enough $ (for effort, per what makes business sense)
• Lack of control – outsourcing too much
• Morale
• Customer participation
• Structure
• Poor system availability and speed
• People constraints (eg, tech)
• Prioritization (lack of)
• Communication
• Synch of environments (lack of)
• Control of patches (lack of)
• Improve upper mgmt focus
• Unwilling to ask for help
• Unknown requirement
• Lack of Auto testing
• Undefined goals
• Improving the ‘owner’ (maybe the PO)
• No accountability
• Managing whirlwind
• Knowledgeable subject expert not available
• Lack of procedure
• Lack of Scrum [I liked this one - smile]
• Broken code
• No installation guide
• Incorrect estimates
• Indecisive “decision” makers
• Data crash
• Time spent on non-value added tasks
• A wide variety of different things.  I recommended to them that a Team track the top 20 impediments…that was probably enough.

I hope this list suggests to you or your team that maybe there are…. one or two more ‘opportunities for increased excellence’.

Scrum is Hard! (Scrum is Fun!)

The classic phrase from Sutherland and Schwaber is: Scrum is simple, but Scrum is hard.

And yet, with almost any decent Team, Scrum is fun. Unless the personal chemistry is dysfunctional.

So: If I don’t warn you  that Scrum is Hard, I am lying.

But if I don’t ‘warn’ you that Scrum will be fun, I am also lying.

OK, but why is Scrum hard?  Here are a few reasons. There are other ways to put it. And probably other reasons.

1. A person does not want to admit that he is imperfect.

Very common, right? And understandable. So, when you see and talk about imperfections, find some way not to let people get defensive.

2. People don’t like to admit that ‘we’ are imperfect.

From a certain point of view, this is silly. But it is also how humans are. We don’t like to ‘air our dirty linen’ we sometimes say.

So, this can be a hard thing to change. Again, a lot of it is how we talk about it. So, one cliche is that we phrase it as ‘opportunities for improvement’.  Sometimes very useful.

The key here: Scrum makes obvious lots of personal, team and organizational ‘problems’ or impediments. Makes them very obvious. And some people find this very very hard. And for us Scrum guys, getting those people not to make a mess can be very hard.

3. Change

Scrum is a change. And Scrum demands more changes.

And any change is often hard. You surely have experienced this many times personally.

Now, for a given person, some changes are felt as good. So, not everyone every day will find that changes of Scrum hard. But almost always someone, to some degree finds ‘the change’ hard.

Be sympathetic, to some degree. Bend them, but don’t break them. The next key statement is: Most people don’t resist change, they resist most being changed (by you).

4. Pressure or Stress

Our business of new product development is, by its nature, somewhat stressful.

New products MUST be built ‘quickly’ or ‘on time’.  Time, and quickly delivery are fundamental.

In the old waterfall way, the stress was ‘controlled’ a certain way.  Usually low for a long time, and then very high at the end.  Typically.  In Scrum, the stress is continual, all along the way.

Some people think Sprint means that stress is too HIGH every sprint. (That is not what the word was meant to convey.)

Really, with Scrum the Team is supposed to have ‘positive’ stress (you can google that is you don’t know the concept). And bad stress is supposed to be eliminated. But life is never quite that simple.

So, as you introduce Scrum, you must actively manage that they understand and execute on the ‘stress’ ideas in the proper way.  Much too often, ‘Scrum’ is used to just beat up on the Team continually.  (Or at least that’s how they hear it.)  In many ways, Scrum was designed to SAVE the Team from the Death March. So this ‘beating up’ is rather ironic.

But also ironic is the notion that the Team with Scrum should have zero stress. That time magically has no importance suddenly. This is of course not true. The full team is faced with the business problem of delivering something useful in a reasonable time.  They may or may not be able to do it in a specific situation (eg, company and product), but that fundamental pressure is unavoidable in our business.

5, People Types

A few Myers-Briggs types will find Scrum ‘uncomfortable’ or hard.

Those types may have been fairly satisfied (even if unproductive) in the ‘regularity’ and ‘control’ of waterfall. But Scrum exposes that our business actually has a fair amount of ‘chaos’.  Makes that much more obvious.  And a small percentage of people will find this too uncomfortable for their Type.

In the long term, this is a good thing.  People get reallocated to work that suits them better. But in the short term, it can be hard.

6. Skill Development Feels Endless

We know from any sport that even for ‘simple’ sports it takes years to develop into a true professional.

Scrum, in a similar way, exposes that development into a professional product development person (whether business or technology side) takes time.

And learning and playing the simple sport of Scrum takes years to master as well. Years. Years of hard practice. And this realization can be discomforting to some.

In truth, this was always true in a way. But waterfall kind of hid this truth to a fair degree. And one could feel ‘advanced’ much sooner. It was an illusion, but it seemed to be true then.

So, while this can seem hard, I am not convinced that it is really hard.
But you have seen already that almost all of what I have called ‘hard’ is mainly inside the heads of people. It is not ‘externally’ hard (mostly), but rather internally hard. Or subjectively hard.

7. Impediment Removal

Getting groups of people to remove impediments often feels very very hard.

And it is. All work in life is hard in some sense. And when we are inexpert at some things, they definitely feel very hard at first.

But with impediments, we tyoically also must get other people to ‘assist’ or go along in some way. And that can be very very hard.

Very useful, but very hard.

***

So, there are a few ‘hard’ things about Scrum.

I would be interested in your thoughts on why Scrum is hard.  I have not used the word ‘culture’ yet, and expect some of you to use it.