Sunday, April 13, 2014

Interview with Ken Scwaber Part 2

Part 2:

Adoption of Scrum
Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 2 0f 5.  Enjoy.


KS - The latest data from Forrester says 92% of agile organizations are using Scrum, and I would have expected see 90 to 92% scrum and maybe 85% XP.  I think the static is a little funny because it doesnt say how many organizations are developing software just with Scrum and how many are using modern engineering techniques too.  I think if we ask about Scrum combined with modern engineering techniques the answer might be closer to 30 or 40%, which is still pretty reasonable. 


I think we have finally turned a corner on people thinking waterfall is a good approach for software development.  As long as that type of mentality persisted, there was always the chance that we could have fallen back to a misuse of RUP or strict waterfall again.

Sunday, March 23, 2014

Interview With Ken Schwaber Part 1

Part 1:

The Early Days of Scrum

Coming this spring, Better Software magazine will publish an interview with Ken Schwaber that I conducted.  As part of my blog, I will publish a number of excerpts.  Here is part 1 of 5.  Enjoy.

KS - Ive been working with the ideas of Scrum for 23 years. I was using one of the early OO technologies and at the same time the customer was coming back with changes - we were going nuts with our inability to deal with the technology difficulties and the constant request of changes.

I started to start coming up the ideas in scrum and agile and found that Jeff Sutherland was trying to solve the same problems by doing pretty much the same thing.  Jeff was formalizing these ideas from scrum so we started doing that together and by 1995 we had a pretty well described we called Scrum today.

We got an email from Kent Beck who had seen our initial work at Oopsla.  He liked the ideas and asked to borrow some of them which is why you see convergence between XP and Scrum.  


I had always hoped, in particularly leading up to the 2001 agile manifesto, that we could somehow band together because Scrum answers the question of how to develop within an agile framework.

Monday, March 10, 2014

Lightbulb experience

I had a lightbulb experience a few years ago  when I took a careful look at the agile values and tried to compare them to the traditional business values.  There really was no traditional set of values, so I had to construct my own version. 
I came up with: 
1) We develop processes and tools to standardize our interaction and maximize individuals’ productivity.
 2) All of our software has comprehensive documentation so that anyone can understand it quickly and easily.
 3) In order lock down a plan and cost for project, we enter contract negotiation with our customers.
 4) We follow a plan in order to minimize and control change.

 All of these are the exact opposite of the agile manifesto.  I now understood that the traditional techniques of developing software were based on control and came from a domain like construction, where the exact layout of the product under construction could be fully understood before beginning.  Software changes too quickly and it usually is a matter of “I’ll know it when I see it” for the end user.  

I began to see that a lot of what we do these days is a waste:  determining full requirements at the very beginning when they will change after a short time, estimating everything to the lowest level of detail at the beginning when the least amount was known about the project, putting together one-size-fits-all methods and then tailoring them down to the project at hand.  It’s all too much to just develop software.

I now use agile for software, running businesses, writing, creating all sorts of non-software related products.  It’s great.


Thursday, February 20, 2014

Agile Contract Models

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:

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.


Monday, February 10, 2014

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.