Agile Contract Models

Using the agile software development process in conjunction with client contracting is challenging due to the emergent nature of the detailed plan and product. Traditional contracts, used to bid or scope an agile development effort can subvert project execution and causes both parties miss the potential benefits of agile development since a full understanding of the client needs is assumed in a contract. 

Fortunately others have come before us who have tried different contracting models.

Some of the typical models of contracts are listed in the following table:

Contract Name	Description
Capped T&M	Use time and material  but cap the cost based on effort or scope.  Sets up a conflict with the customer as this model assumes all scope is known.
Fixed Bid	Price and scope is fixed.  Quality is the only variable – which is not good.  Assumes all scope is known.
Target Cost	Mutually target a cost, if final product cost is less, split the savings.  If final product cost exceeds target, share the extra cost.  Can be a tough sell and setting the target cost is a challenge.
Target ROI	Estimate work for effort and value to determine each piece’s ROI.  When the summation of effort and value for a sprint reaches a certain ROI, enter a ‘work wrap up’ sprint and end the project.
Contract by story point	Work is broken down into small stories and estimated by story points.  Fixed bid work is based on number of story points.  As the project progresses, scope is fixed but stories can be exchanged as long as they are not currently in a sprint.
Money for Nothing Changes For Free	This is a combination of target ROI and contract by story point.  The work is targeted toward a certain ROI and stories of the same size can be exchanged as long as they haven’t started yet.
Contract by Sprint	Each sprint is a mini project.  Could be contract by several sprints. Client can cancel after any given sprint.

* A good blog on agile contracts from another scrum.org coach:

http://scrumology.com/an-overview-of-agile-contracts/

The best contracts for agile use a variable scope and shared risk approach.  Of those, Target ROI, Contract by Story Point, and Money for Nothing Changes for Free are the most popular and effective.  Here’s a description of each.

Target ROI

Target ROI works when customers want fixed price estimates for the entire contract up front but the work has not been fully .  The Agile contract allows termination of the contract when the value of features drops below a certain ROI criteria.  It can be effective for delivering high value to the customer for a reasonable price and building trust.  The ROI value can be based on revenue or using other techniques. 

Contract by Story Point

Contract by story point works can well when the client wants a fixed bid based on work that isn’t very solidly defined or is emergent.  The estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint.  This technique works well when the client doesn’t know what they want or there is a large risk of discovery.  It can be risky though for both parties considering team velocity comes into play when billing the project.  Also story points can become a sticking point in client-provider relationships when the provider re-estimates detailed stories.

Money for nothing, changes for free

“Money for nothing, changes for free” can be though of as combination of Target ROI, Contract by Story Points, and Target Cost.  The following elements of each are combined:

·      Contract by Story Points - the estimates determined based on high level story points and, as work is broken down, stories of the same size can be substituted as long as they are not within a sprint. 

·      Target ROI - Delivery is based on a target ROI, and project payment is based on a mutual price

·      Target Cost - Mutually determine target a cost for a certain ROI, if the ROI is reached and the final product cost is less, split the savings.  If ROI is reached and the final product cost exceeds target, share the extra cost. 

This is a complicated contract but the risk is shared, the delivered product is malleable, and success is based on what really matters – value. If the business value is not realized on a particular cost target, then there should be a fall-back to time & material.

 “Money for nothing, changes for free” contract turns the advantages of the agile development processes into a competitive advantage by prioritizing and delivering business value incrementally and allowing change when something is learned.

SAFe and Agile

Incase you don't know SAFe stands for Scaled Agile Framework.  It's a framework for scaling agile through an organization and it's controversial - why later.  Think of 20 teams working on multiple backlogs and multiple year projects.  The funding - the planning - the organization - the roles all of these things are where SAFe is meant to play.

I attended a 4 day course for SAFe certified consultants a while back and wanted to share my thoughts.  First of all, SAFe could very well be a RUP-like tool with the same negative results.  The 4 day training gives the student the ability (if passing a test) to roll out SAFe at an organization as a consultant including training and process consulting – hogwash.  

Some students could implement SAFe in a large organization. Despite experience in agile at the enterprise level, I personally feel uncomfortable in such a role without seeing SAFe in the works.  Mistakes could lead to organizational level disaster. On the other hand, having appropriate guidance on enterprise adoption can be very helpful in the right hands.

SAFe does talk about emergence, self organization, and a lot of the leadership dynamics, but in the context of company maximized profit and a push-top down mentality. Decisions made at higher organizational levels can be painful in the wrong hands when the decisions are not based on a thorough understanding of emergence.

It also breaks a lot of the ground rules of scrum through HIP sprints, multiple levels of product owner, multiple levels of scrum masters, and potentially long planning horizons.

The big questions I have about the process revolve around it’s overall focus on large, large projects.  Why do you need 50 teams on a project?  Why not make a lot of small projects?  Why plan out for a couple of years?  Can you decouple work so that dependencies among teams isn’t so much of an issue?  How do you tailor SAFe? 

These are all questions that weren’t answered in the class and, frankly, I don’t know the answers either.

Ultimately SAFe has merit as a starting point, but should be applied with caution – it can easily be implemented as a push style of management without having an understanding of agile itself.  Remember values over mechanics.  Agile in general could get an ugly name through SAFe or any other process being implemented through certified neophytes.

Agile Adoption Maturity Levels

I recently had a thought that I'd like to share with others regarding agile thinking.  

I believe that agile maturity can be thought of in three levels:

1) Level 1 is where agile is thought of as a way to allow change through adaption and inspection.

2) Level 2 sees agile as proactive in it's ability to change:  it not only allows change, but proactively positions the organization to expect and anticipate changes, in part by actively deferring constraining commitments.

3) The most mature agile organizations must seek out change, not just passively await it.  The example is organizations that foster change through techniques such as hack-a-thons or innovation days.

I've come to see these levels by watching multiple companies introduce Scrum and the supporting agile mindset without seeing product innovation.  They simply wander to the same general destination as they always have, minimizing risk and reducing waste, the only innovation being in the minor details. That’s a pity, but often the best you can hope for until the organization matures.

These levels are not meant to relate to Shu-Ha-Ri nor the Dreyfus model of skill acquisition.  It’s just way of progressing a company to higher levels of empirical processes based on their attitudes of change.  It works for me.

Have you experienced the same?  

Another agile correction

If you're trying to find information about agile on the internet, I hope you've found that there is a lot of wrong information out there. Let me give you an example.

Here's a response based on the question of lean relating to agile.

"Many of the principles will find an echo in a Lean principle too, but one fundamental difference to keep in mind: Lean does NOT talk about iterations - only about reducing work-in-progress and delivering early. So you can be Lean without doing any iterations, but you cannot be Agile without iterations."

This is an interesting statement: "you cannot be agile without iterations". I think Mary Poppendyke, David Anderson, and many, many other agile leaders would find this untrue. The Scrumban approach as well many of the articles I've read about Kanban focus on flow and still claim they are agile without iterations. I think Mary Poppendyke believes that lean is agile dispite not having iterations.

I suppose saying that agile requires iterations really depends on what you would define agile as. In my world, an agile project deals with plan/do/inspect/adapt which requires doing, inspecting, and adapting, iterations are keys.  But I can also see a flow approach that inspects and adapts on a per story basis.

Small stories

If your stories are small, discrete pieces of work, Kanban fits well – no one story choked the backlog and stories didn’t need to be completed in groups. The business then has the flexibility to change the backlog of any story not on the Kanban board which means the process allowed the business to keep up with the development team. The business focuses on fewer stories, meaning that the stories they did focus on are of much higher quality. Keeping only 2 critical stories in the product backlog at any one time (limited by WIP), enables a fluid prioritization of the rest of backlog. The business team, who determines the content of the stories, is able to focus only the top few, leading to better time management and clearer stories.

Correction on Agile

If you're trying to find information about agile on the internet, I hope you've found that there is a lot of wrong information out there. Let me give you a couple of examples.

In a study group about agile certification, the question came up about iteration length. One of the participants posted the following;

"Sprint duration is fixed ONLY after some smiler (sic) Sprint cycles have finished so there is no such duration fixed (sic). Books may recommend some durations for understanding purposes and in practical (sic) smaller the Sprint, more effective it is.Once the Sprint is longer than 1 month or so, then again it effects its agility anyway(sic)."

Where did that come from? What does this mean? I wonder. Scrum.org paints iterations as time boxes of fixed length. Varying sprint lengths make it difficult to judge how much can be completed or do any type of forecasting. Sprint lengths are set and shouldn't vary - based on Schwaber, Cohn, Fowler, and more.

I have other examples I'll explore next month

Successive Refinement of Requirement/design

In agile, requirements are progressively detailed, with the finest details being developed as late as feasible. There are three main reasons for this just in time requirements detailing: no time is wasted on requirements that are possibly not going to be developed, decisions about requirements can take into account lessons learned in prior sprints and the requirements fresh in the mind of the team when they begin developing because the lag time between specification and implementation is short. Enabling flexibility in the requirements backlog and minimizing wasted work are just as important as detailing the requirements.

Design documentation has its highest value in helping work out the details of the software under construction, not as post implementation documentation. As a post-implementation artifact, documentation must be kept up to date with the software which adds to the cost of any software changes. If the documentation is even slightly out of date, the documentation looses credibility – the code becomes the ultimate documentation. Unless the documentation is automatically generated, design documentation is of limited value and should be prioritized low.

The pacesetter?

Pacesetting is a leadership style based on the premise that the leader’s manner of doing things is best. While the intentions may be noble (getting the project done) it’s a form of ego and can border on recklessness. Often times the individual doesn’t even realize that he/she is exhibiting classic signs of this leadership style.

First and foremost, we must recognize that agile development can provide a wealth of opportunities to act as a pacesetter. Consider the effect of one week iterations: given the right circumstances, at the end of every week there’s an opportunity to be a hero – to ensure that the team makes the weekly commitment goal. Another problem is that immature product owners can take advantage of pacesetters, pressuring them to add little features, and with agile’s emphasis on collaboration, there is often no way of telling (e.g. no documentation and change control) that the pacesetter is allowing micro bursts of scope creep. The technique of pair programming provides another prime opportunity for the pacesetter to be the center of gravity for getting things done, leading (or pushing) the pairing partner. Self selecting stories from the backlog can easily turn into a game where the pacesetter assigns him/herself to an inordinate number of stories early in the sprint – effectively marking many stories “in process”.

Agile development can also be a threat to the pacesetter’s sense of control – which can exaggerate the negative behavior. Agile emphasizes whole team participation, responsibility, and rewards. The pacesetter may feel lost and long to add value as an individual.

Back to product owners

So what's it take for a product owner to work well?

Observations:
• Technical people (i.e. former or current developers) can make poor product owners as they can tend to focus on the technical rather than business side of the house.
• Some of the best product owners are those that are very close to the customer.
• A manager may be a poor product owner because they tend to see the product in terms of tasks rather than features.
• Rotating a product owner causes quite a bit of churn. Don’t do it.
• Multiple product owners can be a bad idea unless they can collaborate together. Multiple product owners can be just as bad as multiple managers trying to manage one project.
• Product owners must be organized enough so they have stories ready for the sprint planning session.
• Business analysts can make good product owners as can technical sales people and product trainers.
• Look at the values of the agile manifesto and make sure your product owner can buy into them.
• If multiple stakeholders are involved in the product, you need one product owner to represent them. And that one representative must have the authority to make decisions without constant negotiation of the other stakeholders.

Word Cloud generators?

I had an interesting experience, I created a word cloud of my resume.  Have you tried wordclouding unusual items?   I've seen it done on code (if you remove the comments).  I used wordle. Pretty cool.

Product owners?

What are some of the things to look for when starting up an agile team and choosing the product owner?

-->

A good product owner must have:

Knowledge

·      Knows enough about the product to create and maintain a backlog – can write reasonable requirements and eventually stories.

·      Knows enough about the product and it’s context to conveys the vision and goals of the project and each sprint.

·      Understands the needs of the customer.

·      Knows enough about the technology to make reasonable decisions.

Authority

·      Can carry through the result of any tough decisions.

·      Owns the product success (or failure), so can prioritize the backlog and eliminate stories if they’re not high value.

·      Represents the customer, interfaces and engages the customer.

·      Can change the course of the project at the end of every Sprint.

·      Can terminate a Sprint if he/she determines such action is required.

·      Has the recognition to communicate status externally.

Availability

·      Has the time to work on the product backlog, despite other responsibilities.

·      Can actively participate in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives.

·      Has enough time to quickly respond to questions (that day) and sit with the development team when needed.

·      Actively inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done.

Aptitude

·      Able to resist the temptation to micromanage.

·      Not be afraid to make tough decisions.

·      Able to work in a team environment.

·      Focused, proactive, and engaged in the product.   

·      Good negotiator.

·      Deeply interested in helping the team be successful.

·      A “People Person” with patience.

·      Willing to learn and flexible enough to deal with the changes of agile.

 

Tips for new BAs

Remember that your business contacts are usually very busy and may not see providing information for project requirements as a priority. Be persistent, but considerate of their situation.

• Ask people when the best times to talk to them are and when it is best to leave them alone (when end of month process is going on, for example).
• Find out their preferred method of communication. If someone never responds to your e-mails try phone calls or stopping by their desk. If they hate interruptions, schedule time to meet or use e-mail.

 

If you are not getting adequate time with someone you need to talk to, address the problem as soon as possible. Talk to the person about possible times to meet. Address the issue with the project manager and in your status report.

 

Target your communication to your audience. Busy executives may not read anything except a single page with bullet points. Others will want to read every detail before signing off. Visual people may understand flow charts better than use case descriptions. Don’t use technical jargon or acronyms that your audience is unlikely to understand.

 

Since time is usually limited, use an agenda for all meetings and follow up by sending meeting minutes to the team.

 

Always, always have an agenda for meetings and a set of goals for the meetings.  

 

Mind Puzzles

Here are some ways to exercise creative thinking.  They are separate from eachother. Have fun.

Clear your mind

The idea is to get rid of problems that are keeping you from concentrating on the task at hand.
Take out a piece of paper and quickly write down any issues which come to mind. It doesn’t matter how small the issue is, write it down. Keep writing until there is nothing left to write. Then look at the list and acknowledge that you will deal with these concerns later. Fold the paper up and put it on the corner of your desk for later.

Define your problem

The idea is to come up with different expressions of your problem, leading to a new and unusual solution.
Use an idea quota. Write down 5 different ways to express your problem in 1 sentence.

Repeat at least 3 times.

Why and what ways

The idea is to drive to root cause (why) and back up to potential solutions.

Why do I spend time less time doing this thing that I should?

Why do you want to ...?

Why do you ...?

Why do you ...?

Why ...

Now restate the answers as “In what ways can I ....”

Mind map and negative mind map

The idea is to see the problem from a negative perspective and strengthen the positive.
Do a mind map of the problem.
Now do a mind map of the opposite of the ideas. I.E. opposite of fitness is sloth.

Random words

The idea is to look at the problem from differnt perspectives.

“In what ways can I ________________?”

Choose a random verb.

Explore the relationship between the sentence and your subject and then explore the non-relationship between the sentence and your subject.

Random Number Generators and Slot Machines

Has this ever happened to you: you're playing your favorite slot machine for nearly two hours, hoping to get that big jackpot but never really winning it. You take a break for lunch and come back an hour later just to see someone else playing your machine hit the big one. Is your first thought, "That's my jackpot! If I had only stayed I would have won it all.” Don't believe it. Slot machines are based on a sequence of pseudo-random numbers and, in a way, the timing of your play.

An slot machine is a computer (Electronic Gaming Machine or EGM actually) and computers can't really create random numbers, but can generate sequences of numbers that mimic randomness - Pseudo Random Numbers which are widely known as PRNs.  These PRNs are pretty good:  they're exercised with battery of tests run against the output to ensure the numbers are statistically random.  The most common algorithm, the linear congruent method (LCM) which generates numbers such that same sequence of numbers won't occur until about 2 billion numbers have been generated. Many EGMs use variations of the LCM that have cycle periods close to the number of molecules in our galaxy!  You can't guess the sequence even if you know the algorithm.

As a rule, EGMs generate a random number continuously, not every time you drop in a coin. It's not unusual for EGMs to generate over 1000 numbers in the sequence every second. Only when you place your bet does the machine capture the next 'random' number.  Knowing the algorithm isn't of much help since you'd have to drop your coin into the machine and bet at the exactly right 1/1000th of a second in order to get the number you were counting on.

Once the number is generated, the computer compares the number to a payout chart.  All games have a payout table referred to as the PAR (Percentage Average Return) chart. Each EGM has it's own individual PAR chart, usually ranging from 99% to 81%.

Every game (even if they look the same) has a different PAR chart and the chart is usually held as confidential by the casino. The payout rate advertised on the machine or in the casino usually portrays an average of all the games taken together. Since each game is a separate entity with its own random number generator, it is not uncommon for one game to have a payout of say 95% and the one next to it, with the same game title having a payout of 86%.


To further complicate matters, PAR charts are usually different depending on the amount of the bet.  Maximum bet has the highest return rate while smaller bets typically have a lower payout rate.

Once the payout (or loss) is determined, the slot machine spins the spinners with a command from the computer to land on a certain display.  The spinners really have NOTHING to do with the actual play, it's all handled by a random number generator and a table.  Even the 'bump' of the spinners is pre-determined based on the random number and table.  Sorry to take the fun out of it.

The bottom line is that gaming is truly random. If you are at the right place at the right time with max bet you too could win a sizable jackpot on an electronic gaming machine. The fun part is the anticipation of the win and the many little wins along the way that make slot gaming fun regardless of whether you win or loose.

How much worth is the man

Do you put a dollar on the value your epics deliver to the business?  If not you should; it will help you determine epics’ prioritization and give the the business owners an idea of value the project is delivering.
  

Consider this example: your software is used by 75 sales people and your changes save an average of 2 hours a week per person, you save 2 hour * 75 people or 150 hours a week which translates to 7,500 hours a year (50 weeks).  That's 3.75 people's time.  

If those people have an average salary of $40 an hour, that's a cost savings $300,00 a year (not bad).  If on the other hand each person produces $250,000 in new sales over a year (hopefully you expect staff value is more than their salary) you free up the  250K * 3.75 = $937,500. In the one case you save $300,000 by reallocating people and not growing the business, in the other case you can potentially grow the business by nearly a million.

Next time you’re calculating what a feature is ‘worth’, look at not only the cost savings side but the opportunity side - a perspective that many people miss.