Thursday, August 28, 2014

Fixed Price Contracts - Doing it Agile way

The basic principle of Agile Methodology is to develop product in small increments based on the regular feedback received at the end of each sprint (2-4 weeks). The feedback often results into change of requirement/new requirement, Agile processes harness change for the customer's competitive advantage. As the project’s scope can be of dynamic in nature, it is advisable to go for “Time and Material” type of contract. Unfortunately, due to several budget constraints clients may still want to opt for “Fixed Bid” one(by the way - Fixed price RFP's are a buyer's way of displaying his/her own company's internal weakness. As long as service providers continue to chase after these thorny bones the market will continue to find providers willing to sacrifice their people for the sake of meeting revenue targets). In “Fixed Price” type of contract – time, scope and cost remain constant.

So is it even possible to work in a fixed bid Agile mode?
If yes ,how to provide the estimates?

Once the Agile mindset and the thinking behind scrum is explained to the client, the need or demand for a fixed bid price is dropped in favor of the client, him being able to continuously “direct” the product. Though if it still has to be a fixed bid assignment, following are a few things that can be done to have an effective estimation:

- Move from fixed scope to fixed size/budget: Scope, time and costs are three constraints of the “Project Management Triangle” where one side of the triangle cannot be changed without affecting the others. To leverage Agile the triangle has to be tweaked to replace fixed scope by fixed size.

-Get the Product Backlog ready: List down the high level features, involve the PO and customer to refine them as user stories.
-Estimate the Backlog in terms of SP: Use Ranges to get an estimate, get the team involved for a couple of hours every day. So considering if the product backlog has 200 user stories,team can figure out a range,lets assume it as 1000-1200 SP.
-Estimate the cost to cover the SP: Based on team's past experience or by running a demo sprint , total SP covered in a sprint can be calculated(Velocity) .For example , a team's velocity is 30 SP in a 2 week sprint which is equal to 3 SP/day = 3SP/6hours=0.5 SP/hour. Dividing the calculated SP range by the SP/hour ,i.e. 1000/0.5(2000) - 1200/0.5(2400) . So the hour range comes to be 2000 Hours-2400 Hours . Multiply it by per hour billing ($Z)to get the estimated range of cost , i.e. 2000$Z - 2400$Z .
-MoSCoW Estimation : Use MoSCoW estimation (Must Have, Should Have, Could Have , Wont have) to bring the features under estimated cost , in case the cost is going over the fixed one.
-Exchange Model: Requirement changes to be handled carefully as it may affect the agreed cost. Prioritization should be done keeping the features (that may give real value to the customer) and the cost (it may incur to the project) in mind. The requirements can be dynamic in nature so the existing user story can be replaced by new ones of same size. It is also called as an “Exchange Model”. The overall size of the dynamic product backlog remains same however the Product Owner (PO) can introduce new user stories that are high on business values by exchanging them with the existing ones of the similar size.

Agile methodology is often considered as a misfit for fixed price contracts as the scope is perceived to be one of the constraint. With the help of this post we have just tried finding a few ways to deal with it , hope it helps. 


Monday, July 28, 2014

Agile - Scrum Implementation - Grass is certainly greener on your side

Moving from a traditional development life cycle to Agile is like quitting smoking, you know it is good for you but at times the temptation to fall back on the old ways is too strong. This article is mainly intended for newly minted Scrum Masters or for people who are looking forward to implement it effectively in their projects. Yes, a cursory glance with feedback from the Agile gurus and experts will also be appreciated. 

Agile Manifesto : 
Before we start , lets have a look at the Agile Manifesto . Following are the four main points of the manifesto
-Individuals and Interactions over processes and tools
-Working Software over comprehensive documentation
-Customer Collaboration over contract negotiation
-Responding to Change over following a plan

"That is , while there is value in the items on the right, we value the items on the left more"

These simple elegant looking words mentioned above can be deceptive in nature when it comes to practicing them,will explain the manifesto in detail later in the post.

By now,many of you may have perceived it as just another "shout it aloud Agile" post and probably would be thinking of utilizing your time in some better article. Probably something more flashy , creative , dynamic lauding author's prowess as a blogger.
But if you are still here ,  following could be the reasons:
-Your willingness to know the Subject -Agile-Scrum Implementation
-Your willingness to implement it
-If already implemented the your willingness to correct it

I am not sure about  what kind of management support , or what kind of knowledge your team has for Agile-Scrum implementation  , however the good part is you have the will, right intentions to embrace the change and the best part is probably you don't have the in house skills and support on it.
The challenges that you face now while implementing Agile-Scrum in your new project would help you to understand some key concepts that people with experience and expertise on it often fail to.

As per my knowledge and experience following should be the order of Implementation :
-Get your Product Backlog ready : Arrange the requirements in the form of user stories with the priority ones on the top .This will give you an idea about first things first, you can either use excel or any open source/ low budget test management tool for it.
-Set up the sprint length (2-4 weeks) : Sprint length is dependent on agility of the team, frequency of changes and the technical complexity of the project. There is no hard and fast rule for choosing one , however the chosen one should remain same for the entire release.
-Start with basic formal Scrum ceremonies i.e.Sprint Planning, Stand Up , Sprint Review and Sprint Retrospective , you may perform the ones like Estimation and Sizing and Backlog refinement informally for now. Once you get a hang of things , you can start performing the other ones formally too.
-Get a certified Scrum coach or master involved to train the Scrum team, facilitate the ceremonies and maximize the productivity by taking care of Unforeseen impediments.However if the option is just not viable , you may go through some very helpful videos/articles that are readily available over internet.
-Plan your sprint once the refined Product backlog is ready ,by pulling the priority items from the Product backlog to the Sprint backlog. Please keep in mind one very important fundamental of Agile Manifesto while planning the sprint - "Working Software over comprehensive documentation " . Plan your sprint in a such a way that you have something to demo to the Product Owner and other stake holders at the end of the Sprint in Sprint Review Meeting .
-Stand up Meetings :Once you have the Sprint backlog ready , please start the Sprint.Use daily Stand up Meetings to check the health of the sprint and discuss impediments if any.Involve the Product Owner in it so that the team can clarify any doubts. Please keep in mind important fundamental of Agile Manifesto-"Individual and Interactions over processes and tools" . If you are not using any tool please use a white board as your team's Collaboration Hub. Mark up five columns on it - Sprint Backlog, Tasks to Do, Work in Progress, QA Ready and Done. Use Post it stickies describing the requirements on the white board.Apart from it Use daily Burndown Chart to track the progress.
Many projects that have elaborate project plans with detailed Gantt charts have failed. We make the plans so complex and detailed that they're difficult to modify when changes occur. Agile process replaces project plans with release schedules and burn-down charts that can accommodate change. Another Agile Manifesto fundamental comes into picture here- "Responding to change over following a plan"
- Use Sprint Review Meeting to showcase what you have accomplished during the sprint. Typically this takes the form of a demo of the new features. Feedback from the customer and all the other stakeholders are taken . Agile welcomes changing requirements , even late in development. Agile process harness change for the customer's competitive advantage. We practice "Customer Collaboration over contract negotiation " principle of Agile Manifesto here.
- Use Sprint Retrospective to find ways to improve in future sprints.

There is so much to write on Scrum Implementation , I hope the above points can at least get you started on it or if already started can help you in improving the things.One last thing that i would like to caution you against is the temptation that may arise to fall back on to half agile/waterfall kind of methodology due to initial Sprint failures. Congratulate yourself if your initial 1-2 sprint fails as those failures would eventually prove to be the stepping stones of the grand success lying in the bright future.
You may think grass is greener on the other side but if you take the time and put the efforts to water your own grass, it would be as greener.

Monday, July 21, 2014

Futurespective - Predicting the Unpredectible

Apart from the regular Scrum ceremonies - Sprint Planning and Commitment, Daily Stand up, Sprint Review and Sprint Retrospective , a new one has emerged that has proved to be quite effective for ensuring higher productivity across the future sprints.

Futurespective - It is a powerful technique that uses the concepts of Retrospective to make the future better. The idea is simple. Think of your new project and mentally take the team to the final deadline. Assume the project has been a miserable failure, brainstorm about what happened on the project to make it fail thinking of People, Organization, Systems, Processes, Facilities and Logistics and put all ideas up on a flip chart. Now look at all of the things that have been written down as a team. Ask them to vote to determine which of these are starting to happen (e.g. poor communications with Product Owner) in the current project. At the end of the session you'll have a list of priority actions that you should take now to resolve the problems that haven't happened yet. It is like taking a mythical Sprint Plan and then thinking of ways to make it fail.
During this exercise team asks themselves two questions:
 Assume this Sprint is a complete failure, and based on what we've committed to deliver, what are we going to do on this Sprint to make that happen?
 What actions can we take now to stop that happening and make our Sprint successful

Future-spectives help the team to establish practices and collaboration patterns early on that transforms a group of individuals to a real team faster.
This is more of a forward approach than backwards , it is more positive where the team can work together in advance to avoid problems. As a result the team feels more in control and is far more likely to put ideas into actions.