Scrum

Webinar: How to Scale Agile using SAFe Framework

Scrum and XP have been working well for small teams. That works fabulously for small organizations. However implementing the same for large project portfolios, having teams with 100+ developers has remained very challenging from organization perspective.

There are many challenges while working with large teams like:

Breaking silos/departments in large organizations
Requirements focused on changes in enterprise architecture
Ability to work on highest business value features for program portfolio instead of for a project
Eliminate waste and reduce cycle time for the whole value chain
..and more

They can be mitigated by seeing scrum as organization design framework and using lean principles. In this session Shrikant will share his thoughts on how Scaled Agile Framework (SAFe) is used to solve this problem. We will take references from Spotify Scaling Case Study, SAFe and personal experiences.

Date: Feb 19th, 3:00 – 4:00 PM IST

Register Now!

How To Do Effective Capacity Planning on The Scrum Team

by Avienaash Shiralige 11 Comments

During sprint planning, scrum teams often face this challenge of sprint commitments. How many stories can we commit in this sprint? How to plan for the team capacity?

I ask teams to do commitment driven planning during early stages of scrum adoption. For you to commit to a sprint goal, you need to know current team capacity. Team capacity is calculated as per people availability in that sprint.

Let’s take an example.

Sustainable Pace: Does Culture Play Any Role At All ?

by Avienaash Shiralige 11 Comments

Striving to bring agility into the organisation to adapt to changing business conditions is leading people to lose sleep and stretch more than before in some organisations. Agile thought leaders definitely envisioned this and hence recognised sustainability as one of the agile principles.

[pullquote] Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. [/pullquote]

To run a long distance you need to find a sustainable pace. But often, companies just don’t get this due to various reasons like:

Pressure from business and management to get most work from least people
Team not having an option to make their own decisions – command and control culture
Teams inability to say NO for non-realistic goals. Service industry firms – they just can’t say NO to unreasonable client demands
Utilisation of people – Planning for 100% utilisation. This makes people work for more than required hours and hence getting burnout
Unable to remove distractions to the team. Lot of unplanned, non-essential meetings taking people’s time. Questioning motives and saying NO is essential here.
Allocating people on multiple projects with allocation distributed 20%,50%,30% etc. This does not work in reality. There is a switching time between two tasks and people take around 15 mins to achieve FLOW (high productive zone)

Metrics to Build Great Agile Teams: Measure Influence, Not Control

by Avienaash Shiralige 17 Comments

Couple of weeks back, I noticed an incident that triggered this post. Senior Management in a company applauded people for showing individual heroics on the project.

Some of them were:

Staying late in office to address a client request?
Responding to project emails at late night..
Rewarding testers on number of bugs found and more.

And then, managers shared this privately with rest of the organisation too. Treating this as accepted, rewarding behaviour invited more such incidents and frustrated many of those who don’t do this. Below comic strip summarises it well.

“You Will Get What You Measure(or Reward)!”

I recently heard an another incident of how testing team kept an very important bug under the carpet before bringing it up just a week before release, and then getting rewards for the same. Such behaviours more likely are the candidates for root cause analysis than rewards.

Story Points and Man Hours – When To Use Them and Why?

by Avienaash Shiralige 4 Comments

The debate about why story points why not time goes on wherever I go for conducting coaching workshops. Hence I thought of sharing few more thoughts today.

Previously we had sizing techniques like Function Point Analysis, but it was tough to understand/implement by everyone and hence was restricted to experts ONLY. But estimation is an activity to be done by people who are going to work on it. Hence a simpler sizing technique was needed so that everyone(developers, testers) can understand and use it easily.

Story points is a very powerful sizing technique. It has various advantages as I mentioned in my earlier articles.

Story points estimation using planning poker which is based on Wideband Delphi method helps to arrive at consensus based estimates using collective intelligence – Wisdom of the Crowds.