Where to start?

Some of us have been doing lean-agile-scrum for awhile now. And we forget that others are just starting.

So, where does one start?

The first answer is that you start from where you are. One thing this means is that one starts with the impediments one has today. And you use Scrum to help tell you "what is the biggest impediment today?"

And there is always a biggest one today. And it is hard to predict what will be the biggest impediment tomorrow. So many different things can be slowing down the team. So many things can come up in an instant.

Is it useful to work on a less-important impediment? Well, yes, but not nearly as useful as working on the top impediment. THIS IS IMPORTANT. We should always be working on the top impediment (presuming that it can be improved, or that 'they' will allow us to fix it).

Why should you start Scrum? (This gets to the core issue of starting with right intention. As any good Buddhist would want us to.)

Well, some people want a work life that is more fun. Some want to get rid of a bad manager. (BTW, I think very very few managers are 'bad', although I do think lots of managers have been taught badly how to do their work.) Some want money. These are all good reasons.

But I think the best reasons are phrased a bit differently: To make my life better, to make our team's life better, to make our customers' lives better. You will note how that starts from the center and moves outward.

And it raises a fundamental question: what does it mean to make someone's life better? This is a difficult yet important question.

I think it is bigger than software. And I think that important words, like freedom, love and self-responsibility, are in there. And working as a team and at the same time fulfilling oneself as a person. Perhaps we may say a connectedness that that makes us more individuals rather than less. (I am in eastern europe (Romania) as I write.) We do not join a collective to lose our individuality, but rather, seemingly paradoxically, to become yet more our own individual selves within the team.

Within the dualisms we are used to thinking in, this sounds a paradox. But it is the truer organic reality.

Learning how to do this can be painful, but, as the song says, and as every mother knows, a deeper pleasure is on the other side. (See http://www.metrolyrics.com/save-room-lyrics-john-legend.html for the lyrics, if you are interested. Good song too.)

One team recently was going through this pain. One wondered how long it would take. One wondered "will they get to the other side?" Still, one has confidence that people learn from scraping their knees.

Fearless Change

Mary Lynn Manns is visiting Agile-Carolinas in Charlotte next week.

As many of you will know, Dr. Manns is the co-author of Fearless Change, along with Linda Rising. This is a great book about getting people to adopt a new idea (eg, lean-agile-scrum).

So, I wanted to take this opportunity, in thanks, to praise the book and to write about one pattern in the book. In this case: "Fear Less".

This pattern is first about how we fear the skeptic. And the first advice is, as other wise teachers have taught us, love your enemies.

This is in part saying "accept that you are an imperfect human". Meaning, again in part, that while lean-agile-scrum may be very very good, my own interpretation of that might be less than perfect for a specific usage. And a good skeptic can keep bad things from happening.

We must also understand that many people, quite normally, resist change unless they can clearly see that it will help them.

It is also, I think, a recognition that each person is free. Our opposite is not required to agree that our new, brilliant idea is good for them. As we are, they too remain free. Their freedom is a very good thing.

OK. So, what to do about it?

The advice, in my words: "If you have lemons, make lemonade." In the books words: "Turn resistance to the new idea to your advantage." And then, maybe more specifically: "Ask for help from resisters."

We can't go any faster Captain!

For many Scrum teams, they reach the point of attacking all the obvious impediments. And they are fixed. And they say, in effect, "we can't make it go any faster Captain!" As that actor with the Scottish accent would say in the original Star Trek.

What's wrong with this picture? (for the Team)

Well, many things. I will name a few below.

1. Not so obvious impediments.

What I often find is that lots and lots of not-so-obvious impediments still need to be fixed. Things that they overlooked. Or someone didn't see. Often they are the "elephant in the room" kind of impediment. One example has been a command&control ScrumMaster. And there are many others.

Some people assume all impediments must be technical.
Some think all are to do with Continuous Integration.
Some think all are facilitation issues.
Some think if we take care of expresso and baby-sitting we are done.
Some think that disruptions by managers are the only impediments.
Some think think that the initial setup of the infrastructure for the Team is the only impediment.

But, the biggest impediment can be any of these, and more. Technical debt, for example. Or not building new technical debt.

2. Impediments that seem immovable.

I am not in favor of attacking impediments that simply can't be changed.

But, what I usually find is that teams assume that 3 or 5 impediments can't be fixed or improved, and they give up trying to work on them or even asking anyone else to work on them.

And, usually a you need something to "juice" the team to get them to even think of working on these kinds of impediments. Often, the impediments are actually easy to move, eg, after talking to the right manager. Not always, but often.

3. "We're perfect now."

There is this deep human desire to be perfect, to be done getting better. To feel we are the best, and can't possibly improve.

But the wise and even 6 year old know, no one is perfect.

So, we must ask the Team to always say, even though we won the Super Bowl last Sprint, we have to get better….so, what is the biggest impediment now?

The relentless pursuit of perfection. But always a perfection that eludes us.

The Lean people say that when we approach our earlier definition of perfection, we become wise enough to define a new, tougher definition of perfection. Which we can then pursue.

* * *
There are many more issues around this, but these three are a start.

Release Planning & the Early Warning System

Building complex innovative products is, of course, hard.

So, in that context, what is the purpose of Release Planning in Scrum/Agile?

We will not provide a complete explanation here, but we will give a few key ideas.

1. A consensus view of the 'same' elephant. We want all the team members to see the whole product and to start to see the same whole product. We think this is typically the most valuable thing.

2. Think first, but not think too much. This is a neat trick -- getting some people to think enough before they start, and also helping others not get stuck in 'analysis paralysis'.

I find that many people want to know 'perfectly' a certain set of information before they start. Meaning: They want to wait and study too long. I find this seeking for 'perfection' is mis-guided. It typically does not include enough consideration of what it costs us not to know 'X' before we start. (If the cost could be real high, then slowing down to learn 'X' makes more sense).

I think each team should have a good fight about how much to 'study' before starting to Sprint.

3. Establishing a project plan, with a date estimate for the first release and a cost estimate. In most organizations, something like this is usually needed. My experience is that, aside from the discussions about risks and impediments, this is usually the least valuable output. But it establishes a starting point for improvement. So, for several reasons, it is necessary.

4. Establishing an Early Warning System. I was just working with a large client who has a big, multi-team and multi-year effort. Some on the team think they will get done 'early'. And some think they will be 'late' as usual (this is said from my own personal experience that most waterfall projects are late...and this organization is just transitioning from waterfall).

In this case particularly, the group (everyone in the group) needs an early warning system that can tell them whether they are likely to hit the date or not. (A date and a high-level scope has been defined, but the detailed requirements are undefined.) For example, the earlier the group knows there is a problem, the earlier it can take counter-measures to address the problem.

So, the Release Planning sets up the ideas (velocity, story points to be completed, Business Value of the features, etc) that go into the Release Plan. And the Release Plan, with its implied 'ideal velocity', can become the Early Warning System.

Since, in this case, the Chief Product Owner is leading this effort, this gives him great incentive to get the whole group to do professional Release Planning now. So that, for example, refactoring of the Release Plan will take less effort later. So, the CPO needs to explain and explain again why the whole group wants a good Release Plan sooner rather than later. (Only if they want to do it, will they do it well.) Not an easy job. Do-able, but not easy. Especially for beginning Product Owners.