- Joe's Approach to Release Planning
- Agile Release Planning Vision
- Agile Release Planning Product Backlog
- Agile Release Planning Business Value
- Agile Release Planning Effort 1
- Agile Release Planning Effort 2
- Agile Release Planning Risks, Dependencies, Learning, MMFS
- Agile Release Planning Completing the Plan
- Agile Release Planning Refactoring the Release Plan
Showing posts with label agile business. Show all posts
Showing posts with label agile business. Show all posts
Monday, March 7, 2016
Release Planning: Summary of our blog posts
Here are the main ones, in order.
Sunday, November 2, 2014
Avoid an agile adoption that's 'meh'
We suppose there are many ways to adopt Agile or Scrum.
And in a sense it is true that each organization adopts agile in it's own way.
One pattern is 'bottom-up'. This means that it starts with one team, who finds out about it and starts doing it, and then it spreads. Without official approval at first, but later with at least the authorities not resisting it. To the degree the 'bottom' gets the 'top' to support it in some ways, this can be a very successful approach.
And other pattern is 'top-down'. The Leader decides 'we will do agile', and tells the group in detail. This can work, to some degree, especially if the Leader has credibility and, in one way or another, explains what and particularly why. And gets buy-in. In that case, with time, it can be successful. Why? In my opinion, in large part because Agile justifies itself to the people. Once they try it, they see the results, and become convinced.
However, very commonly the top-down implementations are 'troubled.' They get some benefits, but people naturally resist. They do not become engaged, they do not buy-in. And, hence (at least IMO), the energy is not there, and so the adoption's benefits are rather modest. And the people slowly, in a sneaky way, start to revert back to what they want to do. Perhaps they do it consciously, maybe even more they do it unconsciously.
There is a another method now, called Open Agile Adoption. One of the key ideas is that it is 'optional', or maybe better to say 'experimental'.
In other words, it is an attempt to see what people will want to do. At first, as a group, they do not understand agile. Often, even later, they do not fully understand agile or scrum. So, we do recommend some training on what agile is. And some discussion within the group. And use other methods to learn what agile really is.
Then the Leader 'invites' them to experiment and discover the benefits.
One. The adoption is no longer 'forced' or perceived as forced. So, the natural resistance that occurs when you do that (at least in some people) is avoided.
Second. By inviting them, you get them to start to buy-in. They are making a choice. They feel like they are creating the change themselves.
***
Here’s how it works.
Here’s how it works.
1. Let's try letting them volunteer within the context of a vision. Practice, experiment, learn (much as Ohno suggests).
2. Let's get them engaged in the change itself (partly via doing practical work).
3. Let's bind these 'chapters of learning' (or chapters of change) in timeboxes. We call each timebox a 'rite of passage'. Maybe 2-3 months. After each timebox, the group levels up.
4. Let's put a self-organizing event at either end of the timebox. We'll call these 'open spaces'. 1 day each. And they act kind of like a sprint planning meeting and a retrospective, all rolled into one.
Then rinse and repeat.
And let's include Steve Denning's idea of leadership story-telling. In fact, let everyone tell stories (they do anyway), but we (the good guys) tell MORE stories than we usually do (for God's sake! We must!).
And the culture gets changed.
***
I recommend this set of ideas.
Start here: http://newtechusa.net/open-agile-adoption/
And read Harrison Owen's book, Spirit, here: http://www.openspaceworld.com/Spirit.pdf
This is a fascinating read. Too intense, I think, to read quickly.
This is a fascinating read. Too intense, I think, to read quickly.
Heck, you are NOT going to read Harrison's book until you watch the video: https://www.youtube.com/watch?v=APD7oQ3xrSA
It's about 14 minutes.
It's about 14 minutes.
***
OAA is practical and tested approach to 'good' agile adoption.
Who knew we could treat the people like people? And self-organize the change within a vision!
This approach allows, as far as I know, you (as agile advocate) to do also almost every other 'trick' you were going to do. But whenever you do something now, do it with respect for the brains of the people you want to change. Get them to see the merits. Don't think about 'forcing' it.
So, the Leader does not 'mandate' the change in detail. ie, In OAA the Leader can give a vision (eg, at first "We want to experiment with agile methods to see if they will work with us"), but we urge you not to add too much detail to the vision.
AND...you (the leader or the leader group) can also OFFER to them details about things (like Scrum) that they might use. And suggest that they *experiment with them."
So training, coaching, talking can still be used. But in the context of invitation.
Who knew people, especially our knowledge workers, needed a feeling of autonomy? (Cf Danial Pink in "Drive".)
Seriously, I recommend you consider this approach. You will get more success.
Thursday, October 30, 2014
Strategy as Distributed Phronesis - Nonaka
Some of you will recognize this name. He is one of the two men who wrote The New New Product Development Game, which directly lead to the creation and naming of Scrum.
Here is slide deck on "Strategy as Distributed Phronesis."
Sounds like a mouthful, but it has some great stuff in there.
I think you will enjoy.
Monday, May 26, 2014
Blinding flash of the obvious
Tom Peter's wrote a blog post, about the blinding flash of the obvious.
Suffice to say, I think it is worth the read.
Enjoy!
Thursday, April 3, 2014
Organizing a small-ish company to do Scrum and ‘regular work’
Holly asks: “I am relatively new to this methodology, and I would like to learn more about how resources are assigned to Scrum teams. Resource allocation – do Sprint team members need to spend 100% of their time in a Scrum Team? If so, how do we account for existing job responsibilities?”
***
Good question or questions.
Good question or questions.
In simple terms, we are dying from complexity. So, we want to keep things as simple as possible, to help people become more productive.
This is what I am thinking from what I know of your situation. Imagine that your company has 800 employees, but most are ‘in the field’. So, you have 75 people who support ‘BAU’ (business as usual), who are not ‘in the field’ and are potentially available to support Innovation.
So, for 125 of the BAU people, I would have a rule that they are 80% dedicated to BAU and each person can use up to 20% of their time to support ‘innovation’.
I would maybe move 25 of the current BAU people to an Innovation group, which would include other people already doing innovation (technology people, project managers, etc.). Then we call this group doing ‘Innovation’ or ‘Change’, which now has about 75 people.
Let’s assume my ratios of BAU and Innovation people is roughly correct for now. It provides enough hours to do the related BAU work (if 20% of their time is given to Innovation). It still raises two questions:
(a) is this the optimum ratio?
(b) should the firm be investing more (or less) in Innovation?
(a) is this the optimum ratio?
(b) should the firm be investing more (or less) in Innovation?
These two questions should be of prime interest to the Exec Team.
Note that often the Innovation people are doing work to benefit the BAU people, directly or indirectly.
These are the two main groups. Note that the innovation people include business people also.
I would form most of the people in Innovation into Scrum Teams. But the BAU people are NOT part of the Scrum Teams. At least not as ‘pigs’, although they may work with the Scrum Teams some as chickens (in their 20% time).
We would group work into ‘Product Backlogs’ that have groupings of stuff that can be released quickly. We get a limited number of ‘projects’ or product releases in flight at any one time. In simple terms, one project per Scrum Team (per 7 people in a Scrum Team).
Obviously, we can only support, with the Innovation people we have, a limited number of product releases at any time (in any year).
Each Innovation person is 80% dedicated to one Team (but can advise others with 20% of their time). The Innovation people are 100% innovation…no meaningful BAU responsibilities. They can ‘advise’ others on BAU work in their 20% time.
It may be that some lower priority projects will ‘require’ some BAU people to be involved. But a lower priority project can only start if someone feels that they can get enough BAU support to be viable. Or can get enough ‘business support’ elsewhere (within Innovation, via consultants, whatever). This will not be the case; this may represent a significant constraint on the number of inflight Innovation teams. So some projects will be blocked until higher priority projects complete, and ‘release’ certain BAU people.
So, X project may not be able to start. The Exec Team can decide to hire people or not, to fix that impediment. Or, we go to the next viable priority project. (Remember that business information can get into a Team either from Innovation people (eg, product owners or BAs or whatever we call them) or from BAU people.
Why? We need to be focused on getting things DONE, not on how much work is ‘in process’. We need to be focused on accountability by Team. Each Scrum Team is focused on the next release. (That means the release is much more likely to get done well and quickly.)
How to form the Teams? Here is a good option. Have 3 managers draft up a set of teams. The Innovation people look at that and then ‘self-organize’. They can modify the proposal. Give the Innovation people a week to meet, discuss and change the proposed teams. With the understanding that any person in a Team is 80% dedicated to that one Team, at least. Then the 3 managers review the alterations and give final approval. The group usually does a very good job.
Later we discover a few things, and realize we need to make some adjustments; the Teams usually can manage that.
The real issue is when to start and stop ‘projects’.
Whenever we have a better project than one currently in flight, we need a way to pause the existing project (or get it to release early) and start the higher value project. Before pausing, we tell the related Team, and ask them ‘we want to ‘pause’ your project…can you release most of what you have now ‘real soon’? How soon?’ Then adjust according to their advice.
Another issue is: when does the ET know that a Scrum Team is coming ‘free’? I give the Scrum Teams the responsibility to ‘brag’ about a Release they are about to put out. They are clearly expected to release quickly, products of high value and high quality.
So, when a Team has just released, the ET can give a different ‘assignment’ or ‘mission’. The Team may make a case that they need to stay on Product 1 for the next release. But the ET gets the final decision.
In this vision, the main jobs of the ET are two (for the innovation teams)
1. Fix impediments
2. Be decisive about priorities.
This includes….when a Team finishes a release, what do we give them next?
Given where we have come from, I suspect the Team will have to say (probably repeatedly for awhile): “We are only working on one and only one release at a time…the one of top priority.”
Tuesday, February 25, 2014
Question: More on Agile Contracts
Gabriel asks: Can you suggest me few relevant papers on Agile contracts? I am interested in both the ad-hoc, non-commercial agreements, to maximize, based on Pareto law naive application, the output of PO-development team through collaboration, and the commercial agreements that best support such an objective. I read this: http://www.agilecontracts.org/agile_contracts_primer.pdf but I would like to read more materials on the topic.
Here is a short answer. And maybe too basic for you.
1. You can have a waterfall contract (old style) and use agile to deliver. And probably things will turn out better. One problem could be getting progress paid for ‘interim deliverables’ (documents), but I won’t do there now.
2. I like Jeff Sutherland’s idea about an ‘agile contract’ half-way house. It is between a waterfall contract and a real agile relationship between the buyer and the seller.
The basics are: you get a BRD from the client, and convert that to a product backlog. You organize the PB by business value, add story points, and give it a fair overall cost. And you estimate the ‘final delivery date’. And then discuss contract terms.
In summary, the terms include:
Client will inspect every sprint. Change for free (if we did something wrong…obviously we built in some padding for this…aka ‘contingency’).
Equal substitution. If the client wants to add a feature, then a feature (story) of equal size comes out.
Addition. Client can still just add a feature, at the same old price (high).
Early Termination. The client can terminate early if the client pays X% of the remaining contract. (X=20%?)
This gives the vendor a strong incentive to terminate early. And aligns the vendor with the customer need to ‘complete’ faster. Also, the features are built (mainly) in BV order.
Jeff Sutherland calls it ‘money for nothing and change for free’. Smile. A good step in the right direction. Often the biggest first step one can make away from the old waterfall contract.
3. A real agile contract.
This is more like a T&M contract. The client becomes the PO. Or at least can change the PB at any time.
The key term is that the client ‘owns’ the team continuously, for as long as they want and at a monthly price. And the client can cancel the contract at any time, with X months’ of notice. (X=2?)
This gives both parties an incentive to work well together, and get it done early (get the next release out early). The vendor does good work each month to justify continuing to be employed by the client. The client gives good PB items (stories) to the team to maximize the BV from the team.
And this contract maximizes the ability to change. And reduces ‘early termination’ costs for the client. Typically the vendor should charge a higher rate, since the customer is getting in every other way a great deal.
If I were the client, the first work for the team would be agile release planning, where they helped me establish an initial sense of the scope, dates and costs for the first release or two. But I would understand that this initial plan will change. And largely due to me — due to business side changes. But not only due to that….due to other learnings as well.
Nowadays, the key problem with the real agile contract is often the lawyers. The business guys at the client understand the need to do things this way, but they can’t explain it to the lawyers well enough. So, the contract does not get changed enough. See comment on Larman/Vodde below.
***
Other resources for contracts include earlier blog posts on this topic:
http://www.leanagiletraining.com/blog/agile/agile-contracts-the-poppendiecks/
http://www.leanagiletraining.com/blog/agile-business/agile-contracts-another-resource/
http://www.leanagiletraining.com/blog/agile-business/the-basics-of-agile-contracts/
http://www.leanagiletraining.com/blog/business-value/agile-contracts/
http://www.leanagiletraining.com/blog/better-agile/agile-contracts-question-1/
http://www.leanagiletraining.com/blog/key-problems/joes-real-agile-contract/
***
Some notes:
* The Poppendiecks focus on the larger goals of agile contracts and give you some specific examples of how it worked. How do we get the vendor and the client in alignment, and share risks appropriately?
* Larman and Vodde talk about getting the lawyer(s) in the mindset of agile. The details come out better if the underlying thinking is agile.
* It is of course still true that some people are still stuck on keeping the waterfall contract: scope, date and budget are locked down, and the vendor gets some progress payments based on waterfall ‘deliverables.” So, the first thing is to discuss how this is working for them so far. Typically, not very well. So, gathering some examples of the failures of waterfall contracts might be needed to loosen up the thinking.
Here is a short answer. And maybe too basic for you.
1. You can have a waterfall contract (old style) and use agile to deliver. And probably things will turn out better. One problem could be getting progress paid for ‘interim deliverables’ (documents), but I won’t do there now.
2. I like Jeff Sutherland’s idea about an ‘agile contract’ half-way house. It is between a waterfall contract and a real agile relationship between the buyer and the seller.
The basics are: you get a BRD from the client, and convert that to a product backlog. You organize the PB by business value, add story points, and give it a fair overall cost. And you estimate the ‘final delivery date’. And then discuss contract terms.
In summary, the terms include:
Client will inspect every sprint. Change for free (if we did something wrong…obviously we built in some padding for this…aka ‘contingency’).
Equal substitution. If the client wants to add a feature, then a feature (story) of equal size comes out.
Addition. Client can still just add a feature, at the same old price (high).
Early Termination. The client can terminate early if the client pays X% of the remaining contract. (X=20%?)
This gives the vendor a strong incentive to terminate early. And aligns the vendor with the customer need to ‘complete’ faster. Also, the features are built (mainly) in BV order.
Jeff Sutherland calls it ‘money for nothing and change for free’. Smile. A good step in the right direction. Often the biggest first step one can make away from the old waterfall contract.
3. A real agile contract.
This is more like a T&M contract. The client becomes the PO. Or at least can change the PB at any time.
The key term is that the client ‘owns’ the team continuously, for as long as they want and at a monthly price. And the client can cancel the contract at any time, with X months’ of notice. (X=2?)
This gives both parties an incentive to work well together, and get it done early (get the next release out early). The vendor does good work each month to justify continuing to be employed by the client. The client gives good PB items (stories) to the team to maximize the BV from the team.
And this contract maximizes the ability to change. And reduces ‘early termination’ costs for the client. Typically the vendor should charge a higher rate, since the customer is getting in every other way a great deal.
If I were the client, the first work for the team would be agile release planning, where they helped me establish an initial sense of the scope, dates and costs for the first release or two. But I would understand that this initial plan will change. And largely due to me — due to business side changes. But not only due to that….due to other learnings as well.
Nowadays, the key problem with the real agile contract is often the lawyers. The business guys at the client understand the need to do things this way, but they can’t explain it to the lawyers well enough. So, the contract does not get changed enough. See comment on Larman/Vodde below.
***
Other resources for contracts include earlier blog posts on this topic:
http://www.leanagiletraining.com/blog/agile/agile-contracts-the-poppendiecks/
http://www.leanagiletraining.com/blog/agile-business/agile-contracts-another-resource/
http://www.leanagiletraining.com/blog/agile-business/the-basics-of-agile-contracts/
http://www.leanagiletraining.com/blog/business-value/agile-contracts/
http://www.leanagiletraining.com/blog/better-agile/agile-contracts-question-1/
http://www.leanagiletraining.com/blog/key-problems/joes-real-agile-contract/
***
Some notes:
* The Poppendiecks focus on the larger goals of agile contracts and give you some specific examples of how it worked. How do we get the vendor and the client in alignment, and share risks appropriately?
* Larman and Vodde talk about getting the lawyer(s) in the mindset of agile. The details come out better if the underlying thinking is agile.
* It is of course still true that some people are still stuck on keeping the waterfall contract: scope, date and budget are locked down, and the vendor gets some progress payments based on waterfall ‘deliverables.” So, the first thing is to discuss how this is working for them so far. Typically, not very well. So, gathering some examples of the failures of waterfall contracts might be needed to loosen up the thinking.
Sunday, February 9, 2014
Joe’s real agile contract
Adela asks: “Please send me some information [on] the details contracts shall contain [for] those projects where the methodology is Agile.”
To talk more clearly, let’s imagine a situation. Imagine you are a ‘development firm’, ie, in response to external client needs, you develop custom software.
Imagine that the client contacts your firm. He knows and trusts your firm fairly well already. He has heard of agile, but does not know it well.
You discuss the situation with your main contact and his people. You explain agile some, and specifically, that you need to develop a product backlog in order to give a price (a budget) and some rough dates. (He needs this rough information to determine if the project is viable.)
The first thing I want is to do is ‘Joe’s Agile Release Planning’ with the client’s people. I have talked about that a lot on the blog and in my book, Joe’s Agile Release Planning. My summary here:
1. Meet for a day and
define the Vision
develop the Product Backlog
estimate Business Value
estimate Effort
calculate the R Factor
review Risks, Dependencies, Learning, MMFS, and other factors
Order the Work
Do the scope/date cut-offs
Finalize the Day Zero plan
The client may be tempted to spend 2 weeks or 2 months to have a ‘requirements gathering’ phase. Maybe for a couple of days, but try to talk them out of it. (Usually this delay for a 6 month project is not worth the trade-off. Doubtful even for larger projects.)
2. Tell them you will give them a team to do that work. 100% dedicated to doing that work. He must give you a Product Owner, 100% dedicated to working with that Team. (How dedicated the PO and others at the client might be is subject to some discussion. For now: maybe not always 100%.)
Explain that the Team will work X hours per week (eg, 40), and have normal vacations and holidays. This will not change. (We will never do a Death March.)
This team has a cost per sprint. Which you give to the client. (That price includes your profit.)
The client can now see the rough costs for the features in each release on product backlog. Make sure the client adds in some ‘contingency’ for each release.
You discuss the conditions under which the people on the Team might change. The basic idea is that he ‘owns’ (in a good way only) the people on the Team.
You help him understand the magic of the Team. And that your Team has special magic (assuming it does).
3. You ask the client “Do the benefit-cost ratios for each release look good to you?”
He will almost always say ‘yes’. At least for the first few releases.
4. You say ‘Let’s talk about the Contract.’ At this point you propose that he pay for each sprint on essentially a time and materials basis. He can change the product backlog at any time (for now, let’s say he cannot change the stories in the sprint, during the sprint).
We will estimate the work in story points. Since he can see the velocity, and he knows the cost of the team per sprint, he can see the cost per story point.
5. If at any time this does not seem good to him, he can stop. He must give us X notice before stopping. (I will say 2 months. Negotiable.) When he cancels, we will immediately help him take all the then working product, and help him put that in production if he wants.
6. He only has to pay us for the sprints we work. He is not locked into a long-term contract. Thus, we have high incentive to be doing the best we can each sprint to keep him working with us. We have to deliver every sprint. And our team is 100% dedicated to him, and only his work.
He knows from the past with vendors, that often they would be pulled off his project to work on another project. So, he likes the 100% dedicated.
7. You explain that our team may need some specialists. Either from his company or our company. We will try to give him advance notice of any special skills needed, and their cost (if our people). In any case, this will also be reviewed on a ‘sprint-ahead’ basis, to assure the team is not stuck.
You also estimate now any known specialist work, and give the client that estimate.
8. Our team will have a 100% dedicated ScrumMaster (assume it is a Team of 7 (including their PO and our SM).
Also, 1/7th of the budget of the Team will go into an ‘impediment removal’ fund. (We have included this already in the price of the Team.) So that the team has some money to remove impediments.
The client and the Team will discuss how and when this money is spent on removing impediments. This is not money he can ‘take back’. But it is money he can help us spend to improve the velocity of the Team. Including the ‘fun’ of the Team.
Overall, we expect that, with higher innovation and higher productivity, the client will get more business value.
9. You remind the client that success is very dependent on getting good business value information and good detailed requirements information into the team promptly. You discuss the issues around that. You explain the importance of the PO he is providing.
10. You explain the value to him of the inherent adaptability built into this contract. And how it minimizes his risks. And gives us an incentive to optimize his values (early release, high business value, only do the essential things, adapt to change).
Then you ask: “Does that sound like a fair contract?”
***
Note: For some readers, the contract described above may appear to be impossible or totally unrealistic. And, for your clients, it may be. But be aware that other firms and other clients are indeed doing contracts on essentially this basis. You can too, with enough learning, enough discussion, and enough trust.
To talk more clearly, let’s imagine a situation. Imagine you are a ‘development firm’, ie, in response to external client needs, you develop custom software.
Imagine that the client contacts your firm. He knows and trusts your firm fairly well already. He has heard of agile, but does not know it well.
You discuss the situation with your main contact and his people. You explain agile some, and specifically, that you need to develop a product backlog in order to give a price (a budget) and some rough dates. (He needs this rough information to determine if the project is viable.)
The first thing I want is to do is ‘Joe’s Agile Release Planning’ with the client’s people. I have talked about that a lot on the blog and in my book, Joe’s Agile Release Planning. My summary here:
1. Meet for a day and
define the Vision
develop the Product Backlog
estimate Business Value
estimate Effort
calculate the R Factor
review Risks, Dependencies, Learning, MMFS, and other factors
Order the Work
Do the scope/date cut-offs
Finalize the Day Zero plan
The client may be tempted to spend 2 weeks or 2 months to have a ‘requirements gathering’ phase. Maybe for a couple of days, but try to talk them out of it. (Usually this delay for a 6 month project is not worth the trade-off. Doubtful even for larger projects.)
2. Tell them you will give them a team to do that work. 100% dedicated to doing that work. He must give you a Product Owner, 100% dedicated to working with that Team. (How dedicated the PO and others at the client might be is subject to some discussion. For now: maybe not always 100%.)
Explain that the Team will work X hours per week (eg, 40), and have normal vacations and holidays. This will not change. (We will never do a Death March.)
This team has a cost per sprint. Which you give to the client. (That price includes your profit.)
The client can now see the rough costs for the features in each release on product backlog. Make sure the client adds in some ‘contingency’ for each release.
You discuss the conditions under which the people on the Team might change. The basic idea is that he ‘owns’ (in a good way only) the people on the Team.
You help him understand the magic of the Team. And that your Team has special magic (assuming it does).
3. You ask the client “Do the benefit-cost ratios for each release look good to you?”
He will almost always say ‘yes’. At least for the first few releases.
4. You say ‘Let’s talk about the Contract.’ At this point you propose that he pay for each sprint on essentially a time and materials basis. He can change the product backlog at any time (for now, let’s say he cannot change the stories in the sprint, during the sprint).
We will estimate the work in story points. Since he can see the velocity, and he knows the cost of the team per sprint, he can see the cost per story point.
5. If at any time this does not seem good to him, he can stop. He must give us X notice before stopping. (I will say 2 months. Negotiable.) When he cancels, we will immediately help him take all the then working product, and help him put that in production if he wants.
6. He only has to pay us for the sprints we work. He is not locked into a long-term contract. Thus, we have high incentive to be doing the best we can each sprint to keep him working with us. We have to deliver every sprint. And our team is 100% dedicated to him, and only his work.
He knows from the past with vendors, that often they would be pulled off his project to work on another project. So, he likes the 100% dedicated.
7. You explain that our team may need some specialists. Either from his company or our company. We will try to give him advance notice of any special skills needed, and their cost (if our people). In any case, this will also be reviewed on a ‘sprint-ahead’ basis, to assure the team is not stuck.
You also estimate now any known specialist work, and give the client that estimate.
8. Our team will have a 100% dedicated ScrumMaster (assume it is a Team of 7 (including their PO and our SM).
Also, 1/7th of the budget of the Team will go into an ‘impediment removal’ fund. (We have included this already in the price of the Team.) So that the team has some money to remove impediments.
The client and the Team will discuss how and when this money is spent on removing impediments. This is not money he can ‘take back’. But it is money he can help us spend to improve the velocity of the Team. Including the ‘fun’ of the Team.
Overall, we expect that, with higher innovation and higher productivity, the client will get more business value.
9. You remind the client that success is very dependent on getting good business value information and good detailed requirements information into the team promptly. You discuss the issues around that. You explain the importance of the PO he is providing.
10. You explain the value to him of the inherent adaptability built into this contract. And how it minimizes his risks. And gives us an incentive to optimize his values (early release, high business value, only do the essential things, adapt to change).
Then you ask: “Does that sound like a fair contract?”
***
Note: For some readers, the contract described above may appear to be impossible or totally unrealistic. And, for your clients, it may be. But be aware that other firms and other clients are indeed doing contracts on essentially this basis. You can too, with enough learning, enough discussion, and enough trust.
Sunday, February 2, 2014
Agile Contracts: Another resource
Here is an additional resource from some smart people:
http://agilecontracts.org/
http://agilecontracts.org/
Saturday, February 1, 2014
Question: The Basics of Agile Contracts
Melinda asks this question: How can SCRUM/Agile Methods be
effectively leveraged for responding to RFP/proposals for Fixed price
& Fixed Date contracts especially when the SCOPE (I.e. Product
Backlog) is more adaptive to change? When would CRs be required, if at
all? How can we help customers understand and be confident that they
will receive greater value for a Fixed Price & Fixed Date contract
than the traditional Waterfall methods?
Answer: This is a hard question, but I think phrased in a reasonable way.
Let's take one extreme. If you have a completely unreasonable customer, who wants lots for nothing in no time, then nothing is going to fix that. Not waterfall, not Scrum, not Agile. So, you have to start with a reasonable business situation and reasonable partners.
Then, for today, let me make these basic statements.
1. We can use Agile Release Planning (as I define that in my book and teach that in my course) to establish the scope and the date. And also the budget. I believe you can do this better with these agile methods than with our typical waterfall methods.
2. I have assumed in the Agile approach, you have added a reasonable amount of buffer (cushion, contingency, whatever you call it).
3. We show the customer the product backlog and the business value points, and how we have ordered the work (in mainly benefit-cost order). The customer can 'correct' this order (within reason).
4. Building it in Agile will be more effective. We will understand better, and build it more cheaply.
5. If 'unexpected' changes are too great (we get a tsunami hitting our building), then we may still fail. But bear in mind that the cushion should have been built for a reasonable amount of 'stuff' hitting the fan (that's the technical phrase).
6. You ask the customer: "Could you come in once a month (or whatever your sprint length is) to see the software we have built so far, and gives us feedback? And if anything is wrong, not correct according to the spec, we will fix it for free?" ('Wrong' means truly 'not to spec' -- they don't get to go crazy with 'implied' features.) Any reasonable customer will jump at the chance to do this, since they know from long experience that the bad news does not get better with age. Even though they understand that those meeting cost them something.
7. You ask: "Does it ever happen, when you examine the software, that you discover new features that you want?" Of course, that always happens, so they say 'yes'. So, you offer them 'change for free' as explained below.
8. We tell the customer: "You can make changes in two ways. You can get 'change for free' -- meaning you can identify a new feature of 2 SPs (story points) and substitute it for an existing low value feature of 2 SPs. Even exchange, aka 'change for free'. Not additional cost.
9. The customer can also add a feature via a CR (change request), and we can price it at our usual (high) rates for changes.
10. Because both of these are open, the customer tends to argue that 'it was implied already in story 54' a lot less. Of course, they still want and make changes for, mainly, the two classic reasons: (a) they think of it after they look at some of the working product, or (b) their business situation has changes some, and so the features need to change.
11. Speed of delivery. In the past, we as a consulting firm only made money if the project went long. The original contract is always priced 'too low' because we have to beat the competition. But once the customer is in bed with us, they have to use us for changes, so when they asked for CRs (and they always did), then that is when we could make some profit (finally!). So, we wanted the project to go 'late' in this way.
12. But the customer always wanted it sooner. To be honest, they wanted it before they even asked for it. AND...while they 'wanted' (or said they wanted) lots and lots of features, what they really wanted was something simple that worked, and did the most important thing(s) well.
13. So, we offer them 'money for nothing'. Meaning: We offer them an 'end early' clause. They have the option to cancel the contract at any time, so long as they pay us 20% of the remaining contract.
14. The key thing is that this aligns our needs (we are the consulting company or vendor) with theirs. We both want to deliver fast. Faster.
15. Example: The contract is $10 million and 20 months. We complete 4 months (we have Pareto on our team). That's 20% of the work. Over those 4 or 8 sprints, we have convinced them to take an early release. The value of the work to them is much much higher than the cost. So, since the first 4 months has the highest value items, the value of the features from the first 4 months is huge. (I won't do the math here, but you can guess at it.) The customer WANTS to release early. Partly because we have seduced them with 'sizzling steak'. (Some of you will know my 'killing babies or sizzling steak?' metaphor.)
16. The Money: For the 20% of work, that is $2 million. Leaviing $8 million in the contract. They cancel clause says they must pay us 20% of the remaining, or $1,600,000. Money for nothing (we built nothing to get that money). And the customer is happy to pay it to get early delivery of the high business value features.
So, money for nothing and change for free. Easy to remember if you get into dire straits as a consultant. (Sorry about that.)
Let us repeat: If you have an impossible customer or an impossible situation, nothing is a silver bullet. Still, this approach gives you far greater probabilities for success. IMO.
See also Jeff Sutherland's blog posts on this. And his presentation.
Answer: This is a hard question, but I think phrased in a reasonable way.
Let's take one extreme. If you have a completely unreasonable customer, who wants lots for nothing in no time, then nothing is going to fix that. Not waterfall, not Scrum, not Agile. So, you have to start with a reasonable business situation and reasonable partners.
Then, for today, let me make these basic statements.
1. We can use Agile Release Planning (as I define that in my book and teach that in my course) to establish the scope and the date. And also the budget. I believe you can do this better with these agile methods than with our typical waterfall methods.
2. I have assumed in the Agile approach, you have added a reasonable amount of buffer (cushion, contingency, whatever you call it).
3. We show the customer the product backlog and the business value points, and how we have ordered the work (in mainly benefit-cost order). The customer can 'correct' this order (within reason).
4. Building it in Agile will be more effective. We will understand better, and build it more cheaply.
5. If 'unexpected' changes are too great (we get a tsunami hitting our building), then we may still fail. But bear in mind that the cushion should have been built for a reasonable amount of 'stuff' hitting the fan (that's the technical phrase).
6. You ask the customer: "Could you come in once a month (or whatever your sprint length is) to see the software we have built so far, and gives us feedback? And if anything is wrong, not correct according to the spec, we will fix it for free?" ('Wrong' means truly 'not to spec' -- they don't get to go crazy with 'implied' features.) Any reasonable customer will jump at the chance to do this, since they know from long experience that the bad news does not get better with age. Even though they understand that those meeting cost them something.
7. You ask: "Does it ever happen, when you examine the software, that you discover new features that you want?" Of course, that always happens, so they say 'yes'. So, you offer them 'change for free' as explained below.
8. We tell the customer: "You can make changes in two ways. You can get 'change for free' -- meaning you can identify a new feature of 2 SPs (story points) and substitute it for an existing low value feature of 2 SPs. Even exchange, aka 'change for free'. Not additional cost.
9. The customer can also add a feature via a CR (change request), and we can price it at our usual (high) rates for changes.
10. Because both of these are open, the customer tends to argue that 'it was implied already in story 54' a lot less. Of course, they still want and make changes for, mainly, the two classic reasons: (a) they think of it after they look at some of the working product, or (b) their business situation has changes some, and so the features need to change.
11. Speed of delivery. In the past, we as a consulting firm only made money if the project went long. The original contract is always priced 'too low' because we have to beat the competition. But once the customer is in bed with us, they have to use us for changes, so when they asked for CRs (and they always did), then that is when we could make some profit (finally!). So, we wanted the project to go 'late' in this way.
12. But the customer always wanted it sooner. To be honest, they wanted it before they even asked for it. AND...while they 'wanted' (or said they wanted) lots and lots of features, what they really wanted was something simple that worked, and did the most important thing(s) well.
13. So, we offer them 'money for nothing'. Meaning: We offer them an 'end early' clause. They have the option to cancel the contract at any time, so long as they pay us 20% of the remaining contract.
14. The key thing is that this aligns our needs (we are the consulting company or vendor) with theirs. We both want to deliver fast. Faster.
15. Example: The contract is $10 million and 20 months. We complete 4 months (we have Pareto on our team). That's 20% of the work. Over those 4 or 8 sprints, we have convinced them to take an early release. The value of the work to them is much much higher than the cost. So, since the first 4 months has the highest value items, the value of the features from the first 4 months is huge. (I won't do the math here, but you can guess at it.) The customer WANTS to release early. Partly because we have seduced them with 'sizzling steak'. (Some of you will know my 'killing babies or sizzling steak?' metaphor.)
16. The Money: For the 20% of work, that is $2 million. Leaviing $8 million in the contract. They cancel clause says they must pay us 20% of the remaining, or $1,600,000. Money for nothing (we built nothing to get that money). And the customer is happy to pay it to get early delivery of the high business value features.
So, money for nothing and change for free. Easy to remember if you get into dire straits as a consultant. (Sorry about that.)
Let us repeat: If you have an impossible customer or an impossible situation, nothing is a silver bullet. Still, this approach gives you far greater probabilities for success. IMO.
See also Jeff Sutherland's blog posts on this. And his presentation.
Friday, January 31, 2014
6 Myths of Product Development - Take 2
Months ago, I mentioned here a great article. Here is an article about: Six Myths of Product Development. By Stefan Thomke and Donald Reinertsen.
Strongly recommended. Especially good for managers and executives.
Here are the fallacies in one list:
Let's do the first two today. Quickly.
1. High utilization - Myth
Ok, ceteris paribus (other things being equal) high utilization of the resources would be good. Lower cost per widget.
But in knowledge work especially, we only deceive ourselves. First, it is often based on the false premise that knowledge workers are fundamentally lazy. Demoralized, demotivated -- maybe. But not lazy. (Ok, maybe 1 in 30 has some real laziness, but we do not recommend 'pushing' on high utilization to get that fixed. Fix it another way, and we do in Scrum.)
Second, high utilization, as shown in the article, leads to low through-put from the system (to us, the system is the Team). Nothing gets delivered quickly.
And in product development (eg, software development) fast delivery is ESSENTIAL. No, it is much much more essential and critical than my capital letters imply. We barely have a glimpse, in my opinion, about how critical it is. And in how many ways it is critical.
Once we recognize that, then we must struggle with seeing the utilization level, and adjusting it to the optimum level. (We are not proposing super-low utilization. Just lower, to get the through-put.) We have some rough techniques for that in basic Scrum. As you become professional in using those techniques, you may want to fine-tune the techniques for each team.
Again, a push for high utilization by managers is killing us. Managers should focus on speedy delivery of smaller things (smaller releases).
2. Large batches - Myth
It often feels as if we become more efficient with large batches. And, it is partly true in a way.
But it is mostly false, and in all the important ways.
Large batches tend to lead to silos. That means we tend not to work together as a team (in all the bad ways we mean with that phrase).
Large batches means that problems are hidden. And hidden problems are much harder to fix. And, in knowledge work, the bad news does not get better with age.
Large batches means that things are not delivered quickly to the customer. And speedy delivery to the customer is essential.
Large batches allows our knowledge a much greater opportunity to decay in value. In all the many different ways it can decay in value. Often to zero.
I have to mention the 'carrying costs' of large batches. It leads to much more 'inventory' or 'work-in-process'. If you could see or visualize the cost of that 'partially done work' and you were a good manufacturing manager, you would be aghast at all the excess cost.
And our work is done by very expensive people. The accumulated costs are huge.
So, while it seems (and is a bit) more efficient in some ways to have large batches, in net the costs are higher. And the 'time to market' much slower. A lose-lose.
***
There are two short commentaries on the great article. Please read it.
Strongly recommended. Especially good for managers and executives.
Here are the fallacies in one list:
- High utilization of resources will improve performance.
- Processing the work in large batches improves he economics of the process.
- Our plan is great; we just need to stick to it.
- The sooner the project is started, the sooner it will be finished.
- The more features we put into a product, the more customers will like it.
- We will be more successful if we get it right the first time.
Let's do the first two today. Quickly.
1. High utilization - Myth
Ok, ceteris paribus (other things being equal) high utilization of the resources would be good. Lower cost per widget.
But in knowledge work especially, we only deceive ourselves. First, it is often based on the false premise that knowledge workers are fundamentally lazy. Demoralized, demotivated -- maybe. But not lazy. (Ok, maybe 1 in 30 has some real laziness, but we do not recommend 'pushing' on high utilization to get that fixed. Fix it another way, and we do in Scrum.)
Second, high utilization, as shown in the article, leads to low through-put from the system (to us, the system is the Team). Nothing gets delivered quickly.
And in product development (eg, software development) fast delivery is ESSENTIAL. No, it is much much more essential and critical than my capital letters imply. We barely have a glimpse, in my opinion, about how critical it is. And in how many ways it is critical.
Once we recognize that, then we must struggle with seeing the utilization level, and adjusting it to the optimum level. (We are not proposing super-low utilization. Just lower, to get the through-put.) We have some rough techniques for that in basic Scrum. As you become professional in using those techniques, you may want to fine-tune the techniques for each team.
Again, a push for high utilization by managers is killing us. Managers should focus on speedy delivery of smaller things (smaller releases).
2. Large batches - Myth
It often feels as if we become more efficient with large batches. And, it is partly true in a way.
But it is mostly false, and in all the important ways.
Large batches tend to lead to silos. That means we tend not to work together as a team (in all the bad ways we mean with that phrase).
Large batches means that problems are hidden. And hidden problems are much harder to fix. And, in knowledge work, the bad news does not get better with age.
Large batches means that things are not delivered quickly to the customer. And speedy delivery to the customer is essential.
Large batches allows our knowledge a much greater opportunity to decay in value. In all the many different ways it can decay in value. Often to zero.
I have to mention the 'carrying costs' of large batches. It leads to much more 'inventory' or 'work-in-process'. If you could see or visualize the cost of that 'partially done work' and you were a good manufacturing manager, you would be aghast at all the excess cost.
And our work is done by very expensive people. The accumulated costs are huge.
So, while it seems (and is a bit) more efficient in some ways to have large batches, in net the costs are higher. And the 'time to market' much slower. A lose-lose.
***
There are two short commentaries on the great article. Please read it.
Wednesday, January 29, 2014
Agile Reading for Executives
A recent email I sent, slightly edited.
Dear Mike and Mark:
You asked for something to give the executives and managers.
I might send them "The New New Product Development Game" article (see below). With a short explanation. And then offer them these other things to look at.
Other options:
Software in 30 Days - Schwaber and Sutherland. More from the manager's viewpoint than other Scrum books.
"The Basics of Scrum" - a great paper. I assume it must have been written by Jeff Sutherland, who is great. I will confirm that. 9 pages.
Drive, by Daniel Pink is great on motivation for knowledge workers. 272 pages.
Video about Drive (Daniel Pink). Here: http://www.youtube.com/watch?v=rrkrvAUbU9Y About 18 minutes.
"The New New Product Development Game" by Takeuchi and Nonaka - This is the key paper that led to the development of Scrum. Many of the key principles behind Scrum are described there. And the use of the Scrum metaphor in that paper led to the name of "Scrum" for this agile method. 11 pages (HBR)
The Power of Scrum by Sutherland et al. A "novel" about a manager's journey. Fairly realistic. Semi-real (that is, I am sure they took a real situation, and modified it some.) Not a Tom Clancy novel. But still, a lot of key ideas from an exec's viewpoint, in an easy to read format. 128 pages.
"Six Myths of Product Development" by Thomke and Reinertsen. Wonderful recent HBR article. Not about Scrum per se, but all the 6 ideas (myths) are key to Scrum. And if executives or managers do not understand these 6 key ideas, and particularly if they take decisions contrary to them, then Scrum will be much less effective. 9 pages. (HBR)
"Scrrum and CMMI - Going from Good to Great" by Jakobsen and Sutherland. Short read about implementing Scrum. 5 pages.
"The Discipline of Teams" by Katzenbach and Smith. Strong, stable, real, dedicated Teams are key to successful Scrum. Extremely common that executives and managers do not value the Team enough. 11 pages. (HBR) They also wrote a book, The Wisdom of Teams. Recommended.
"Knowledge-Worker Productivity: The Biggest Challenge" by Peter Drucker. On page "83" there are 6 major points. 16 pages.
Regards, Joe
I will get these all on my website soon. Some are there now.
Dear Mike and Mark:
You asked for something to give the executives and managers.
I might send them "The New New Product Development Game" article (see below). With a short explanation. And then offer them these other things to look at.
Other options:
Software in 30 Days - Schwaber and Sutherland. More from the manager's viewpoint than other Scrum books.
"The Basics of Scrum" - a great paper. I assume it must have been written by Jeff Sutherland, who is great. I will confirm that. 9 pages.
Drive, by Daniel Pink is great on motivation for knowledge workers. 272 pages.
Video about Drive (Daniel Pink). Here: http://www.youtube.com/watch?v=rrkrvAUbU9Y About 18 minutes.
"The New New Product Development Game" by Takeuchi and Nonaka - This is the key paper that led to the development of Scrum. Many of the key principles behind Scrum are described there. And the use of the Scrum metaphor in that paper led to the name of "Scrum" for this agile method. 11 pages (HBR)
The Power of Scrum by Sutherland et al. A "novel" about a manager's journey. Fairly realistic. Semi-real (that is, I am sure they took a real situation, and modified it some.) Not a Tom Clancy novel. But still, a lot of key ideas from an exec's viewpoint, in an easy to read format. 128 pages.
"Six Myths of Product Development" by Thomke and Reinertsen. Wonderful recent HBR article. Not about Scrum per se, but all the 6 ideas (myths) are key to Scrum. And if executives or managers do not understand these 6 key ideas, and particularly if they take decisions contrary to them, then Scrum will be much less effective. 9 pages. (HBR)
"Scrrum and CMMI - Going from Good to Great" by Jakobsen and Sutherland. Short read about implementing Scrum. 5 pages.
"The Discipline of Teams" by Katzenbach and Smith. Strong, stable, real, dedicated Teams are key to successful Scrum. Extremely common that executives and managers do not value the Team enough. 11 pages. (HBR) They also wrote a book, The Wisdom of Teams. Recommended.
"Knowledge-Worker Productivity: The Biggest Challenge" by Peter Drucker. On page "83" there are 6 major points. 16 pages.
Regards, Joe
I will get these all on my website soon. Some are there now.
Sunday, December 8, 2013
Agile Contracts – Question 1
Adela asks this question: Imagine we have a brand new project. And we must bid on it, and we want to use the agile-scrum method. How should that work?
This is a good and a hard question. I will answer it quickly here. Too quickly. I have partly answered it in my book, Joe’s Agile Release Planning. And partly elsewhere.
Why is it a hard question? Because business and life itself wants us to do what is impossible. To perfectly predict the future. And to know everything in advance. And, while we all forever will wish those two statements were true (well, at least part of each of us will), they never will be true.
So, let’s make the case fairly simple. Imagine that the project (the work) is about what one Team can do in 6 months.
Then I recommend Agile Release Planning (as explained fully in my book).
The Team (including the right ‘business stakeholders’ or SMEs or customer reps or whatever you call them) do the following:
- Clarify the vision. Quickly
- Build the product backlog. In user story format. Roughly all that work divided into about 50 stories. Not to large, not too small.
- Identify business value on each story. Via priority poker. Using the best BV people we can find (about 5 of them). In about 1 hour.
- Identify the Effort for each story. Using planning poker. Again, using the right people for this (namely, the people who will do the real work).
- Identify the R Factor (BVP/SP). For each story. Make the benefit-cost ratios more explicit. Order the work now by R Factor.
- Consider Risks, Dependencies, Learning, Min Marketable Feature Set, and other issues. Re-order the work as needed.
- Do the scope-date trade-offs. In other words, identify the ‘release’ cut-offs.
- Estimate the velocity of the team. And identify when each release will happen.
- Do a communications ‘plan’ and add appropriate buffer (aka padding, contingency, etc.)
- Identify the ‘fix it plan’ to fix the biggest imperfections in the plan first.
- Start ‘release plan refactoring’ — where we refactor the release plan every sprint based on new learning.
Now, the first time you do Agile Release Planning, I think you will get a better (slightly more accurate) scope-date-budget than you do using your current method. Still, for the first or second time, I do recommend doing it both ways. And comparing the results, and learning from that.
By the third time, I predict that you will be happier with this agile approach than your current approach.
Will the agile approach on day zero ever be ‘perfect’? No.
Always we guess at the buffer or padding. And always that guess can be too much (not a big problem if the customer agrees) or too little (a big problem if it causes us to go bankrupt). Notice that we as a vendor are biased to want to win contracts, and hence often ‘close our eyes’ and go with too little ‘padding’. Often.
In any case, once we get a signed contract, I recommend running the project in an agile way. Again, this cannot guarantee success, but it will enable us to manage the effort to better success (or a lower loss).
That’s the summary of my answer in one short blog post. I am sure I left many questions unanswered.
Friday, October 11, 2013
Key Impediments – Toronto
I am a big advocate of a public impediment list. (Yes, for some
of you, I am saying this again. I think in general it bears repeating
and repeating in a company.)
There is some discussion to explain skeptics WHY I recommend this. I will not attempt that discussion here (but maybe I should soon in another post … I have in the past, just search).
By the way, I recommend only ONE list of all impediments. Some people are tempted to have several lists. One for org impediments, one for agile adoption issues, one for Blockers (things that block a story from getting done, is the usual definition), one for impediments (however they define that term). To me, ALL these things (and more) are just different types of impediments. We we need only ONE list. And work from the top.
In the Toronto class this week, the group identified these impediments. They are not in any specific order.
There is some discussion to explain skeptics WHY I recommend this. I will not attempt that discussion here (but maybe I should soon in another post … I have in the past, just search).
By the way, I recommend only ONE list of all impediments. Some people are tempted to have several lists. One for org impediments, one for agile adoption issues, one for Blockers (things that block a story from getting done, is the usual definition), one for impediments (however they define that term). To me, ALL these things (and more) are just different types of impediments. We we need only ONE list. And work from the top.
In the Toronto class this week, the group identified these impediments. They are not in any specific order.
- Poor skill Team (skill sets are weak)
- Non Formed Teams
- Source Availability Planning
- Under estimate scope by Prod Owner
- Lack of investment (don’t remember what kind of investment the person wanted)
- Lack of requirements
- No product road-map (vision)
- Scope creep
- Lack of Comms
- Final product quality was poor
- Project team over-worked
- Senior leadership commitment & mission
- No clear product owner
- Unrealistic Time/Scope commitment
- Low accountability
- Project over budget
- Lack of ownership individuals
- Business down – layoff of developers / teams
- Ownership to one person
- Technology hurdles (ie, infrastructure)
- Too Bossy, No Teamwork
- Not able to remove impediments
- Low communication
- Not doing demo (sprint fail)
- No connection between Dev & Business
Wednesday, October 2, 2013
Deliver Faster
Why do we want to deliver fast, and then faster?
Well, the first reason is...that's what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.
The second reason: time to market. In this context, I mean we need a good poduct to market before the opportunity goes away. Before the competition beats us there, or before the most important problem has changed.
Third. More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped "we need to deliver faster than the next re-org". This meant within the next 3 months.
So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.
But there is more. We need to deliver faster because we get more feedback. In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.
This minimizes risk. This minimizes WIP, whose value...if we wait long enough...will always eventually go to zero. So, we have minimized the potential loss in value of the WIP, the work-in-progress. We have reduced the risk.
All the reasons that make us want to deliver something faster.
Yes, it must be a minimum marketable feature set. But we are learning that 'minimum' is smaller than we thought.
Deliver faster. This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.
Then the question becomes: how do we do that?
Well, the first reason is...that's what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.
The second reason: time to market. In this context, I mean we need a good poduct to market before the opportunity goes away. Before the competition beats us there, or before the most important problem has changed.
Third. More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped "we need to deliver faster than the next re-org". This meant within the next 3 months.
So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.
But there is more. We need to deliver faster because we get more feedback. In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.
This minimizes risk. This minimizes WIP, whose value...if we wait long enough...will always eventually go to zero. So, we have minimized the potential loss in value of the WIP, the work-in-progress. We have reduced the risk.
All the reasons that make us want to deliver something faster.
Yes, it must be a minimum marketable feature set. But we are learning that 'minimum' is smaller than we thought.
Deliver faster. This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.
Then the question becomes: how do we do that?
Sunday, August 25, 2013
What are impediments?
An impediment is anything that is slowing down the Team. (The Scrum Team)
In PMP words, it is any kind of issue. And it may include risks as well, but typically only high probability risks that are likely to occur soon. (I do typically recommend a simple risk log for each Scrum team -- but that is an add-on to Scrum, not part of the bare framework of Scrum.)
Anything.
Even things beyond our control. A hurricane in NYC. A tsunami. A people issue. Lack of a babysitter.
In fact, since nothing we do is perfect, every team has at least 900 impediments. Things that can be improved somehow. The only real question is, what are the top 20 things to improve. Or problems to address.
Some people say that blockers and impediments are different. I say no. First, blockers are usually defined as a thing (eg, lack of knowledge) that keeps a User Story from being completed in a Sprint. This is an ok definition. But blockers are just one type of impediment.
Just as there is only one Product Backlog for a Team, there is only one impediment list for a Team.
Thus, there is only one list for the ScrumMaster to manage (on behalf of the Team). And the SM should always be driving the top impediment to completion. (To some mitigation, where it is no longer #1, and something else becomes the #1 impediment.)
Some types of impediments:
It turns out that usually each Team will feel improvement as soon as the agile adoption is 'complete'. Hence, agile adoption gets on the same list. (This maybe needs more explanation in another post.)
Anything (anything!) that would lead to the Team going at a higher velocity (at a sustainable work pace) is an impediment. So, the lack of positive things (Coke machine) is an impediment.
An FAQ:
1. How often does a Team start with impediments? Ans: Always.
2. Can the Team do some work even though it has many impediments? Ans: Almost always. Except the velocity would be higher if some were mitigated (well, in general, the more mitigation, the higher the velocity).
3. Can a Team be completely stopped by one impediment? Ans: In theory, of course -- yes. But in practice, this seldom happens. Or the duration of the stoppage is not terrible. Two main points:
a. The Team does not get to use the impediments as an excuse for doing nothing.
b. Someone should always be working on the top impediment, and the firm should always be making a reasonable investment in helping the Team get better.
4. Should the Team stop working if some impediments are not fixed? Ans: In general, this seems .... not the most mature approach. But in some companies, to break certain patterns, this threat or even this action for some time might be useful and necessary. To make a point.
5. Should we fix all the impediments before we start Sprinting? Ans: NO! First, by definition there are always more imperfections to work on, and we have never seen a real team that could not improve. Second, Scrum helps the Team the next most important impediment to work on. Thus, you must be Sprinting to get that information.
6. Who fixes an impediment? Ans: It depends on the impediment. Obviously, the best person should fix the impediment. "Best' is a multivariate equation. In practical terms, some are fixed by the SM. Some by the PO. Some by the Doers in the Team. Some by people outside the Team.
7. One can imagine that some technical impediments (eg, inability to do continuous integration) or organizational impediments (a tollgate process built for waterfall) could take many months or longer to fully fix. Is this reasonable? Ans: Yes, very often this is the case.
8. Who decides which is the Top impediment? Ans: Ideally, the Team. Certainly, it is form the whole team's point of view. And the SM should force the Team to decide. It is acceptable if the Team decides to let the SM decide. Although for the bigger impediments addressed in the Retrospective, the SM should force the Team to agree to the ordering of the Top few impediments. Which still might change by the next day.
9. In prioritizing the impediments, what kinds of factors should come into play? Ans: Well, for beginners let's say this. Impediments, like large user stories, must be broken down into digestible chunks. The (expected and actual) impact on velocity is key. Cost-benefits analysis is important. Sequencing is important (eg, for technical impediments).
10. How quickly do we want to benefits from work on impediments? Ans: About every Sprint, at least.
11. Could the ordering of the impediment list change from day to day? Ans: Yes. And often not every day, but on many days. For many reasons.
12. Does the Team always identify the best impediments? Ans: No. At least, not without coaching, usually. We recommend giving the Team a a challenge. Say: "We need to double the velocity of the Team in 6 months, without anyone working more than 8 hours per day. Ever. So, what do we need to change?" If they see it as a reasonable challenge, they often get more creative.
13. Is a public impediment list useful? Ans: Definitely!
14. Why is a public impediment list useful? Ans: Many reasons. Here are my favorite three reasons.
a. By seeing everything on the list, Team members can know when it is useful to add things to the list.
b. By seeing the ordering, Team members can know when it is useful to give input on changing the priorities (and when it is only wasteful).
c. Everyone, including the SM himself (herself) knows what the SM is working on. The top impediment!
In PMP words, it is any kind of issue. And it may include risks as well, but typically only high probability risks that are likely to occur soon. (I do typically recommend a simple risk log for each Scrum team -- but that is an add-on to Scrum, not part of the bare framework of Scrum.)
Anything.
Even things beyond our control. A hurricane in NYC. A tsunami. A people issue. Lack of a babysitter.
In fact, since nothing we do is perfect, every team has at least 900 impediments. Things that can be improved somehow. The only real question is, what are the top 20 things to improve. Or problems to address.
Some people say that blockers and impediments are different. I say no. First, blockers are usually defined as a thing (eg, lack of knowledge) that keeps a User Story from being completed in a Sprint. This is an ok definition. But blockers are just one type of impediment.
Just as there is only one Product Backlog for a Team, there is only one impediment list for a Team.
Thus, there is only one list for the ScrumMaster to manage (on behalf of the Team). And the SM should always be driving the top impediment to completion. (To some mitigation, where it is no longer #1, and something else becomes the #1 impediment.)
Some types of impediments:
- Blockers (for a user story)
- People issues
- Technical issues
- Lack of knowledge
- Operational issues
- Managerial Issues
- Organizational issues
- Process issues
- Outside disruptions (outside means from outside the Team)
- External things (weather, riots, war, etc)
- Problems that the Pigs have at home (eg, lack of babysitter)
- Lack of positive things (eg, the Team needs its own Coke machine)
- Business or customer issues
- Culture and waterfall attitudes
- Impediments to faster Scrum/Agile adoption
- Etc Etc
It turns out that usually each Team will feel improvement as soon as the agile adoption is 'complete'. Hence, agile adoption gets on the same list. (This maybe needs more explanation in another post.)
Anything (anything!) that would lead to the Team going at a higher velocity (at a sustainable work pace) is an impediment. So, the lack of positive things (Coke machine) is an impediment.
An FAQ:
1. How often does a Team start with impediments? Ans: Always.
2. Can the Team do some work even though it has many impediments? Ans: Almost always. Except the velocity would be higher if some were mitigated (well, in general, the more mitigation, the higher the velocity).
3. Can a Team be completely stopped by one impediment? Ans: In theory, of course -- yes. But in practice, this seldom happens. Or the duration of the stoppage is not terrible. Two main points:
a. The Team does not get to use the impediments as an excuse for doing nothing.
b. Someone should always be working on the top impediment, and the firm should always be making a reasonable investment in helping the Team get better.
4. Should the Team stop working if some impediments are not fixed? Ans: In general, this seems .... not the most mature approach. But in some companies, to break certain patterns, this threat or even this action for some time might be useful and necessary. To make a point.
5. Should we fix all the impediments before we start Sprinting? Ans: NO! First, by definition there are always more imperfections to work on, and we have never seen a real team that could not improve. Second, Scrum helps the Team the next most important impediment to work on. Thus, you must be Sprinting to get that information.
6. Who fixes an impediment? Ans: It depends on the impediment. Obviously, the best person should fix the impediment. "Best' is a multivariate equation. In practical terms, some are fixed by the SM. Some by the PO. Some by the Doers in the Team. Some by people outside the Team.
7. One can imagine that some technical impediments (eg, inability to do continuous integration) or organizational impediments (a tollgate process built for waterfall) could take many months or longer to fully fix. Is this reasonable? Ans: Yes, very often this is the case.
8. Who decides which is the Top impediment? Ans: Ideally, the Team. Certainly, it is form the whole team's point of view. And the SM should force the Team to decide. It is acceptable if the Team decides to let the SM decide. Although for the bigger impediments addressed in the Retrospective, the SM should force the Team to agree to the ordering of the Top few impediments. Which still might change by the next day.
9. In prioritizing the impediments, what kinds of factors should come into play? Ans: Well, for beginners let's say this. Impediments, like large user stories, must be broken down into digestible chunks. The (expected and actual) impact on velocity is key. Cost-benefits analysis is important. Sequencing is important (eg, for technical impediments).
10. How quickly do we want to benefits from work on impediments? Ans: About every Sprint, at least.
11. Could the ordering of the impediment list change from day to day? Ans: Yes. And often not every day, but on many days. For many reasons.
12. Does the Team always identify the best impediments? Ans: No. At least, not without coaching, usually. We recommend giving the Team a a challenge. Say: "We need to double the velocity of the Team in 6 months, without anyone working more than 8 hours per day. Ever. So, what do we need to change?" If they see it as a reasonable challenge, they often get more creative.
13. Is a public impediment list useful? Ans: Definitely!
14. Why is a public impediment list useful? Ans: Many reasons. Here are my favorite three reasons.
a. By seeing everything on the list, Team members can know when it is useful to add things to the list.
b. By seeing the ordering, Team members can know when it is useful to give input on changing the priorities (and when it is only wasteful).
c. Everyone, including the SM himself (herself) knows what the SM is working on. The top impediment!
Subscribe to:
Posts (Atom)
