They still want us to deliver too much in too little time!

Posted on May 18, 2013 by Joe Little

In a class, we had a large group of people from one company. And the company is doing or getting close to doing mostly Scrum.

But the managers and the Board have not been to a Scrum class.

In any case, ‘management’ is still asking the Teams to try to deliver too much in too little time. And say both the scope and the date are inflexible. Or at least, that is how it is heard.

What is the solution?

This is one of the hard problems of our work. There is no easy answer.

I think it boils down to this.

1. Customers want things quickly. And time itself has a value. For example, we must get to market with our new product before the competition.

2. On the other hand, as they said in Latin some 2,000 years ago, to predict is difficult, particularly of the future.

So, we (the Scrum Team) must make predictions, and try to make them real. AND, we must get everyone to understand all the changes that will happen. And all the variability in our ‘predictions’. When we think the next release will be done and how much will be in it.

These are not easy conversations. Usually. People mis-understand each other. Nonetheless, you must have the conversation.

Sometimes we say: we have a fixed time, a fixed scope and a fixed budget.

But always this is never completely true (in my experience). There is always some proposed small features or featurettes in the work that do not have to be done in the current release. This gives us an incentive to break down the features smaller, so we can identify small things to move to ‘later’.

Always there is a value to delivering fast. Usually, even before the current ‘date’ would be real good. Often very very good. (Which gives us yet more reason to reduce the number of small features in the release.)

And usually cost is NOT the main driver. There is (or should be) a huge ration between benefit and cost, so that being stingy about cost is silly. Especially when time is so important.

Lastly, in this too brief discussion, we must mention impediments. In Scrum, we want the Team to identify their biggest impediments. Things that, if we fixed them, we could double (again) our velocity. Not by magic, not by working harder, but by fixing impediments. In the wetware, in the random carbon units, in the automated testing, in the management culture, whatever. And often fixing impediments costs serious money. So, we need good judgment to spend wisely.

Finally, we need to use Agile Release Planning to start to identify a reasonable scope and date, initially. And, as things change (and everything will change at least some), we can revise and revise and revise it, and do the best we can to innovate in the time boxes we ultimately decide to give ourselves.

***

Managers must learn that if they pressure the Team (to deliver more in a given time), the Team usually hears two things: (a) cut quality, and (b) work high overtime. So, the Team and managers (or customers) must talk about this.

Almost always the managers do not want reduce quality or overtime (bad quality of life). What they want is ‘creativity’. Someone to cleverly see a simpler way to do things. How to remove an impediment. How to do fewer features. Something. Something unexpected that we might not have imagined without a challenge.

So, talk about this. Start to understand each other better. You need each other.

Why should the PO attend the Daily Scrum?

Posted on April 22, 2013 by Joe Little

Umm. Good question. We partly discussed this in an earlier post.

First, the Scrum Guide (2011) does not require that the PO attend the Daily Scrum. If you asked Jeff Sutherland is normal preference though, he would say it is probably better if the PO attended regularly.

OK, so why?

Well, first, the Team needs to know it is a Team. And the PO is part of the Team. Yes, he is different than the others. Much like a hockey goalie is different than the other skaters. But still part of the Team.

Often the key problem is: how to get the Business Value and the detailed requirements into the Team? It is not going perfectly yet. This is very often our biggest problem. And it is a very hard problem. There are several ‘laws’ of software development that speak to this problem.

And the PO is key to its solution.

So, we can say that the PO comes to the Daily Scrum to hear about progress (or lack thereof). We must be careful saying it that way. The PO has a kind of leadership role, it is true. But he is not the ‘boss’ that the Team ‘reports’ to. Or, at least, this is not the approach we want in Scrum.

We want the whole Team, including the PO to be in the same boat. Maybe the PO is like George Washington in that famous picture, but everyone is doing things to ‘manage’ the boat toward success. And they are all ‘in this together’.

The PO could come to ‘comment’ on Team progress. Again, careful. What do you mean by comment? So, if the Team has a question that the PO can answer, certainly in or just after the Daily Scrum, he will ‘comment’ or answer. But the idea is not that he gets to, in a top boss kind of way, stand above the Team and critique ‘the other guys’ (the Team). Again, in Scrum the PO is part of the Team. They win or lose together.

Maybe the PO tells the Team the tasks they will do? NO! Well, even that, in a different way, we must be careful how we say it. So, at what Scrum defines as the Task level, no the PO as such would never define and ‘force’ the tasks on the Team. In part it is because we assume the PO is normally a business person, and would not even know which tasks need doing. In part, we want the full Team to self-organize, and define their own tasks.

But, from a certain point of view, each PBI (product backlog item or story) represents work, and in a sense represents a ‘task’ for the Team. In that way, yes the PO is the person who does the final ordering of the Product Backlog. So, if the Team gets all the PBIs done that they ‘committed to’, then the PO can ‘give’ them the next PBI to work on in the Sprint.

The PO could come to determine if the Team needs help. Umm, again, careful how you say it. Yes, the PO could come to hear all the answers to the 3 questions. And, if something comes up where the PO could help, and that help can be provided quickly, then that could happen in the Daily Scrum. But often the discussion could be too long (bust the 15 minute time box), so the PO may only be able to identify that help is needed, and then provide the help after the Daily Scrum.

Now, who actually identifies that the help is needed? Well, it could be anyone, so the best way to say it is that the Team (including of course the PO) identifies that help is needed. From the PO. But specifically, it can be the PO who discovers first that help is needed on a given story.

One final reason for today (for why the PO attends the Daily Scrum). The PO should give his own answers to the 3 questions. Why? In part because he is a Team member (meaning, he is a member of the Scrum Team, not that he is doing ‘Team role’ work). By reporting to the Team, he and everyone starts to think of him more as a Team member. By reporting to the Team, over time everyone starts to see better how integral his work is to Team success. Yes, the PO’s work is different. Yes, his work is not as tied to the current Sprint as it is for the Implementers. But still, the whole Team needs to start to understand better how all the work is connected. (And if some is not usefully connected….well, maybe fix that.)

Could we imagine some ‘mis-understandings’ between business and technology at the beginning that could lead to some ‘awkward’ conversations? Yes! And this is good! Because now we as a Team will be addressing real, hard, difficult issues.

Could this conflict or tensions get out of hand? Yes. And the SM must manage the conflict. Making it more useful rather than ‘just conflict’.

***

OK, that’s what I think. What do you think?

Leading Fearless Change Workshop – Apr 12th!

Posted on April 4, 2013 by Joe Little

We recommend that all agile advocates and all ScrumMasters and Product Owners learn more about making change happen.

Change both in the large (changing the organization and adopting Scrum more or better) and in the small (changing to fix each impediment).

Mary Lynn Manns will be leading a 1-day workshop on change. In Charlotte. April 12th. I can hardly imagine a better way to learn about change, and how to do it better. Nor can I imagine a more essential skill set.

For more info: http://leanagiletraining.com/ChangeWorkshop-Charlotte-1.html

Hope you can join us!

Making Change Happen

Posted on April 4, 2013 by Joe Little

We must make people change, and we hope we know the direction. And we hope we know the specific changes.

In Scrum, we believe in big changes, in kaikaku. This happens when we first implement Scrum.

And we do smaller changes, also. Kaizen. We do them as impediment removal, for example.

Changes is easy in a way. They must change, it is clear to you. And your ideas are good.

But change is usually hard also. You feel like you have no power. They want to stay the same. They want to change a different way than you propose.

So, the first pattern is that you become an Evangelist. You want to get people to change. You start with ‘Ask for Help’. Get others involved.

You want to get some traction. Use ‘Just Do It’. And get started in a small way with your change. You want to explain the change to more people. Use ‘Personal Touch’ to make it the change specific to those you are working with.

See more patterns and ideas in Fearless Change. Or read here.

We cannot emphasize too much the importance of adding change upon change. Incremental change. Compounded change. This is the way to 5x-10x improvement.

Selling the benefits of Scrum

Posted on March 28, 2013 by Joe Little

Two other CSTs (scrum trainers) made some comments in a Google Group, which got me thinking. They reminded me of the following exercise I normally do in my Scrum classes.

Every class is different, but imagine a class that is mixed. Some people are new to Scrum, some have a few months experience, some have 9-24 months’ of experience.

And a recent experience makes me think I should modify the exercise. A bit. I have to say explicitly: “If change is going to happen, you must ‘sell’ Scrum. In some sense of the word sell.”

I show a slide listing all the benefits of scrum. ‘More Fun’ being one of the big benefits. In all, 6 or 7 benefits…

I then ask the class:
‘I need an estimate from you. Each of you. A single rough percentage. On average across all these factors.
If on Monday you start with one team, maybe your real team, and you get to work with them for 1 year, after all that you learn in this course and your hard work in applying it over 1 year, in removing impediments over a year — how much better will the Team be, after one year?
Using whatever weighting you want to use on these (pointing to the slide) 6 or 7 success factors.
So, George (first person) what is your number?’

And then I go around the room.

I get a wide range, sometimes. Usually a bunch of low numbers. 0% (rarely), 10%, 15%, 20%, 25%, 30%…sometimes 80%, 100%, 150%, 200% (rarely). As you might guess, almost always many more low numbers than high numbers.

Usually I end that segment with the Henry Ford quote: “Whether you think you can or you can’t, you’re right.”

***
In the past, I have been asked to ‘sell’ in several different contexts. And it has usually made me uncomfortable. So, why am I asking us all to sell now?

It is simple. Change makes people uncomfortable. Unless they see a real reason to change, they will not change. For example, the company culture will not change.

So, to get change to happen you must ‘sell’. In some sense of the word. And sell in a compelling way.

Now, I know from experience that the benefits of doing Scrum properly are tremendous. So, obviously, we want everyone to experience those benefits. But it starts, as John Kotter says, with a sense of urgency. And that means we, who understand Scrum, must be continually ‘selling’.

Now, selling to me does not mean: fakery, lying, exaggerating, forcing people to listen, etc, etc. By ‘selling’ I mean giving people a chance to have, or to have again, that sense of urgency for the change.

Leading Fearless Change

Posted on February 16, 2013 by Joe Little

What is the hardest thing about Scrum? (Maybe in life.)

Probably, it is that we must lead change.

Getting people to change is difficult. And in Scrum, for example, we are always trying to change people. Always continuous change. Always removing impediments.

But first, we have to change them to agree to a fully dedicated real Team. Then to fewer disruptions and only one product (product release). Then to doing all of Scrum. Then to really understanding self-organization. And on and on.

And then we start with the real hard impediments. Technical impediments. People issues. Managerial issues. Organizational issues.

Here are some resources to start with:

Leading Fearless Change by Mary Lynn Manns and Linda Rising. A good article by them. 3 pages.

This leading change course. With Mary Lynn Manns. In Charlotte in April.

By the way, this course will be about change. Any change. Not just change using Scrum or Agile. Any change.

Are there PMs in Scrum? No (but…)

Posted on February 15, 2013 by Joe Little

Scrum has only 3 roles: Product Owner, ScrumMaster and Implementer.

Who is responsible for ‘the project’? Well, that would be the whole Team.

What do we do with George, who was a Project Manager (PM)? Well, we have to talk to George, but maybe he would make a great ScrumMaster or a great Product Owner. Or something else.

The ones who liked removing impediments tend to make good SMs. The ones who liked managing the requirements often make good POs.

Next, several comments.

1. Some of the best agile people I know were Project Managers once. (I was one once.)

2. It is very common for the phrase ‘project manager’ to imply to some people that that person is ‘responsible’ for project success. This is not the case with agile. The whole Team is responsible. Together. Each person in a slightly different way. But, they win together or they lose together.

Now, often the PM knows well that only the Team has success. And sometimes the Team also understands this well. But as soon as we call someone ‘PM’, then a manager outside the Team starts talking as if this is George’s project to win or lose. And it starts to hurt things, hurt the chances for success. So, I suggest avoiding the term completely.

It is a nice idea that one person only could be responsible. It might seem to make another manager’s work easier. And maybe in some areas, it is true. But in our knowledge work, the whole Team must contribute. So, they win or lose as a Team.

3. Some PMs have years of experience trying to drive a ‘team’. They have their checklists. They have their command-and-control ways. I think this way of working is wrong, both as a way to treat people, and as a way to success. In any case, it is not what we do in Scrum. And, many PMs cannot break these habits. So, watch out for that.

4. Scrum is a simple framework. Scrum does not even try to give the Team, by itself, everything that the Team will need to succeed. They Team is expected to add things to Scrum, appropriate things for their work and their situation.

In this regards, many PMs have dealt with and studied many of these ‘possible things to add’. So, often George is good at suggesting these things. And other things can also be suggested by other ‘disciplines too.

5. Some companies still have PMOs after getting well started in Scrum. (PMO means Project Management Office, although I find each PMO group…usually several PM types grouped together…each PMO group can be run quite differently.) This may not be the best pattern, but it is not clear that this is a terrible pattern. Or at least, it might be a necessary pattern for a temporary period. In any case, some PMs can still work in a PMO kind of office, and this does not seem to be totally contrary to Scrum, or to clearly hurt Scrum teams. (But there are occasionally issues.)

6. Most of the duties of the old PM are divided in Scrum amongst the PO, the SM, and the Team.

7. Should we put George (a PM) on a Team that already has a PO and a SM? And give George mainly his old PM duties? (We could make a long list of those….) No, it seems very unlikely this will work well. George will be in too much unnecessary conflict with the PO and the SM. And, while there may be a few other duties, they are not enough to keep George busy full-time. Maybe, in a system that still also demands Teams to comply with waterfall reporting, maybe then there is enough work for George (the former PM) as a ‘pig’. Maybe. But we ought to get away from that as soon as possible.

8. Could Scrum Teams in large organizations need help doing ‘project management reporting’ and such? Yes. And often George has a great role to assist several teams in handling this work. In this case, we might say George is a ‘chicken’ to several teams. Still, we would hope that most of this role would go away with time.

Our Favorite Scrum Mistakes

Posted on February 14, 2013 by Joe Little

Ah, Valentine’s Day!

A day for a simpler love than “love your enemies”. But even this simpler love is quite complex. Well, as long as one is not besotted like Romeo below the balcony. Or Juliet above. When one is besotted (well, as I still am), then love is simple. But on other days, it is not. Or so I am told.

So, as a Valentine’s Day gift, we offer “Our Favorite Scrum Mistakes”.

This list was put together by a bunch of great Scrum trainers.

Some mistakes you will readily recognize. Some you might say “Oh, really? We might be doing that.” You will find some of them to be similar to each other. You may be surprised with how many there are. And I disagree with a few of them. (One suggests it is bad to estimate…well, it has problems, I think we must admit.)

Read, enjoy, learn. My and our gift to you.

The list is here.

Making Change Happen

Posted on January 28, 2013 by Joe Little

I was delighted the other day to have a brief conversation with Mary Lynn Manns, who is the co-author of Fearless Change, an excellent book on making change happen.

And I told her I had this idea: We can let change happen to us. (This is mostly to be passive in the face of bad change.) Or we can make change happen (the good change).

This dilemma was expressed by Shakespeare:

Whether ’tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles,
And by opposing end them…

We mean something slightly different. Not just to oppose the negative changes. But to advocate for positive change.

It takes guts.

I think, for many, it does not feel like guts. It feels like this: “I have to make this change happen, and I don’t care if I get nicked or scratched along the way.” The nicks and scratches are a ‘small price to pay’…is the way they feel.

Anyway, we are better people for making the good changes happen. It makes us better people.

To make it happen, we must be by turns aggressive and patient. By turns, emotional and thoughtful. By turns, with laughter and with all seriousness.

How do we make this happen?

Well, this change and we ourselves are the stuff that dreams are made on. There is no science here. But there are still many good ideas, and some of these ideas have been tried many times. And in the hands of the professional, they are usually or often successful.

Mary Lynn Manns and others call them patterns.

The first pattern is Evangelist. That would be you.

The Evangelist comes up with the good idea (somehow). (Hint: I think the first idea to implement is Scrum.) And then starts to…well, to evangelize. To get others to try the idea. To help the idea.

A couple of more patterns:

Ask For Help: The Evangelist asks others for help with the new idea. Maybe help defining it. Maybe help implementing it. Maybe help evangelizing. Also, have you noticed how wonderfully seductive it is to be asked for help. Who could possibly have more taste, brilliance, and acumen than the person who would ask me for help?

Innovator: Usually you have in your group some Innovators. Ask them especially for help. Get them on your side. In part, they are the ones most likely to have a positive attitude toward trying new things.

Just Say Thanks: Again, it is remarkable how a few bits of good manners can get people to go along with a new idea. Saying ‘thanks’ for the help can…well, help a lot.

Step by Step: Some of us want to make one big grand change. And be done with it. But the experience is that it is almost always best done, in some sense, step by step. One smaller change at a time. And they become added together into something quite big.

Small Successes: This is a similar idea, but somewhat different. As you have successes, even if small, be sure to celebrate them. The small celebrations will delight the change’s supporters, and confound its enemies. (Mark Twain said: When in doubt tell the truth. It will confound your enemies and astound your friends.)

***
In the book Fearless Change, Mary Lynn Manns and Linda Rising have gathered much more detail on these patterns. Indeed, on a total of 48 patterns.

You will find patterns you have done (but probably not done recently). You will find patterns you have heard of other people trying (but you have never used). And you will hear of completely new patterns.

The main problem is: use one pattern each day.

I think, if you do that, you will win.

Kanban Question

Posted on April 9, 2012 by Joe Little

A colleague asks: we are an out-sourcing firm and have a client who does not have a Product Backlog. In fact, they often can’t prepare enough items (stories) for even a full Sprint Backlog. (2 week Sprints). He is not used to Scrum or any other Agile approach. I am thinking of using Kanban with him. What do you think?

For some readers I guess we should define Kanban.

Kanban

Kanban is the Japanese word for signboard or card. The Lean guys in Japan stole the idea from Piggly-Wiggly in the US (a grocery store).

The idea is to use the cards to establish a pull system, to generate flow and to minimize WIP (work in process). It is very helpful if each card represents a small amount of work, and roughly an equal amount of work. We establish 3-7 ‘slots’ for each of 3-7 process steps. This establishes the capacity of the ‘system’, meaning in our case, a team.

Another key idea is to use visual management (seeing the cards on a board) to manage the flow. If flow stops, the issue is supposed to be addressed immediately.

This is a hugely over-simplified view of Kanban, especially as practiced by Toyota. Indeed, Toyota does many other things besides using the Kanban cards to enable pull and flow, and to minimize WIP. When we hear something that sounds like a team is using ‘only Kanban’, we are worried, because that seems to us likely to not be enough. Of course, almost always, they are doing other things as well, but often not calling them anything.

Summary of recommendations

Scrum comes with a basic Kanban approach ‘out of the box’ with the scrum board (with backlog, in process, and done columns). Once the team gets the basics of scrum down, we strongly recommend enhancing this board to make it a strong Kanban board.

In almost all real situations that we encounter, we want to maintain the basic strengths of scrum even while using Kanban on the board. These include release planning, sprint planning meeting, daily scrum, sprint review (demo), and retrospective. Very rarely we see weird situations where this just won’t work, but again that is very rare.

If the product owner is not ‘good enough’ or the connection to the business side is weak, we recommend addressing those impediments directly. We do not recommend hiding those impediments by doing only Kanban.

Discussion

Some assumptions…

1. The team is a regular size of about 7.

2. The client has a product of a reasonable size.

3. The product is important, although not always as important to the CEO (of the client, in this case) as we team members might like.

4. An MMFS (Minimum Marketable Feature Set) for this product typically takes at least four weeks of work (or more) by the team. (This means to me, more than 1 sprint.)

I find that situations that don’t fit within these assumptions are rare. But they do of course exist. My recommendations above and my comments below are based on these assumptions.

First issue: a weak product owner or a poor connection with the business is very common!

I am sorry, but this true. And scrum makes this issue visible, eg, in the demos.

These problems happen because Technology got divorced from ‘the business’. It happened because mutual disrespect has built up over the years. It happens because no one has ever been asked to be a product owner before. And your firm typically does not have a seriously experienced and successful product owner to train or mentor the freshly minted product owners.

Solve this problem! And it starts by making the pain visible. (Further discussion of this issue in a later blog post.)

Second issue: which is better to implement first, Scrum or Kanban?

This is maybe the toughest question, with not always an easy answer. My main answer is clear: Scrum. Because it sets so many basic disciplines in play.

This often requires a persuasive advocate for Scrum. Scrum can appear hard (change always feels hard), Scrum is typically blamed for revealing real problems, etc. And often the local advocate does not fully appreciate all the reasons that Scrum works.

Now, let’s assume you have a good advocate and you have made a persuasive case for Scrum. Maybe even gotten them to try it for 4 Sprints. But they aren’t buying it. This can happen in real life. Not saying that it should, but people are not always reasonable.

In that case, it is reasonable to say, ok, let’s try Kanban. And then later, as you identify issues that make some part of Scrum useful, you implement that part.

This is not to say that professional Kanban is easy to implement. But maybe in some cases easier.

Third issue: Retrospective.

Yogi Berra said: in theory there is no difference between theory and practice, but in practice there is.

In theory, we humans in a team should not need a Retrospective meeting, but in practice we do. And we need one about every Sprint length. (I like 2 week sprints, but I am not too bothered whatever length you want to say.)

So, if you implement only Kanban, then also implement a Retrospective every 2 weeks.

And the key here is to identify the top impediment and take action. Action in the form of identifying a specific plan to fix it. Or in identifying a business case to fix it, that a manager will approve (once you make the presentation of the case).

***

This is already a long blog post. Let me leave it here (although there is much more to say). Tell me your questions, and I will likely write and explain more.