This topic is being discussed here. And many places. I think I will be discussing it with a senior executive in Canada on Monday. So, very pertinent for me. And likely many others.
A lot of smart people in that discussion (I know some of them personally). A number of great ideas were mentioned by these people in that discussion, and I wanted to summarize them and react to them.
1. My advice might differ greatly if I understood Mark's specific situation better -- really, if I understood it at all. So, my comments in the prior post are based on what I find is the typical situation.
2. As discussed here earlier, asking people to do something (Scrum) that they really do not (yet) feel an interest in doing, is not a recipe for success. So, typically, one must influence them to want to do Scrum. Usually a fair amount of work itself.
3. To re-phrase Steven "Doc" List's main point (I think fairly): In Scrum terms, it is always in my experience useful to do a decent Release Planning with the whole team. (We do this in the Workshop, although not always with enough time to do it 'well enough for now'. So, it may need some further work before Sprinting starts.) To me, the biggest advantage in this is that it gets the team all on what page: what is this effort all about.
In Scrum, we refactor the Release Plan every Sprint (to some degree).
4. As Eric L said: Bringing in an external person (or people) is valuable. This is one of the patterns in Fearless Change by Manns and Rising. (In fact, get that book. And do all the patterns in it. Repeatedly.) The external person can do training, coaching, a speech...many different things.
5. I know people at Rally Dev and at Thoughtworks. All the people I know are good (although not all equal). Each brings 'their thing' to the table.
6. Jay C. mentions being prescriptive. There is a paper that Jeff Sutherland contributed to called Shock Therapy, which describes an approach to this. While it is risky in some ways, I think it can be very successful to be prescriptive about what Scrum is (for a period of time). Not prescriptive about how they do their 'real work', but about Scrum.
7. Jay C. also mentions being value centered, about which I strongly agree. I start this in Release Planning. My fuller approach I call Business Value Engineering, where I steal ideas from Scrum and Lean to incrementally improve the approach to delivering higher business value. As one very small example, from the beginning I advocate Priority Poker, which is much like Planning Poker, only done with the top 5 guys and about Business Value.
8. Bob M. mentions the idea of doing agile-scrum outside of just the software building part of the overall business process. I concur. It often would actually be more valuable elsewhere. The question is how and when. Sometimes useful to demonstrate that agile-scrum is successful here (sw dev), and then expand it out.
9. Matthew H. mentions an analysis of the organization: what's working and what's not. I would definitely do one initially. (Maybe an hour or two.) I would say the key is: prioritize your battles (if you like the war metaphor). Scrum by the way can be said mainly to be a way of seeing your problems more clearly --- then it takes the guts to actually act on that new information.
10. Matthew H. talks about understanding the leadership team. This is often a key part of the organization, and analyzing and getting an action plan around leveraging their strengths and mitigating their weaknesses can be very useful. This has to be done in a timebox. Everything does not depend on these people. The most important person is really the 'agile advocate' (typically, that is you). Again, see Fearless Change by Manns and Rising.
11. Daniel G. gives a link to a very nice list of the basics of Scrum. This is a useful thing to use, particularly with more than one team, so there starts to be a good discussion around "why aren't we all doing the basics of Scrum?" Other uses too, of course.
12. Robyn D. gives some great advice about how to set up the first team at the very beginning. Get a good set of work, do some release planning, get them to collaborate, etc. Being realistic about the 'quality' of the first few sprints is very good advice. My advice (prior post) took a somewhat longer term time frame.
13. Robyn D. mentions XP practices (TDD, CI). Concur. I would implement the fixes to the biggest impediments first. Usually the value in doing these XP practices should be either: faster velocity (at sustainable pace) or reduced technical debt, or both. But, sometimes these XP practices are a great hammer, but we are not quite ready to get to the nails yet. If see what I am suggesting. Anything can be the biggest impediment; fix the biggest one first.
14. Matthew H. mentions 'silver bullets and ideology'. Umm. This is hard to explain well. On the one hand, "it depends on common sense" is always useful advice. One the other hand, common-sense is not that common. Then we observe: There is a lot of Scrum-But out there. And usually we find people acquiescing to it, with no good long-term reason (often the initial short-term compromise was quite sensible).
We do find people in agile whom I would characterize as impractical or too impatient about the initial implementation. They want a team to do all of Scrum and all of XP on day one. For example. So, being impractical in this way about existing impediments on day one seems to me wrong.
We do find people in agile who say or imply 'do Scrum [or XP or whatever] and all will be well'. Let's be clear. Scrum cannot guarantee success. Example: If you have a great team at American football, and you ask them to play soccer, they will fail at that against a world cup level soccer team. But (back to our regular situation) if the team is not sufficiently competent for the work they have been given, Scrum will enable you to see that impending failure sooner.
On the other hand, as I suggested earlier, typically we think people should be very aggressive about removing impediments (within the rule that 'a dead ScrumMaster is a useless ScrumMaster'). And we also find in very many scrum implementations a lack of aggressiveness about removing the impediments (eg, the Scrum-Buts that we had to start with). So, we need some 'fire in the belly' about eventually getting to 'better Scrum' (and better lean-agile-scrum more broadly).
Our overly simplistic motto for the right attitude is from lean: 'The relentless pursuit of perfection.' Meaning: We accept that we are imperfect. We define a 'better state' and we relentless pursue that until we are close enough to see that we can define a yet higher state of 'perfection'. In other words, we relentless pursue getting better, without the illusion that we will ever become truly perfect.
Wow, that balance between being practical and being idealistic is hard to explain. I hope you could get the idea-action that I meant.
I hope you found one or two of the ideas here actionable in the short-term. (It is important to think and then act, in a tight cycle.)
Comments or further comments welcome.
A lot of smart people in that discussion (I know some of them personally). A number of great ideas were mentioned by these people in that discussion, and I wanted to summarize them and react to them.
1. My advice might differ greatly if I understood Mark's specific situation better -- really, if I understood it at all. So, my comments in the prior post are based on what I find is the typical situation.
2. As discussed here earlier, asking people to do something (Scrum) that they really do not (yet) feel an interest in doing, is not a recipe for success. So, typically, one must influence them to want to do Scrum. Usually a fair amount of work itself.
3. To re-phrase Steven "Doc" List's main point (I think fairly): In Scrum terms, it is always in my experience useful to do a decent Release Planning with the whole team. (We do this in the Workshop, although not always with enough time to do it 'well enough for now'. So, it may need some further work before Sprinting starts.) To me, the biggest advantage in this is that it gets the team all on what page: what is this effort all about.
In Scrum, we refactor the Release Plan every Sprint (to some degree).
4. As Eric L said: Bringing in an external person (or people) is valuable. This is one of the patterns in Fearless Change by Manns and Rising. (In fact, get that book. And do all the patterns in it. Repeatedly.) The external person can do training, coaching, a speech...many different things.
5. I know people at Rally Dev and at Thoughtworks. All the people I know are good (although not all equal). Each brings 'their thing' to the table.
6. Jay C. mentions being prescriptive. There is a paper that Jeff Sutherland contributed to called Shock Therapy, which describes an approach to this. While it is risky in some ways, I think it can be very successful to be prescriptive about what Scrum is (for a period of time). Not prescriptive about how they do their 'real work', but about Scrum.
7. Jay C. also mentions being value centered, about which I strongly agree. I start this in Release Planning. My fuller approach I call Business Value Engineering, where I steal ideas from Scrum and Lean to incrementally improve the approach to delivering higher business value. As one very small example, from the beginning I advocate Priority Poker, which is much like Planning Poker, only done with the top 5 guys and about Business Value.
8. Bob M. mentions the idea of doing agile-scrum outside of just the software building part of the overall business process. I concur. It often would actually be more valuable elsewhere. The question is how and when. Sometimes useful to demonstrate that agile-scrum is successful here (sw dev), and then expand it out.
9. Matthew H. mentions an analysis of the organization: what's working and what's not. I would definitely do one initially. (Maybe an hour or two.) I would say the key is: prioritize your battles (if you like the war metaphor). Scrum by the way can be said mainly to be a way of seeing your problems more clearly --- then it takes the guts to actually act on that new information.
10. Matthew H. talks about understanding the leadership team. This is often a key part of the organization, and analyzing and getting an action plan around leveraging their strengths and mitigating their weaknesses can be very useful. This has to be done in a timebox. Everything does not depend on these people. The most important person is really the 'agile advocate' (typically, that is you). Again, see Fearless Change by Manns and Rising.
11. Daniel G. gives a link to a very nice list of the basics of Scrum. This is a useful thing to use, particularly with more than one team, so there starts to be a good discussion around "why aren't we all doing the basics of Scrum?" Other uses too, of course.
12. Robyn D. gives some great advice about how to set up the first team at the very beginning. Get a good set of work, do some release planning, get them to collaborate, etc. Being realistic about the 'quality' of the first few sprints is very good advice. My advice (prior post) took a somewhat longer term time frame.
13. Robyn D. mentions XP practices (TDD, CI). Concur. I would implement the fixes to the biggest impediments first. Usually the value in doing these XP practices should be either: faster velocity (at sustainable pace) or reduced technical debt, or both. But, sometimes these XP practices are a great hammer, but we are not quite ready to get to the nails yet. If see what I am suggesting. Anything can be the biggest impediment; fix the biggest one first.
14. Matthew H. mentions 'silver bullets and ideology'. Umm. This is hard to explain well. On the one hand, "it depends on common sense" is always useful advice. One the other hand, common-sense is not that common. Then we observe: There is a lot of Scrum-But out there. And usually we find people acquiescing to it, with no good long-term reason (often the initial short-term compromise was quite sensible).
We do find people in agile whom I would characterize as impractical or too impatient about the initial implementation. They want a team to do all of Scrum and all of XP on day one. For example. So, being impractical in this way about existing impediments on day one seems to me wrong.
We do find people in agile who say or imply 'do Scrum [or XP or whatever] and all will be well'. Let's be clear. Scrum cannot guarantee success. Example: If you have a great team at American football, and you ask them to play soccer, they will fail at that against a world cup level soccer team. But (back to our regular situation) if the team is not sufficiently competent for the work they have been given, Scrum will enable you to see that impending failure sooner.
On the other hand, as I suggested earlier, typically we think people should be very aggressive about removing impediments (within the rule that 'a dead ScrumMaster is a useless ScrumMaster'). And we also find in very many scrum implementations a lack of aggressiveness about removing the impediments (eg, the Scrum-Buts that we had to start with). So, we need some 'fire in the belly' about eventually getting to 'better Scrum' (and better lean-agile-scrum more broadly).
Our overly simplistic motto for the right attitude is from lean: 'The relentless pursuit of perfection.' Meaning: We accept that we are imperfect. We define a 'better state' and we relentless pursue that until we are close enough to see that we can define a yet higher state of 'perfection'. In other words, we relentless pursue getting better, without the illusion that we will ever become truly perfect.
Wow, that balance between being practical and being idealistic is hard to explain. I hope you could get the idea-action that I meant.
I hope you found one or two of the ideas here actionable in the short-term. (It is important to think and then act, in a tight cycle.)
Comments or further comments welcome.
No comments:
Post a Comment