Yow Conference Australia

Looking forward to attend Yow Developer Conference next week.  The conference has pretty good and popular speakers. Some of the popular speakers  include Martin Fowler, Mary and Tom Poppendieck,Linda Rising, Joshua Kerievsky, Eric Evans. 

Leader's Workshop, 2 days workshop by Mary and Tom is going to be an important workshop for me to attend.

This workshop is going to cover the following areas:

• How to discover what customers really want.
• How to look at your process from a customer's point of view and identify waste.
• What's wrong with software testing and what you have to do to fix it.
• How to engage people and stimulate focused innovation.
• Scaling patterns that have proven successful - and their context.
• How to frame risk and rethink scheduling to permit confident promise-dating and reliable delivery.
• Tools for solving problems that everyone in the organization can use.
• Leadership roles that work - from the perspective of followers.
• How traditional governance systems can lead to sub-optimization and what to do about it.

Who is best positioned to write a User Story ?

Someone with a strong domain knowledge is suitable for writing User Stories and It is typically a person close to the business.  Having said that, I strongly believe that  everyone  in a Scrum team should know how to write User Stories.

Reflecting back on Ron Jefferies’s Circle of Life, User stories have 3 key aspects:  Cards, Conversation and Confirmation.

Conversation is the key aspect to be noted here.

This is how a typical User Story writing conversation takes place:

1. Some one from Business (Product Owner(PO) or Business Analyst(BA)) would write the Story on a card.
2. They keep this card on a table and invite the delivery team including developers, architect, testers, etc into the conversation.
3. The delivery team will ask questions to understand the story and in turn BA or PO would make a note of these changes, but any one standing there could pick up the card and make necessary changes to the User Story card.
4. Technical people (Architect, DB admin, etc) get involved if the discussion is tilted around technical user stories.
5. Product Owner is the final approver of all the User stories
 

Depending on the size of the project, dedicated people (typically BAs) should be allocated to write User Stories.
In smaller projects, Product Owners can write User Stories.

Problem with specialization

I  saw the above poster on a closed restaurant near my apartment.

First thing that came to my mind seeing this poster was “Issue with Specialization”.   

Let me share this a bit in detail:

Looking at the poster, it is clear that Chef is unavailable for 4 weeks as he is flying abroad to visit family. Due to chef’s unavailability the entire restaurant is closed for 4 weeks (or until his return).

Since Chef is the only specialist available with no “Cross Functional” team in the restaurant, any issue related to Chef impacts the entire restaurant.

Using this analogy on software development, the projects are at high risk when we have specially skilled team members with no backups .

On a lighter note, while reading the poster, you might also feel that the restaurant is being run by a non-English speaking owner.

Agile Contracts

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Writing contracts is a key topic for the sales team getting involved in Agile projects.  In the  projects applying traditional methodology, companies had zeroed down on two popular models that are: 

1. Fixed Price and
2. T & M (Time and Material)

While working on Fixed price model, software vendors would analyse  the requirements upfront and commit to a price with the customer.  Many a times, the customer fixes a price and the committed bidder gets the project.  

The uncertainties involved in the software development makes this model a flawed one.   As per the popular and well researched  Cone of Uncertainty,  the initial estimate done at the beginning of the software project could be +/- 400%

 

off-mark than the actual calculated at the end.   In order to mitigate these uncertain risks, companies participating in these contracts have to add a lot of unscientific buffer to accommodate them.

Projects applying Agile methodologies is supposed to have a flux associated with them. The scope could change any time and this needs to be accommodated in the contract and this is not easy. This is one of the reasons for Fixed price contracts not being popular in Agile projects. Even though there are several case studies of application on Agile projects but at the end of the day, the constraints imposed by Fixed Price model might actually destroy the agility.

Photo Courtesy: http://www.construx.com/Page.aspx?cid=1648

Time & Material(T & M) as the name implies is supposed to work well for Agile software development as it has no restriction on price or scope. The customer can keep paying as long as the value is getting delivered. However, my observation has been that this model works  well in an established trustworthy environment. 

Several experiments have been made in creating contracts specifically suited to Agile environments.  Some of them include:

1. Phased Delivery
2. Capacity Based
3. Value Based

Phased Delivery contracts divides the entire project life cycle into multiple different phases. A goal is set for each phase and funds are released based on the delivery. The goal could be the number of user stories to be delivered in each phase providing additional quality related info.

Capacity based contracts would provide X number of people for the project  and no scope related delivery constraints are signed.

I am also envisioning Value Based Delivery contract, and I am not sure if some one has experimented with this.  I feel that, either a $ value or some unit could be assigned to Epics or to user stories theme.  As and when this gets delivered, proportionate amount of fund could be released. Again, quality related matrices could be an additional parameter in the contract. 

An Agile practitioner  has put together a list of 10 styles on Agile contracts . check this link out for more details.

Summary
I strongly believe that  Trust and Contract are inversely proportional to each other. That is, as long as we have less trust, we need more contracts.

Copyright protected 2011