Impediments - Raleigh-Durham Feb 2014

I really want to advocate again that we must make the impediments visible in a public impediment list.  And never stop aggressively attacking them.  If you prefer to call it 'our list of things to improve on', I won't arrest you.

Here's the list the group made in this class.  They are not on order, they are not framed the same way, there will probably be some redundancies. These are in random order.

1. Team commitment to Scrum
2. Singular voice from PO
3. Team commitment to project
4. Unqualified Team members
5. Quality agile process training (Gee, I hope they were not talking about me? (smile))
6. (lack of) collocation
7. Finalizing sprint work / goals
8. Communication / collaboration
9. Definition of Done / of Ready
10. Replacing communication with documents
11. Non-value process for process' sake
12. Unclear requirements
13. Unrealistic or undefined scope
14. Clear definition of done (lack of)
15. Misunderstood requirements
16. Well defined sprint - days
17. Lack of team commitment
18. No vision or backlog of work
19. Unrealistic expectations
20. No support of team
21. Clear goal each sprint (lack of)
22. No unified team or stakeholders
23. (No) realistic expectations
24. Lack of senior leadership commitment
25. Actual list of impediments
26. Overall goal / delivery
27. Scope creep
28. No idea of what 'done' means
29. Self goals over project / team goals
30. Poor leadership
31. Resource constraints
32. No single voice (I think it was of requirements to team, eg, PO was not really there)
33. Expanded teams skills (need training)
34. No shared vision

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.

Agile Contracts – The Poppendiecks

Here are some additional resources for Agile Contracts.

http://www.youtube.com/watch?v=-ajwxtalBKE

A good presentation via video. From 2011.

http://www.slideshare.net/AgileLietuva/mary-poppendieck-agile-under-contract

A slide deck of a presentation in 2011. Not the same one as the video.

And be aware that the Poppendiecks did presentations on agile contracts over years, and typically each presentation was a bit different.

Open Agile Adoption

Open Agile Adoption is an ‘open’ approach to adopting and evolving agile, eg, in a given company.

By ‘open’ we mean that we are getting the people that will be ‘changed’ to engage in designing the change.

We do not mean total chaos.  Management might establish some ‘guardrails’ (eg, we will do the basics of Scrum, but exactly how should we implement that and what other things should we do?).

The first practical concept is to think of ‘iterations of change’.  Maybe a 2-month timebox.  Maybe longer.

Then, at the beginning of each ‘change iteration’ we have an Open Space event where we invite all the right people.  And let them ‘figure out’ what needs to be figured out to make the next 2 months more successful.  Maybe the Open Space event lasts for 1 day. (We will describe Open Space more later.)

Probably that leads to specific small initiatives that are done during that 2 months.

At the end of the 2 months, we have another Open Space.  This acts roughly like a Sprint Review and Retrospective for the ‘change iteration’ of 2 months. And like a Sprint Planning Meeting for the next 2 months of work on change.

What do we mean by ‘change’?  Well, everything. Fixing impediments, working on the cultural change, organizational issues.  Whatever it takes to get the most value from the change.

Little’s Second Law: People are remarkably good at doing what they want to do.

For more information on Open Agile Adoption, see here.

Impediments – Charlotte in-house course

These impediments were identified (some I think are redundant).  Note that some are expressed in quite a different way (eg, some negative, some positive). Dups may indicate that an issue is very important.

Legacy Code impacts
Allocate the correct people to the team
Address Env Issues
Define scope / business ask (better)
Multiple decision makers
Need more clarity on current state requirements
Lessen the amount of requirements for MVP
Empower them to make project choice decisions What is MVP?
External influences
Failing to ask customer what they want
Defects
Communication
Ensure understanding
Team building
Clean up technical debt
Implement automated unit testing
Setup collocated team
Reduce env. setup time
Reduce approval wait time
Environment Management improvement
Documentation of hack fixes or work-arounds (technical debt)
Clear architectural picture of systems & apps & what impacts what
Bad requirements
Moved too fast
Under-estimating story
Waterfall mind
Poor planning
Lack of people
Need an account with every possible type of purchase history scenario
Need dedicated team
Waterfall mindset
Tech Debt
Missed requirements
No coffee
Team interruptions
No collaboration
Poor processes
Working as a Team.of.One
Document priority list
Get team working together on same project
Fix technical debt
Role clarification
No scope definition
Infrastructure
Less confidence
Team members boxed into projects
Wrong skill-set in Team
Too big
Remove resource sharing
Move resource to area
Unknown technology
Lack of resources
Not working together
No business direction
Fix environment
Changing direction
Silos
Scope creep
Changing teams
Lack of communication
Environments
Poor testing
Wrong stakeholders
Date of deployment changed
People allocation
Too many organizational changes
Lack of product knowledge
Poor upfront planning
Extended testing duration
Poor performing team
More defined scope
Dedicated team members
Organize a team (define key roles within the team)
Do Scrum right (daily scrum, retrospective, length of sprint)
Dependencies on other releases
Have a scrum master assigned
Have a dedicated team!
Have a daily standup
Have a sprintly retrospective
Communication from offshore team
Competing priorities
Lack of process knowledge
Unclear requirements
Lack of funding
Lack of understanding team goal
Get all stakeholders on the same team
Remove dependencies from other teams
Internal politics
No sponsorship
Improve communication with team in Chicago
Team members not focused only on our team / project
Ability to release (lack of)
Code integration practices
Reduce environments (number of)
How many impediments should a team have on the list?  Well, it is important to identify the biggest thing to work on, and in that way, a list can help.  But after the top 20, does a longer list help?  Probably not.

If you have a group of teams, how many impediments should we have?  Well, in reality, we have 900+ impediments because nothing we do is perfect.  So, all 900 things might be improved.  But, again, realistically, with 4 scrum teams, a manager of that group might find a list of 40 helpful, but probably not more than that.

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.

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.

Agile Contracts: Another resource

Here is an additional resource from some smart people:
http://agilecontracts.org/

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.