Certainty by Adaptive methods in Agile projects.

Bringing certainty to a project is one of the prime goals of project management. Conventionally, teams were relying on experts to predict the delivery. Experts provide estimates to plan and schedule and thus to bring certainty. It is very crucial particularly in a very dynamically changing market conditions. However, these predicted estimations by experts are merely as good as the expert himself. The predicted estimates from an expert comes with all the limitation of this expert himself. It is also true that the no expert could be smart enough to predict the outcome of a project in which is impacted by both internal and external factors like, changing requirements, changing team dynamics (particularly addition and removal of team members) and changing technical frameworks etc.

On the other hand, there is one more endeavor pursuing to bring certainty. Adaption in the place of prediction. Adaption is the process of learning from past and taking a suitable stance to avoid repeating the same mistake. Humanity evolved by Adaption. Every food in our table came to our table after trying many wrong things and inferring the right food.

Instead of relying on experts' predictions, the Agile teams follow Adaption by trying unknown things at the earliest and failing quickly to get feedback to learn. This Adaption needs iterative model to apply the learning before trying next requirement. It is crucial that teams take small steps at a time, to avoid lot of time in something they don't know. So they these iterations should be small. Hence Adaption process should be early, small and frequent to learn fast and evolve.

Conventional expert estimates and plans are done only once, during the initial phase of projects. But the Adaption enables the team to revisit the estimates and hence the plan, during each iteration, which is extremely suitable for a dynamically changing environment. More than that, when we enable teams to estimate their requirements, we can get more realistic, time sensitive, team specific estimates. Also, these adaptive estimations are valid only for that specific team, in that specific organization, during that specific phase of project,for that particular client only. Please note the expert's estimations are valid are considered universal.

Estimations by experts are done in person days, and the adaptive estimations are done in story points.

Project Management - Know your cocktail

There could be two prominent ways to deliver something. It could be 'delivering a piece of art'; like delivering Mona Lisa. Or it could be something like a successful war campaign; like Alexander the Great's conquest of the Known World.

There are two major subjects of discussion on knowledge. Empiricism and Rationalism. Empirical process control and analytic process control. The empirical knowledge comes from experience. Rationale comes from reason. Empirical knowledge evolves based on experience. Reason is derived from evidences.

Software development can be categorized into two major types in its simplest form. Delivering something new and delivering something out of experience. For example, a R&D module used to control a rocket module in space is something new. On the other hand, an Employee Management system can be developed utilizing the experience earned from similar projects executed earlier.

No software development project falls in either of these categories completely. The success of a project manager is in identifying the perfect combination of these process control methods to ensure delivering dynamics.
But, understanding the dynamics between these two schools of thoughts is crucial to make a perfect blend of process control which would deliver success.

Bugs – An agilist’s dilemma

The question is - ‘Is it ok to size bugs and consider it like any other story while calculating capacity, When bugs would be planned for successive sprints?’

When I entered in to a team recently I found them not sizing their bugs. But I personally thought that bugs should be sized. 
Why because,

• ·Those bugs are of huge effort
• Then only we can identify the actual effort
• ·Then only we can identify the capacity
• ·Then only we can ensure if all our metrics related to effort, capacity and normalized capacity are correct.

However I am not a purist. An purist- Agilist working on offshore model? Laughingstock.

Still, there is a limit and degree for compromises. So, I investigated and understood the reason why they are not sizing bugs.

• ·They claim credit for stories which are having MINOR defects with the approval of PO.
• ·Any defects reported at last few days of sprint are moved to next sprint without sizing.
• ·Both PO and SM are in agreement with Team to fix the issues without credit.

But, what I noticed was, somehow the team had forgotten that such a conditional compromise is accepted only for MINOR, last minutes bugs.

I am still working with this team to ensure that efforts beyond a degree should be sized.

But, beyond which degree? That’s something the team to decide and the PO to be in agreement.

What if they won’t do this? Then they will never know their capacity and normalization

      Ideally, the team should strive to deliver without defects.

An elevator pitch..

I got another opportunity for an elevator pitch. I could see this senior executive was a man of illustrations. So I chose to give an illustration on the classic questions. Agile Vs Waterfall.
I said -Waterfall projects are like making a table and agile projects are like growing a tree and got his attention immediately. I continued. 
When you decide to make a table you would prepare a design on paper before going to homedepot to get timber, nails and paint. Then you would follow the design to make the table. You have lot of experience in table making. It is under your control. There is no scope for this to grow beyond your design. There is no risk involved in this implementation as you have done this earlier.
On other hand, you don’t have an exact design to grow a tree. You can plan on which tree, which location etc. But the growth and yield of the tree is not in your hand. All you can do is to provide fertile land and selected seed and water and sun light. The tree will adapt to the environment by reaching for sunlight or by shedding leaves. Growing is a new activity every time. Your plans may not be fully implemented during the tree growing process.
Making a table is inorganic and growing a tree is organic.
Creating Software is not like making a table. You don’t create the same software repeatedly. Since the environment is dynamic the requirements may change at any point of time; like growing a tree.
We continued to discuss outside the elevator as well..

CSP Completed

Happy to share that I have completed my CSP . I t took four months to provide the evidences to Scrum alliances.
I presented a series of  tech talk  webex session  to NA associates which was really helpful to provide evidences to this certification.
It is important to have CSR activities like serving as a volunteer.
This certification also helped to put together my Scrum / Agile activities comprehensively.
Already sharing my certification experience with friends.

Velocity and support- maintenance projects.

I observed that the velocity in a support and maintenance project doesn’t go up as it happens in the development projects. Instead, after identifying its normalized capacity it generally stays on there.

However, it is true that the number of stories supported or value delivered increases over a period of time as team gathers more knowledge on technical/functional areas.

This is because,

·As the team gets more expertise on support incidents, they start to size the effort with less story points. For example a support activity that was sized to be 10 story points will be sized to be 5 after 3 months and 3 after 5 months. I can see this happening.

·The knowledge earned enables the team to repeat the support activity quickly and deliver more.

·However, as they understand the issue earlier, they tend to size the repeating activity with less story points.

Whereas, development projects don’t repeat the activity. Event the reusable components are planned with less story points. So the velocity in development projects generally goes up as the team gets more expertise.

Fixing the ToDo issue in Burndown chart

One of the most common mistakes a normalizing scrum team would do is – to neglect reducing the Todo.

It is important that the team would reduce Todo as they make progress in a sprint. This enables scrum master and product owner (and hence stake holders) to understand if the sprint is making progress or not.

We can monitor progress – status, using a burn down chart. Burndown should grow downwards (in a 45 degree slide) along with ideal line when team makes the estimated progress. It will start grow in a straight line, parallel to X coordinate (Time) when team misses to make progress. Sometimes, some delivering / progressing team also get flat line burndown as they miss to reduce ‘ToDo’.

So, it is an important task to a Scrum master (as an owner of monitoring role) to give feedback to team on this. But how to identify the tasks (or stories) where ToDo is not entered? Here is how:

Get the backlog (Of course, sprint backlog), and check for the following.

• Identify all the stories that are done, but still having ToDo remaining.
• Identify all the stories whose tasks are completed but the ToDo is not reset to zero.
• Most importantly, find all the stories where the ToDo and the estimated hours are same but the Done hours are entered.

Give this list of Taks, stories to your team asking to check if they can reset or reduce the ToDo, which will immediately reflect in better Burndown and hence will be projected as a delivering team.