Ruminating on Agile estimates

Over the past few years, we have been using story points for estimation, rather than using man-hours.
For a quick introduction of agile estimation, please peruse the following links that give a good overview.

https://rubygarage.org/blog/how-to-estimate-with-story-points
https://rubygarage.org/blog/how-to-estimate-project-cost
https://rubygarage.org/blog/3-reasons-to-estimate-with-story-points

But still folks struggle to understand the advantages of estimating by story points. During the planning poker session, all team members discuss each story point and arrive at the story points through consensus. Thus each team member has skin in the game and is involved in the estimation process.

The time needed to complete a story point will vary based on a developer’s level of experience, but the amount of work is correctly estimated using story points.

IMHO, velocity should be calculated only after 2-3 sprints. This average velocity (#story-points/sprint) can be used to estimate the calendar timelines for the project.

Managing Database Versions in an Agile Project

Today we have a robust set of tools for code versioning, CI and release management - for e.g. Java, .NET, Ruby web or REST applications. Examples of tools are Github, Hudson, Jetkins, etc.

But what about the RDBMS? How do we manage it across the various environments - i.e. from development to integration to UAT to production. A good illustration of the typical challenges is given here.

Flyway is a tool to address these problems. Using simple techniques such as a schema-version table and automatically apply db scripts (that follow a naming convention for sequence tracking), the tool can help any Agile project in managing RDBMS instances across different environments. It would also be a nifty addition to your existing DevOps tools. 

Advantage of using Story Points instead of hours

Using story points for estimating user-stories in helpful because it encourages us to use 'relative sizing' and estimating the 'size of work' and not the real effort required.

Mike Cohn has given a good analogy by relating this concept to running a trail. Two people can agree on the fact that the trail is 5 miles long, but one may take 30 mins and the other may take 45 mins.

During the Planning Poker game, each developer is given cards with numbers 1,2,3,5,8 on them. Then the Scrum Master and Product Owner take the effort sizing from all developers to arrive at a consensus.

The Fibonacci scale is quite popular for estimating the user-story or epic size, as there is sufficient difference between the numbers to prevent confusion. For e.g. If the scale is sequential, then there would be a debate around sizing of 6 or 7 or 8. But a Fibonacci scale, makes it easy to relative sizing. 

Do we need a dedicated Scrum Master?

The need for a full-time Scrum Master is often a topic of hot debate in many Agile projects. Based on the numerous agile projects that we have successfully executed, I would give the following recommendations -

• If your team is adopting SCRUM for the first time, then it is better to have a full-time Scrum Master. He would be responsible for ensuring that all agile processes are followed and everyone understands the rules of the game. The Scrum Master essentially acts as an evangelist educating teams on all aspects on SCRUM.
• Once the teams have become comfortable with SCRUM processes, then we can have a part-time Scrum Master. IMHO, the technical architect or tech lead is most suited to play this role.
• One of the main functions of a Scrum Master is to remove all impediments that the team faces. To be successful in this role, you need someone who can understand the technical complexities, business drivers and has a good rapport with the product owner. Hence architects are a good fit for the role of a Scrum Master. 
• The Scrum Master also facilitates the daily Scrum and weekly Scrum of Scrums to facilitate collaboration across teams. He also leads the retrospectives and facilitates combined learning. 

Ruminating on the timelessness of the Agile Manifesto

I had signed the Agile Manifesto a decade back (in 2005) and was amazed to realize, how relevant the principle tenets are even today!

It is imperative for any software development project to imbibe the following principles to succeed -

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Applying the Start-Stop-Continue paradigm to Sprint Retrospective

We all know the importance of Retrospective meetings after a Sprint. This is an excellent time to reflect on what worked, what did not work and what areas need improvement.

A simple way to conduct a retrospective with the entire team is to follow the Start-Stop-Continue model. You ask each team member to articulate -

• what according to him/her should we start doing, 
• what should we stop doing and 
• what should we continue doing (with some changes if required). 

Then after collecting everyone's views, the team should brainstorm and debate around all the ideas presented and select the top 3 or 5 ideas that they would implement in the next sprint.

Many teams start skipping the retrospective if their project is running smoothly, but it is important to remember that there is always scope for improvement, no matter how good your team is currently functioning. 

Ruminating on Agile and Fixed Price Contracts

Fixed Price Contracts have become a necessary evil for all agile practitioners to deal with. Over the last few years, I am seeing more and more projects being awarded based on fixed-bid contracts. In a fixed price contract, 3 things are fixed - time, scope and price.

The dangers on fixed price contracts are known to all. But still customers want to go with fixed price because they want to reduce financial risk, choose a vendor based on price, support annual budgeting, etc.

But unfortunately fixed bid contracts have the highest risk of failure. In fact Martin Fowler calls it the 'Fixed Scope Mirage'. Martin suggests using Fixed Price, but keeping the scope negotiable. He calls out an real life case study that worked for him.

In this article, Scott Amber raises questions on the ethics behind fixed price contracts and also elaborates on the dire consequences of it. I have personally seen tens of projects compromising on quality to meet the unrealistic deadlines of fixed price projects. The same story gets repeated again and again - Project slips and pressure is put on developers to still deliver on time and on budget. They begin to cut corners, and quality is the first victim.

This InfoQ article gives some ideas on how to structure Agile fixed-bid contracts.Cognizant has another idea put on a thought-paper called as 60/40/20 that can be used on Agile projects.

IMHO, any kind of fixed price contact would only work if there is a good degree of trust between the customer and the IT vendor. One of the fundamental principles of the Agile manifesto is to "Put customer collaboration before contract negotiation".

Agile Survey

VersionOne has released the results of the survey it conducted on Agile practices in the industry. The report is available at: http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf

Quite an interesting read and worth a perusal.