Limitation of existing Kanban Metrics.

Throughput, Story Lead and Cycle Time are the frequently used Kanban metrics. These were defined for deliverable of same size and equal priority. But a software support team deals with incidents of different size and variable priorities. Hence, Kanban metrics collected without considering these factors (Size and priority) don’t deliver the purpose.
Illustration for cycle time and size of delivery: "Cycle time" is the time it takes to complete the production of one unit from start to finish. However, software support teams don’t have the luxury of working on issues of same size, unlike the mechanical production lines.
For example,
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents then the average cycle time is 2.
Day 2:
Again, the Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 medium incidents; even then the average cycle time is 2.
Now, the production line has spent equal amount of effort on both the days and has delivered equal value; and the metrics shows it correctly. On the other hand, the support team has spent more effort and has delivered higher value on the second day. But the metrics shows the same number, and hence it is not adequate to reflect the value delivered.
Solution: Normalizing the size of the incident could be a solution which is practically impossible. So, we can provide weightage to the incidents.
To illustrate:
Day 1:
Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time a support team takes 8 hours to deliver 4 small incidents. Weightage for small incidents are 1. Hence 8/(4*1) = 2 is the average cycle time.
Day 2 :
The second days, Production line takes 5 hours to assemble a machine then the cycle time is 5.
At the same time, a support team takes 8 hours to deliver 4 medium incidents. Weightage for medium sized incidents are 2. Hence 8/(4*2) = 1 is the average cycle time.
This reduction in the cycle time shows the higher productivity. This is a dependable metrics.
Illustration for lead time and priority: "Lead time" is the time it takes for one unit to make its way through operation from taking the order to delivery. This definition assumes that all deliverable are of same priority. However, the software support works on priority. And we ‘park’ the low priority incidents when relatively higher priority come into the queue.
So, to illustrate,
Consider three incidents A, B and C and all are of same size and came to the backlog at same time.
A came to the queue first and was delivered in 3 hours. Lead time for A is 3 hours.
B is of low priority where C comes with high priority. Hence, we park B and take C next to deliver in 3 hours. Now the lead time for C is 6 Hours. Now, B is brought from parking to delivery queue. Which has a waiting time of 6 hours. Now B is delivered in 3 hours. Hence the Lead time for B is 9 Hours.
Now, we should be able to distinguish the time spent in backlog and the time spent in parking. Because the lead time is going to be used in discussing the backlog health.
So, the time spent in parking should be offset, so that we would be able to see the correct scenario. In the example above,
Lead time for A – 3 hours.
Lead time for B is 9 – 3 (parking hours) = 6 hours
Lead time for C is 6 Hours.
Conclusion:
Hence, for both cycle time and Lead time, the time spent in parking should be deducted before calculation.
And for cycle time the incidents should be given weightage before calculating the cycle time.

Tracer bullets and SIT.

Agile teams deliver smaller slices of deliverable to avert the big bang releases and failure. Also, by delivering iterative, we are getting frequent feedback. Here are the important questions related to this.

• ·        How to perform system integration testing? Whether we need to keep the integration testing as a part of scrum team or as a separate team?
• ·         As we plan to deliver frequently, are we going to perform SIT for each small slice of functionality?

Since the agile teams deliver only a slice of the feature, sometime the suitability of this code in the overall architecture is not validated; until a complete regression on system integration is done and certified.

To avoid such delay, we shall implement tracer bullets. Here is my blog talking about the difference between tracer bullet, POC and prototypes.

http://myagiledays.blogspot.com/2014/12/tracer-bullet-and-more.html

Tracer bullet is a skeleton implementation of a feature which spans across the architecture. It might just be a very narrow implementation of the functionality but is not throw away code. It is of production quality and rest of the iterations can build on this code.

Tracer bullet ideally should cover all the major data flow paths in the technical architecture to perform the basic ask in the user story. The design thinking should ensure (Ideally) that SIT should done once for tracer bullet and once again after implementing other functional asks.

This way, we would be performing system integration when we test tracer bullet and we will validate functional integration when we perform remaining sprints deliveries.

Passive Resistance – An Agile coach’s nightmare.

People resist changes. There are different types of resistance caused by different reasons. I wouldn’t generalize that the resistance is evil. There could be valid reasons and some of the reasons can be very healthy too.

However, passive resistance, irrespective of its validity or reason, could be extremely difficult to be dealt with; for any leadership, particularly for an Agile Transformation leader. Here are the few important reasons for passive resistance and possible mitigation.

Awareness: I would like to believe, at least initially, that people resist because of the lack of awareness. But, most of the resistance caused by awareness issues would be expressed explicitly. That’s a blessing in disguise. Still the coach should bring details and hence awareness to the environment, if a transformation would not deliver expected values. It is not uncommon that people stepping forward and asking more questions after such a second wave of awareness sessions.

Hence, lack of awareness may trigger immediate, explicit response as resistance which can addressed by discussion and negotiation. When silently resisted, it would be observed from the outcomes of transformation. When the coach finds the transformation endeavors are not effective in result, he/she should try bringing more awareness to the team.

Acceptance without agreement: Since, agile transformation is a culture change, it normally comes with a lots of support from executive Leadership. So, it generally gets accepted by the team but there could be team members who don’t agree on the principles and values of Agile transformation. The risk is, such acceptance would prevent the free flow of opinion and would prevent the feedback from surfacing. It is extremely crucial that the team and leader get seamless feedback; after all, visibility is a core value of Agility.

The mitigation is:  the transformation leader should be capable of influencing team without authority. By being a servant leader, the Coach should ensure that the team is aware of the reason, execution and the results of agile transformation. He also ensure that the ceremonies and tools would ensure that the transformation is a matter of moving from hierarchy to a flat organization, to enable visibility across the organization. Such visibility will encourage people to get clarified by raising their concerns.

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.

Tracer bullet and more..

A tracer bullet is not a prototype. Why?
Because,
•A prototype is not deployed in production
•A prototype is not 'working software'.

A tracer bullet is not a POC. Why?
Because
•A POC may not be implementing a feature end to end.
•A POC is not a skeleton of an Epic.
•A POC may not be implementing any functionality

A tracer bullet is not a Sashimi. Why?
Because,
A Tracer bullet is a spike (time boxed) but a sashimi is a collection of (one or few) user stories that implement a thin version of a functionality.

Tracer Bullet is a Spike but a Spike may not be a tracer bullet. Why?
Because:
A spike may not deliver deploy-able value in all the cases. For example, a spike on environment compatibility study may not deliver any ship-able increment. But the knowledge acquired on this process would be the outcome of spike.

Y axis of Burndown chart

I have been interviewing scrum masters. After talking to 25+ candidates, this question still waits to get answered correctly.

What is the difference between release Burndown and sprint Burndown.

I ask this question differently, primarily to identify if the candidate is googling live.

I usually ask - what do you see in the y axis of Release Burndown and what do see in the y axis of Sprint Burndown chart?

Answers for those who are learning now: In Y axis, Sprint burn down has hours todo. Release burndown has story points todo. Should there be a burndown for CXOs, it would have SWAG (todo) of the features in Y axis.

It is always 'Time' ( days, releases or Qts) in X axis.

Mischievous cat of an elderly Guru or Cargo cult science

It is the story of a ‘Gurukul’ (school) that followed traditions religiously. 

This elderly Guru found his pet cat annoying - interfering their daily prayers. So he ordered the pupil’s leader to put that cat on leash, during prayer hours. Guru passed away on a breezy evening. They found his cat, dead under his bed. 

Then the pupil’s leader became Guru. On his first prayer, he looked around and ordered his students to go find a cat, as he needed a cat be tied in the third pillar of long corridor that goes to garden; to start his daily prayer.

The moral is, traditions are meaningless when they don’t deliver value.

Some teams don’t talk anything outside those three subjects during scrum.

“What did I do yesterday?”
“What will I do today?”
And “the impediments!”

When I noticed something missing on a scrum and checked the team member if he discussed the release plan for next week; the reply was ‘I will do it on Friday’. What if the deployment POC would be OOO on Friday?

So, there is no need to limit within three heads. Encourage your teams to talk everything to meet the delivery timeline. ‘Three heads’ is just a starting point for collaboration and we should talk as much as possible to deliver the deploy-able increment; ensure that won’t we end up making it a status report.

Agile provides developers..

Freedom to estimate: You estimate and you deliver. No need to work on someone else’s estimate.

Freedom to explain: One of the toughest tasks of a developer is to explain the delay to managers. Many a times, developer wouldn’t have any evidence to show that she/he has tried different options and the task still remains to be a research item. Agile provides means (VersionOne, JIRA) to track what was being done. After spending all the estimated hours, you will still be able to add ‘ToDo’ if really required.

Freedom to schedule: Generally, developers will be taking tasks one after another working closely with Leads till the project would be completed. But, agile lets developers to plan upfront. Developers will be able to plan their personal time accordingly. If a developer likes to take two weeks of vacation, he can own stories appropriately and deliver such that the others work wouldn’t be impacted.

Freedom to Speak: Developer has an opportunity to speak up every day (in case of scrum). If a developer thinks that the sprint zero was not done well then she/he can start a discussion on day one, instead of storing the work on his desktop and losing them in a crash after weeks. 

Benefits of listening: Conventionally, the collaboration was a role being played by leads. Agile multiples the chances for successful collaboration as everyone has the freedom / opportunity interact. Developers directly interact with another who has done a task similar to what he would try to start, and achieve it in very less time by collaboration. Earlier leads had to check with other modules and bind people together.

Work on a project- Not a module: When a developer start hearing what others do in a project every day, she/he gets a holistic view and minimizes the integration defects. His knowledge on different modules helps to grow a healthy cross functional group (which actually is a ‘Team’) instead of developers working in silos.

In general, Agile enables people to work as a team, and makes the issues very visible so that teams can work towards a solution. Agile is not a solution for practical issues teams may have; but it helps to identify issues, really visible.

NB : I use scrum and my views above are associated with that

The 6th Principle.

"Face-to-face conversation is the best form of communication (co-location)" 
– That is the sixthof 12 principles upon which the agile manifesto was proclaimed. 

We, the Agilists of Eastern Iowa Agile, a meet up group, gather regularly in Cedar Rapids. During the last meeting at Kirkwood College, we had Richard Lawrence of ‘Agile for all’ (http://www.agileforall.com/ ) delivering for us.
It was an interesting workshop with no presentations. The entire gathering took part in opining and realizing the values of agile principle. As an interesting exercise, we were asked to pick most favorite 3 from 12 Agile principles. And we were discussing the pros and cons. But later at the end, we noticed for everyone’s surprise, no one had picked the 7th principle. Then Rick concluded that this should be actually obsolete today and the communication media should have replaced the need to meet face to face. A ground breaking manifesto of 2001 becomes obsolete in 2014.

But, I think a Taskboard full of activities should certainly make a difference in the mid set of teams to bring a healthy competition and would help the team members to understand their contribution in overall delivery, no matter they meet face to face or not. My team is well distributed across the US geography and we ensure that Task board is shared by all of us in scrum, every day. 

Because the HR theories of T-groups are still there in books and are found fruitful. So, the truth should be standing tall somewhere between Yes and No. May be…

Velocity – Significance of averaging.

As I was splitting the remaining/partially done stories to the next sprint I wondered what would happen to the story points. Because the task estimates are getting split and carried forward whereas the story point remains the same for both the sprints. 

Further, if a sprint is going to accumulate a few heavy stories from previous sprints and get credited in the current sprint then what would happen to the velocity? So, 

•It is important to consider the average velocity when you take a shot on SWAG.
•Story points completed in a sprint may not reflect the effectiveness of a sprint.

Story Points Vs Task Hours

Which one should be appropriate for capacity planning? Story Point or Task Hours. That was an interesting question raised by my client Manager when he was trying to get more resources to the team. 

My Answer was ‘Task Hours’. 

Story point in case of ‘capacity planning’ and Task hours if you are resource planning. Here is my justification: Story point is an unit that so specific to that team, organically evolved, normalized within the team. Whereas, the Task hours could be universal. I added, the story point unit signifies the ‘Unit of work, that could be ‘DONE’ by our team, using our technology, for our problems, within our time-box in our company during last few sprints’. 

Should he been planning for the current team I would have told him ‘story point’. But he was asking about the ‘future’ team, which had not yet taken part in determining the team’s story point units. Rather, he should have asked me ‘Which one should be appropriate for resource planning? Story Point or Task Hours’ I gently hinted that to him.

The Staging Sprint.

Well, you will find no google result for ‘Staging sprint’ related to agile. Because, I just named it couple of days back, when a client manager asked me what I would call this. I actually said ’Parking sprint..mmmm, Lets say Staging sprint’.

Yes, Staging sprint is the sprint where I park all the stories that would be handled in the NEXT sprint, every sprint. This enables me to,
• • Classify the stories for the next sprint. ( Earlier I used to navigate the backlog and hand pick them.. laborious)
  • Track the size ; so that I can say immediately, when to stop adding stories for next sprint (given that you know your velocity).

So, to conclude: the staging sprint is a sprint with no end date in which we will accumulate stories during a sprint, and move all the stories to the next sprint, while planning for a next sprint.

To illustrate, in a team that has monthly sprint, we collect stories to the staging sprint all along the month of March; and move all these stories to April sprint during sprint planning. It is true that team may choose to push a few stories back to Back log or to Staging sprint. Ie, team will keep a story in backlog if that story has a dependency or blocked OR move to staging sprint if that story could be handled in the month of May.

It was immediately adopted in other teams and being practiced.