Monday, April 29, 2013
Wednesday, April 24, 2013
Scrum 201: Desire
Any sports coach knows that the Team must have desire.
In my classes I talk to the people about how much improvement they expect to make in 1 year. With 1 team. Often it is in the 20% range.
And I use Henry Ford’s famous quote: “Whether you think you can, or you can’t, you’re right.” So, I usually think that 100% improvement in 1 year is realistic for a specific team.
As a coach or a SM, if they are going to achieve hyperproductivity, the Team must want it. And, to some degree, they must believe it is possible.
So, the question becomes, how do you get them to have the desire?
This is not an easy thing. In fact, you cannot make them have desire. But, if there is something inside them, you can draw on that. You can blow on that ember of desire, and make it blaze.
Sometimes you can give them a challenge. To be the best team in your company, or your state. For example. Or to be much better than they are today, and prove that with metrics.
In Lean, we have the idea, expressed in a Lexus ad, of the ‘continuous pursuit of perfection.’ So, we establish a vision of perfection. (Usually we know this vision is not perfect, or later we see it is not really perfect. But it motivates us; it gives us something concrete that seems within our grasp.) So, we use the vision of perfection to build the desire.
Little’s Second Law: People are remarkably good at doing what they want to do.
So, if you can help them build their desire, in a concrete way, then they can start to make the changes that can drive tremendous improvement.
In my classes I talk to the people about how much improvement they expect to make in 1 year. With 1 team. Often it is in the 20% range.
And I use Henry Ford’s famous quote: “Whether you think you can, or you can’t, you’re right.” So, I usually think that 100% improvement in 1 year is realistic for a specific team.
As a coach or a SM, if they are going to achieve hyperproductivity, the Team must want it. And, to some degree, they must believe it is possible.
So, the question becomes, how do you get them to have the desire?
This is not an easy thing. In fact, you cannot make them have desire. But, if there is something inside them, you can draw on that. You can blow on that ember of desire, and make it blaze.
Sometimes you can give them a challenge. To be the best team in your company, or your state. For example. Or to be much better than they are today, and prove that with metrics.
In Lean, we have the idea, expressed in a Lexus ad, of the ‘continuous pursuit of perfection.’ So, we establish a vision of perfection. (Usually we know this vision is not perfect, or later we see it is not really perfect. But it motivates us; it gives us something concrete that seems within our grasp.) So, we use the vision of perfection to build the desire.
Little’s Second Law: People are remarkably good at doing what they want to do.
So, if you can help them build their desire, in a concrete way, then they can start to make the changes that can drive tremendous improvement.
Monday, April 22, 2013
Scrum 201: Team
We want all Scrum teams to become hyper-productive.
Why?
Well, so they can enjoy life and be satisfied. And feel like they accomplished something. So, in part, this requires that they reach hyperproductivity without working any extra hours.
Second, we assume that hyperproductivity also means much greater business value delivered. This of course will not always be the case. But it should be.
What level is considered hyperproductive? 5x-10x greater than average waterfall productivity. But we will settle for 5x-10x the teams initial baseline. Which is usually about what they are doing the 3rd sprint.
So all teams do this? No.
Can all teams do this? No. Although we expect all teams to try, and to make serious progress. Meaning: We expect each team to change its firms substantially.
***
Where do we start?
I think the first thing is: Is this Scrum team a real Team?
Far too often the answer is no.
They don't think of themselves as a Team. They don't work as a Team. And they don't measure Team productivity.
So, we often have to start by convincing them they are a Team.
***
Lots of the work is talk. Repeating basic ideas about Teams. Sometimes we must remove non-team players. We must add Team metrics. We must ask managers and customers to view them as a Team. And we must show them the small successes of good teamwork. And build on that.
It is not what they say, it is how they feel and act. First, how they feel.
Each team has its own team chemistry. This must be built.
Once they feel like a Team, then it is easier to coach the specific actions that a Team takes to support each and be successful as a Team.
Often, many people in the Scrum team have never been on a good sports team. Or on a good team at work. So, often, you don't have much tacit understanding to work with. Makes it harder.
And lots of the talk and work is on people outside the Team, who are inadvertently destroying the team, through all kinds of words and actions. You, as maybe the ScrumMaster, must change the immediate 'culture' to foster the Team.
Not easy. But a good place to start.
I suppose you can play Scrum without really being a Team, a real Team. But Scrum is meant to be played as a strong Team sport. This is when you will see the real productivity, the real value.
Why?
Well, so they can enjoy life and be satisfied. And feel like they accomplished something. So, in part, this requires that they reach hyperproductivity without working any extra hours.
Second, we assume that hyperproductivity also means much greater business value delivered. This of course will not always be the case. But it should be.
What level is considered hyperproductive? 5x-10x greater than average waterfall productivity. But we will settle for 5x-10x the teams initial baseline. Which is usually about what they are doing the 3rd sprint.
So all teams do this? No.
Can all teams do this? No. Although we expect all teams to try, and to make serious progress. Meaning: We expect each team to change its firms substantially.
***
Where do we start?
I think the first thing is: Is this Scrum team a real Team?
Far too often the answer is no.
They don't think of themselves as a Team. They don't work as a Team. And they don't measure Team productivity.
So, we often have to start by convincing them they are a Team.
***
Lots of the work is talk. Repeating basic ideas about Teams. Sometimes we must remove non-team players. We must add Team metrics. We must ask managers and customers to view them as a Team. And we must show them the small successes of good teamwork. And build on that.
It is not what they say, it is how they feel and act. First, how they feel.
Each team has its own team chemistry. This must be built.
Once they feel like a Team, then it is easier to coach the specific actions that a Team takes to support each and be successful as a Team.
Often, many people in the Scrum team have never been on a good sports team. Or on a good team at work. So, often, you don't have much tacit understanding to work with. Makes it harder.
And lots of the talk and work is on people outside the Team, who are inadvertently destroying the team, through all kinds of words and actions. You, as maybe the ScrumMaster, must change the immediate 'culture' to foster the Team.
Not easy. But a good place to start.
I suppose you can play Scrum without really being a Team, a real Team. But Scrum is meant to be played as a strong Team sport. This is when you will see the real productivity, the real value.
Why should the PO attend the Daily Scrum?
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?
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?
Saturday, April 13, 2013
Latest ‘Agile Release Planning’ ebooklet
I am pleased to announce that I have completed a full edit of the booklet.
It covers:
* Vision
* Product Backlog
* Business Value
* Effort
* Risks, Dependencies, Learning, MMFS, and other
* Ordering the Work
* Drawing the line
* “Communications Plan”
* The Fix-It Plan
* Other things
* Release Plan Refactoring
I use these ideas in the workshop that I now do for every course. So, I know the ideas work.
And I am feeling better about how they are expressed in this booklet.
But I would appreciate your comments. If you like it, and if you find things to be improved. Or if you have questions.
Please download the booklet here. It is about 33 pages.
It covers:
* Vision
* Product Backlog
* Business Value
* Effort
* Risks, Dependencies, Learning, MMFS, and other
* Ordering the Work
* Drawing the line
* “Communications Plan”
* The Fix-It Plan
* Other things
* Release Plan Refactoring
I use these ideas in the workshop that I now do for every course. So, I know the ideas work.
And I am feeling better about how they are expressed in this booklet.
But I would appreciate your comments. If you like it, and if you find things to be improved. Or if you have questions.
Please download the booklet here. It is about 33 pages.
Thursday, April 4, 2013
Leading Fearless Change Workshop – Apr 12th!
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
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.
Subscribe to:
Posts (Atom)
