-
Team
-
Product Backlog
-
Done, Done
Showing posts with label scaling. Show all posts
Showing posts with label scaling. Show all posts
Saturday, May 21, 2016
The Team sucks, the Backlog sucks, the Done Done sucks! I know! Let's scale that!
I just led a discussion with Agile Charleston on that topic.
The idea for this topic comes from a talk by Mike Cottmeyer at the Scrum Gathering in Orlando.
I agreed with Mike that these 3 are 3 of the most common problems with Teams. And they are fundamental. (One might argue that X is even more important. Not going to go there....).
An additional conclusion: I think these (or fixing these) are prerequisites to scaling. More on this below.
So, very quickly, when are the team, the backlog and the done-done good enough?
Here are my answers expressed much too quickly.
Wednesday, December 16, 2015
Scrum at Scale - 4 parts
Jeff Sutherland has recently done a great job in describing his ideas on scaling.
Here are a couple of things I think are key:
1. Scale down. That is, it is complex to get lots of people involved in one problem or effort. Simplify.
2. Use patterns.
3. There are alternatives. While there are some common patterns, and they can work, do not assume every pattern will fit your situation. Be judicious and experimental. Expect experiments may not work out well (for a variety of reasons, including ineffective execution).
Here are the modules. They include video and slides. See both.
https://www.scruminc.com/scrum-scale-part-1/
https://www.scruminc.com/scrum-at-scale-part-2/
Saturday, August 23, 2014
Scaling Workshop - New thoughts
David Muldoon and I just had a new Scaling workshop in Montreal. Two days talking about scaling, and solving problems.
One quick observation
Scaling is ugly. That is, scaling is always a compromise.
We talked about the ideal state; what would we ideally want things to be like. One way of expressing part of that: We want to have 5 teams (of 7 people each) work together in such a way that 'everyone knows everything', and we are completely in sync from top to bottom. And we want this communication to happen at zero cost and in zero time. We want this because we want to work fast and effectively and with high quality. ...Of course, this ideal state could never exist, but at least we see the trade-offs more clearly.
First, we hope we get that in a single Scrum team, and if we play Scrum well, I think we can. It is hard, but we can, in a pretty reasonable way. Yes, not at zero cost, but at a very reasonable cost.
But to get this with 36 people (including the Chief Product Owner) is hard. There is an additional communication overhead, and we almost always start leaving people out of conversations. In part, because it is so messy to have a conversation (or meeting) with more than 7 people.
What is the overhead to scale? Well, honestly I have not looked at the data in a while, and I think we need better data, but I think the cost is quite high. 10, 20, maybe 30% of productivity is lost. Very likely more. In any case, we have to be honest....with scaling more of the raw energy of the people is dissipated 'into thin air' as we might say. We have to accept that, but we also want, within reason and in the context of other values too, to minimize that dissipation of energy.
A second thought.
Each scaling situation is different. I was again struck by this. Yes, some of the problems are similar from one situation to the next, but the solutions you need to bring are different, at least to some degree.
For example, in one situation, a company is trying to rebuild a large legacy core system (a huge payroll system). The original system took, they think, 5 years to build with many people. The problem: How to take 5 teams and rebuild it in 2 years, and deliver it incrementally over those two years (in part, to mitigate the risk of a big bang delivery).
In another situation, the problem was different. Here we had a growing company that is innovating, and changing. How do we get evenness of flow so that the 3 'departments' (or areas)....Inception, Build, Transition each have an even amount of work to do. In such a way that the highest Business Value stuff is delivered quickly to customers, no matter how big each release might be. By inception, they meant identifying good idea sufficiently to move to Build. Build meant, in simple terms, coding and testing and getting to a minimum viable product that was done, done, done. Transition meant taking a (newly built) product and delivering and installing it at many (say 35) customers.
Describing how the solutions for these two situations were different is too much to address today. But the first thing is to recognize how different the problems are.
A third thought.
Implementation is key. We must implement scaling iteratively and incrementally. This was clear to everyone, and clear in all situations. The full meaning varied, eg, because of the different political situations, from situation to situation, but that we should, indeed must, implement scaling iteratively and incrementally was clear.
Why? One was the cost and the related approval for each part. For example, in one situation, it became clear that each of the 5 teams needs a Product Owner and we need a CPO 9chief product owner). But, they only have one PO now (for 3 teams). There is no 'open requisition' for 5 new POs. So, the feasible way to implement this was: add one PO now. A bit later, get approval for another PO. And so on.
Another reason. Whenever you add something to scaling you must get them, and usually to some degree 'all of them', to agree to the change, to change, and then to learn how to use the change effectively. It is easier for 'all of them' to agree to the changes iteratively and incrementally. The changes are easier to implement iteratively and incrementally. And you can manage the process of becoming professional in the use of each change better if each change is fairly small. (There are other factors, depending on the situation, but one of the bigger risks is with a 'big bang' implementation of scaling changes.
A fourth thought.
I continue to learn about scaling. I think we all do.
Slightly related to this: We have or should have a strong bias toward KISS. Keep it stupid simple. Keep it maybe somewhat simpler than it 'needs to be'. Why? Because we have so much complexity already that we are almost stopped in our tracks, and the more complexity we add to the scaling part, that complexity makes things harder by itself. What do I mean by harder? Communication is not as good. We get confused. Everyone in the scaled group does not understand how we are scaling well enough. Hence, the do not use the official scaling effectively, and resort to doing nothing or to doing it in a personal or informal way (which often can run counter to what is happening in official channels).
But back to the learning. Let me give two examples. My colleague Dave has a bias toward 1 week sprints, and I have a bias toward 2 week Sprints. Maybe better to say: I think getting most teams to do 1 week sprints well is harder than getting them to do 2 week sprints. And that 3 or 4 week sprints are only rarely good ideas (ie, useful only in a few situations).
So, that is a small difference between us, and we both knew about it. I think it arises mainly from different experiences (different specific situations), and that we fundamentally agree on the principles (eg, the value of fast feedback, that one must save one's political capital for the most important changes, etc).
But, even though Dave and I have been talking about scaling frequently for years now, we discovered a new difference in this workshop.
Dave likes to talk about 'grooming' as one meeting, and a big grooming working of many hours, maybe even a whole day in a Sprint. He has good reasons for this preference. I like to talk about those activities as 'the red zone' (versus the 'black zone' of doing the 'real work' of ... in very simple terms, coding and testing). In the red zone we do grooming and we do longer term release plan refactoring. I like to call all of the red zone 'release plan refactoring and make it clear how connected the 'grooming before the next sprint' and the 'pre-planning' (as people often call it), it directly connected to the black zone, and to the longer term release plan refactoring. And, for reasons I won't explain fully hear, I therefore do not define the contents of the red zone has strongly in other ways, but do usually propose at least two shorter meetings over a 2 week sprint, one hour each. So, in simple terms, more meetings but overall less time 'all together'... or at least less time where we 'require' that we be together.
Dave and I had talked about these different views some. But what became clear is how, for one situation, we were suggesting notably different options for the people to consider in scaling. And they each had value. They each made a different compromise about the different things we might try to optimize. This was very interesting.
One key idea we discussed is the typical pattern of 'group-individual team-group'. This is of course a typical pattern one find all over the place with scaling. We need to discuss X at the group level first, then we need to discuss it at the team level to get into the details, then we need to bring back the learnings at the team level, and discuss again at the group level. Perhaps you follow the idea enough so that, when I use the Yogi Berra quote ('Little things are big.') you see what I mean and why. (If not, tell me, and I will explain more.) Sometimes the concept is expressed succinctly in the aphorism (two versions): 'God is in the details" or "the devil is in the details."
Concluding thought
I was very pleased with this 2 day workshop. The people wanted us to explain scaling, and all the different ideas 'out there' about it. While of course there are a huge number of ideas out there, and it would take days and days to cover them 'fully', we gave them a decent summary in a time box.
And we talked about specific situations, and specific small patterns that might address those specific problems. And we talked about the implementation issues for implementing those patterns (eg, the politics of getting approval or buy-in). And to enough detail that I felt they had 'enough' to go do it. These became not just abstract suggestions, but rather palpable, do-able action items.
So, I felt (and I think the attendees felt) that it was a very successful workshop. It was fun for me to work with them.
Friday, July 11, 2014
Scaling Whitepaper
Monday, May 26, 2014
Saturday, February 8, 2014
Scaling Workshop
I am really excited about the Scaling Workshop Dave Muldoon and I just led in Montreal.
Dave had mentioned this before, but it struck me how each person’s problems are different. And, even if they are somewhat similar, they need to be prioritized differently.
We had some discussion of ScrumPLOP.org. And of LeSS (Large Scale Scrum). But mainly we did a workshop. We took specific problems in implementing Scrum across the broader organization, and worked through the problems. They were hard problems. We did not have any magical answers. But I felt confident and happy that the people who had those problems now felt better able to tackle them in the context of lean-agile-scrum.
We used SmartSheets and diagrammed. Current Situation. Future situation. And this was useful. But mainly useful as a way to clarify and organize a good conversation. To organize the learning.
Dave had mentioned this before, but it struck me how each person’s problems are different. And, even if they are somewhat similar, they need to be prioritized differently.
We had some discussion of ScrumPLOP.org. And of LeSS (Large Scale Scrum). But mainly we did a workshop. We took specific problems in implementing Scrum across the broader organization, and worked through the problems. They were hard problems. We did not have any magical answers. But I felt confident and happy that the people who had those problems now felt better able to tackle them in the context of lean-agile-scrum.
We used SmartSheets and diagrammed. Current Situation. Future situation. And this was useful. But mainly useful as a way to clarify and organize a good conversation. To organize the learning.
Sunday, October 20, 2013
SAFe, LeSS, DAD, and ScrumPLOP
First, I wanted to say that I feel each ‘large scale agile’ situation is different. The key problems are different. And therefore, the solution(s) should be different.
And I like the idea of patterns. This is the patterns idea: “Here are some things (patterns) that others have found useful, and maybe I can steal from them, and maybe even these things (patterns) will be useful for me.”
One of the nice things about patterns is that they start modestly. They do not boast “oh, I am sure you MUST have this tool.” They simply suggest: “Oh, you might find this tool useful.”
Here are some places where you can steal (in a nice way). Because I like patterns, perhaps I like ScrumPLOP best.
SAFe. Scaled Agile Framework, associated with Dean Leffingwell. See here. Notice the lengthy glossary. And you will notice a whole bunch of Scrum words that have been redefined. Or slightly redefined. There is quite a lot there.
LeSS. Large Scale Scrum. See Scaling Lean and Agile Development by Craig Larman and Bas Vodde. I really like that book. Here is some info on the web. You will notice both similarities and important differences with what “Scaled Agile Framework” is suggesting.
DAD. Disciplined Agile Delivery, associated with Scott Ambler. In some sense Scott has been talking about these issues for years. But now he and others have this site. Again, some similarities and some important differences as compared to SAFe and LeSS.
ScrumPLOP. The Scrum Pattern Language group. The two key people behind this (in my opinion) are Jeff Sutherland and Jim Coplien. I have already said I like the patterns idea. And I have worked with Jeff Sutherland fairly extensively, and I have only the highest regard for him. This repository covers many things, and is not just addressed to the issue of ‘scaling’, however one might define scaling. But, it has a number of ‘scaling’ patterns. Some of the scaling patterns include: Chief Product Owner, Product Owner Group, Scrum of Scrums, Impediment Removal Team, Organizational Sprint Pulse, etc. You will notice that some of the groups mentioned above use these same patterns, although they may call them something different.
I hope these resources are useful to you.
Again, I wish to remind you and caution you: Do not forget the individual team(s).
If you have great scaling and bad teams, you have almost nothing. If you have great teams, and fairly weak scaling, you still have something quite powerful. Don’t lose focus on what is important.
And I like the idea of patterns. This is the patterns idea: “Here are some things (patterns) that others have found useful, and maybe I can steal from them, and maybe even these things (patterns) will be useful for me.”
One of the nice things about patterns is that they start modestly. They do not boast “oh, I am sure you MUST have this tool.” They simply suggest: “Oh, you might find this tool useful.”
Here are some places where you can steal (in a nice way). Because I like patterns, perhaps I like ScrumPLOP best.
SAFe. Scaled Agile Framework, associated with Dean Leffingwell. See here. Notice the lengthy glossary. And you will notice a whole bunch of Scrum words that have been redefined. Or slightly redefined. There is quite a lot there.
LeSS. Large Scale Scrum. See Scaling Lean and Agile Development by Craig Larman and Bas Vodde. I really like that book. Here is some info on the web. You will notice both similarities and important differences with what “Scaled Agile Framework” is suggesting.
DAD. Disciplined Agile Delivery, associated with Scott Ambler. In some sense Scott has been talking about these issues for years. But now he and others have this site. Again, some similarities and some important differences as compared to SAFe and LeSS.
ScrumPLOP. The Scrum Pattern Language group. The two key people behind this (in my opinion) are Jeff Sutherland and Jim Coplien. I have already said I like the patterns idea. And I have worked with Jeff Sutherland fairly extensively, and I have only the highest regard for him. This repository covers many things, and is not just addressed to the issue of ‘scaling’, however one might define scaling. But, it has a number of ‘scaling’ patterns. Some of the scaling patterns include: Chief Product Owner, Product Owner Group, Scrum of Scrums, Impediment Removal Team, Organizational Sprint Pulse, etc. You will notice that some of the groups mentioned above use these same patterns, although they may call them something different.
I hope these resources are useful to you.
Again, I wish to remind you and caution you: Do not forget the individual team(s).
If you have great scaling and bad teams, you have almost nothing. If you have great teams, and fairly weak scaling, you still have something quite powerful. Don’t lose focus on what is important.
Saturday, October 12, 2013
Basic Agile ‘scaling’ terms
Below are several key terms used often when we discuss ‘Agile Scaling.’ And we want to discuss them.
Why?
Our experience is that when the community talks about these issues, they use these words in a very loose way. The problems behind these words are quite real. And can at least be somewhat improved if we work hard and use the best ideas. But the lack of clarity in the word usage gets in the way of good communication and good thinking. And then the actions are muddled.
Let’s review these terms:
Here are my definitions.
Scaling: Means having multiple [Scrum] teams work together on one Product. In some sense, they are ‘in the same code base’ if it is a software product. Two teams working together is one kind of problem. 3-7 teams is one kind of problem. 8+ teams is another kind of problem.
Broader agile adoption:
Means to have more and more teams using Agile. Or new departments or divisions using Agile. For purposes of this idea, assume that each team is working completely independently. Note however: If your group is say 100 people, usually you also will be having some scaling as defined above (ie, here and there, at least, several teams are working together). Very common.
Agile Transformation:
Means mainly having the whole organization become truly agile, in values, principles, and practices. Not just the ‘development’ department (or whatever name your firm uses for that group). This often covers many different kinds of issues. 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.’
It can be said that even a small company with one Scrum team will have a kind of Agile Transformation. And then a company of 100 people people will have a more complex Agile Transformation. And then a company of 300,000 people might have a far more complex Agile Transformation.
Often this term is used to encompass ‘everything’. Meaning, all the changes needed in a big company ‘going agile’. ‘This is our Agile Transformation initiative’ is a sentence one could hear. OK, but then those two words many lots of different things to different people. Even with my relatively narrow definition, it starts to mean too many disparate things, in my opinion.
Cultural Change: This is where the culture of your group (team, department, company) must change because of Agile, or to make Agile more successful. This is almost always needed to some degree with most any of these other changes.
Again, cultural change is often assumed in the phrase ‘agile transformation’. And in a way, that is fair, almost always.
But at least in theory one can imagine a situation in which no cultural change is really required — the firm though could still need an Agile Transformation in terms of hierarchy, incentives, HR things, ways of managing, etc. I think it is useful to think of the culture change as a separate issue. Yes, as we are seeing, all these different things interrelate. This is in part why the words have been mushed together.
Distributed Agile or Scrum:
Covers two situations:
(a) one team has members in more than one location. In fact, if people are on two different floors, that is a ‘distributed’ team. Often distributed also means that at least one person is in a different time zone than another person on the team. And, typically, the wider the time zone split, the worse the problems.
(b) two or more teams must work together, and each Team is in a different location.
You might want to call (a) distributed team and (b) distributed agile.
I also use the term ‘disbursed agile’ to mean a team where no two people on the team are in the same place. I find this to be particularly hard to deal with. Typically.
Many people assume that ‘distributed’ is the biggest problem in scaling (or agile transformation — whichever their favorite word is). And yet many firms can be doing scaling or agile transformation without doing any distributed agile at all.
***
Maybe there are more terms to add to this list. And maybe these definitions can be improved. But it is one set of eyes on these ideas.
This post does not try to provide any solutions. In fact, it barely hints at what the real problems are. The only purpose is to give you some basic tools (ie, words) to start to think about what the problems really are. If we identify the problems better, then we have a better chance to fix them properly.
I have mentioned these ideas to a few other people. Some have been, at least I thought, rather cynical. And with some reason, I think. They see lots of consultants and others running around using words for marketing, and the feeling of these people is that consultants running around throwing around words is not helping. I have some sympathy with that concern. But I have not become cynical.
Second, I think they feel that these words and issues have become hopelessly muddled. I think their feeling is that talking about them publicly is a waste. Or, at least, humorous in a cynical way. (Maybe talking about these words in one room with 7 people is useful, but not in public.) Again, I do agree that getting many people to agree on common definitions of these words is almost hopeless.
Still, I obviously think that discussion in public is not hopeless. Although it is difficult.
Why?
Our experience is that when the community talks about these issues, they use these words in a very loose way. The problems behind these words are quite real. And can at least be somewhat improved if we work hard and use the best ideas. But the lack of clarity in the word usage gets in the way of good communication and good thinking. And then the actions are muddled.
Let’s review these terms:
- Scaling
- Broader Agile Adoption
- Agile Transformation
- Cultural Change
- Distributed Agile or Scrum
Here are my definitions.
Scaling: Means having multiple [Scrum] teams work together on one Product. In some sense, they are ‘in the same code base’ if it is a software product. Two teams working together is one kind of problem. 3-7 teams is one kind of problem. 8+ teams is another kind of problem.
Broader agile adoption:
Means to have more and more teams using Agile. Or new departments or divisions using Agile. For purposes of this idea, assume that each team is working completely independently. Note however: If your group is say 100 people, usually you also will be having some scaling as defined above (ie, here and there, at least, several teams are working together). Very common.
Agile Transformation:
Means mainly having the whole organization become truly agile, in values, principles, and practices. Not just the ‘development’ department (or whatever name your firm uses for that group). This often covers many different kinds of issues. 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.’
It can be said that even a small company with one Scrum team will have a kind of Agile Transformation. And then a company of 100 people people will have a more complex Agile Transformation. And then a company of 300,000 people might have a far more complex Agile Transformation.
Often this term is used to encompass ‘everything’. Meaning, all the changes needed in a big company ‘going agile’. ‘This is our Agile Transformation initiative’ is a sentence one could hear. OK, but then those two words many lots of different things to different people. Even with my relatively narrow definition, it starts to mean too many disparate things, in my opinion.
Cultural Change: This is where the culture of your group (team, department, company) must change because of Agile, or to make Agile more successful. This is almost always needed to some degree with most any of these other changes.
Again, cultural change is often assumed in the phrase ‘agile transformation’. And in a way, that is fair, almost always.
But at least in theory one can imagine a situation in which no cultural change is really required — the firm though could still need an Agile Transformation in terms of hierarchy, incentives, HR things, ways of managing, etc. I think it is useful to think of the culture change as a separate issue. Yes, as we are seeing, all these different things interrelate. This is in part why the words have been mushed together.
Distributed Agile or Scrum:
Covers two situations:
(a) one team has members in more than one location. In fact, if people are on two different floors, that is a ‘distributed’ team. Often distributed also means that at least one person is in a different time zone than another person on the team. And, typically, the wider the time zone split, the worse the problems.
(b) two or more teams must work together, and each Team is in a different location.
You might want to call (a) distributed team and (b) distributed agile.
I also use the term ‘disbursed agile’ to mean a team where no two people on the team are in the same place. I find this to be particularly hard to deal with. Typically.
Many people assume that ‘distributed’ is the biggest problem in scaling (or agile transformation — whichever their favorite word is). And yet many firms can be doing scaling or agile transformation without doing any distributed agile at all.
***
Maybe there are more terms to add to this list. And maybe these definitions can be improved. But it is one set of eyes on these ideas.
This post does not try to provide any solutions. In fact, it barely hints at what the real problems are. The only purpose is to give you some basic tools (ie, words) to start to think about what the problems really are. If we identify the problems better, then we have a better chance to fix them properly.
I have mentioned these ideas to a few other people. Some have been, at least I thought, rather cynical. And with some reason, I think. They see lots of consultants and others running around using words for marketing, and the feeling of these people is that consultants running around throwing around words is not helping. I have some sympathy with that concern. But I have not become cynical.
Second, I think they feel that these words and issues have become hopelessly muddled. I think their feeling is that talking about them publicly is a waste. Or, at least, humorous in a cynical way. (Maybe talking about these words in one room with 7 people is useful, but not in public.) Again, I do agree that getting many people to agree on common definitions of these words is almost hopeless.
Still, I obviously think that discussion in public is not hopeless. Although it is difficult.
Wednesday, October 2, 2013
Scaling: How about the “Don’t do it!” option?
There is a lot of talk lately about scaling. And, to some degree, scaling is necessary and good.
They say that only truly professional Teams try complicated plays. Or should try complicated plays. Most ‘lesser’ Teams do well to stick to basic blocking and tackling. I think this is wise advice for most teams.
Scaling by its nature is complicated. It is attempting the impossible. To keep a large ‘blob’ of people fully informed about what each other is doing. No, not 100% informed about every detail, of course, but ‘fully.’ Meaning: I, as a member of the blob, know everything I need to know to be effective (and to not be counter-productive) about anything that anyone else in the blob is doing.
Impossible. Human communication is very difficult in a Team of 7. Just about impossible in a blob. Unless it is extremely slow moving. Which of course is what blobs naturally do.
So, how about this? Instead of 50 people in 7 teams, let’s take the ‘best people’ from that blob, and make one Super Team. The hard part is finding ‘super’ team players. Or maybe better to say: The hard part is appreciating the value of being a team player over having a so-called ‘extraordinary skill-set’ (usually a specific skill or knowledge domain in our business). We all have seen that a bunch of high-ego people often won’t work together well.
Still, form your Super Team.
Maybe the other people can be useful, but the first rule is ‘do no harm.’ Get them the heck out of the way!! And let the Super Team run.
Can these other people doing anything? Well, yes: mow the grass. Honestly….they can do some ‘spade work’ that never gets in the way of the Super Team. They can do things that enable the Super Team to go faster. They can prepare things. But the key thing is to optimize the speed of the Super Team. (Ceteris Paribus.)
It’s an alternate idea. From a business point of view, often faster, cheaper and higher quality. And higher innovation.
Will this approach work well every time? Is it the best option available? Not sure; probably not. But often it is the best option available.
They say that only truly professional Teams try complicated plays. Or should try complicated plays. Most ‘lesser’ Teams do well to stick to basic blocking and tackling. I think this is wise advice for most teams.
Scaling by its nature is complicated. It is attempting the impossible. To keep a large ‘blob’ of people fully informed about what each other is doing. No, not 100% informed about every detail, of course, but ‘fully.’ Meaning: I, as a member of the blob, know everything I need to know to be effective (and to not be counter-productive) about anything that anyone else in the blob is doing.
Impossible. Human communication is very difficult in a Team of 7. Just about impossible in a blob. Unless it is extremely slow moving. Which of course is what blobs naturally do.
So, how about this? Instead of 50 people in 7 teams, let’s take the ‘best people’ from that blob, and make one Super Team. The hard part is finding ‘super’ team players. Or maybe better to say: The hard part is appreciating the value of being a team player over having a so-called ‘extraordinary skill-set’ (usually a specific skill or knowledge domain in our business). We all have seen that a bunch of high-ego people often won’t work together well.
Still, form your Super Team.
Maybe the other people can be useful, but the first rule is ‘do no harm.’ Get them the heck out of the way!! And let the Super Team run.
Can these other people doing anything? Well, yes: mow the grass. Honestly….they can do some ‘spade work’ that never gets in the way of the Super Team. They can do things that enable the Super Team to go faster. They can prepare things. But the key thing is to optimize the speed of the Super Team. (Ceteris Paribus.)
It’s an alternate idea. From a business point of view, often faster, cheaper and higher quality. And higher innovation.
Will this approach work well every time? Is it the best option available? Not sure; probably not. But often it is the best option available.
Wednesday, September 18, 2013
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.
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.
Subscribe to:
Posts (Atom)
