Use of Operations Research to plan optimal capacity for a Kanban team

Imagine you are responsible for setting up a new Kanban team to develop a piece of software. You have the following contextual background while forming the team

• Requirements are progressively elaborated and you expect on an average 3 new feature requests per day adding to the "To Do" list
• New requirements are likely to follow a Poisson distribution. ~ Pois(3) 
• Since new feature arrival follows a Poisson distribution, naturally the inter-arrival time will follow an exponential distribution
• The feature development distribution would mimic the inter arrival time and follow an exponential distribution as well (i.e in Kanban model, you move the card from "To Do" to "in progress" as soon as you are free to take up the card)
• You have flexibility to change the team staffing to increase or decrease the average service time

Problem Statement:

What is the optimal feature development "capacity" you should plan for to minimize the time between a feature arriving in "To Do" list and moving on to "In Progress" list (i.e. The "Wait time" for a feature). 

Solution - 1:

The following points are evident through application of common sense / gut feel

• The minimum capacity should be an avg 3 features per day ( same as "feature arrival rate"), otherwise the "To Do" list (or backlog) will grow on to inifinity
• There is cost associated with increasing capacity. We need to make a trade off between minimizing the wait time in "To Do" bucket and limiting the cost development to an acceptable level
• May be we can pick a capacity anywhere between 5 or 6 features per day

Solution -2: Application of Operations Research \ Queuing Models

The above scenario reflects an M/M/1 queue model. i.e

• Arrival rate follows Poisson distribution
• service rate (= Feature development rate in our case) follows exponential distribution
• Single server (one Kanban team in this case)

average wait time in an M/M/1 queue (refer to this paper) 

                                                                = (Arrival rate)/ service rate * (service rate - arrival rate)

in our case, arrival rate is = 3 features per day. We have option to vary the service rate (= # how many features can be developed in a day) by changing the team staffing. Given below is a plot of the Wait time as a function of service rate (= feature development rate)

The following points can be inferred from the above plot

1. We must plan for capacity to develop >3 features per day, otherwise the wait time in "To Do" list can grow for ever
2. Having a capacity to develop higher than 7 features per day gives diminishing returns. Having a capacity to develop 7 features may just be good enough

To Summarize, most of the functional managers, team leaders use their gut feel (Solution #1 above) to do capacity planning. In most of the situation, the gut feel gives us good enough results. However there are certain critical situations where the business impact is so high that we require a more scientific approach to base our decisions. As we demonstrated above in solution #2, the appropriate Queuing model can be applied to make more informed decisions. 

Agile tour pune - 2011

I delivered a talk on "Scaling agility" in the enterprise at Agile Tour 2011 @Pune. It was a great experience addressing some 70 odd agile enthusiasts, including some renowned thought leaders in the industry.


The talk aimed to answer the following questions:

- What are the typical challenges faced by enterprises while scaling agility (slides 8 ~ 12)
- Why we can not leave it to self organizing teams to manage scaling of agility (slide 14)
- What values the agile leaders should espouse for successful scaling of agility, in the form of a manifesto (slides 15-28)

Scaling agility - Story of a chicken

View more presentations from Lalatendu Das

Any suggestion or feedback to further improve the content will be appreciated.

A Chicken's manifesto for scaling agility

In agile Scrum parlance, the term 'Chicken' refers to those who are involved (but not committed) in the project and stand to benefit from it. Examples: Managers, Leaders, Coaches, Sponsors etc.

In a typical Scrum team, the role of Chicken is somewhat marginalized, at times to the extent of being derogatory. However as organizations Scale agility from doing individual pilot projects to enterprise wide Agile adoption, the role of Chickens assumes significant importance. A thoughtful organizational change management by the Chickens, can be the differentiating factor between success and failure.

Introducing 'A chickens manifesto for scaling agility':
-----------------------------------------------------------------------------------------------------------------------

"As responsible agile practitioners, we are optimizing the value delivered  through agile software development by adopting innovative practices. In addition to the manifesto for agile software development, we have come to value:

attitude over skill

adaptability over predictability

effectiveness over efficiency

optimizing the whole over improvement in parts

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

-----------------------------------------------------------------------------------------------------------------------

I picked these values based on my own experience of scaling agility from a small team to be an enterprise wide phenomenon. Keeping your agile adoption journey in context, do you identify with the above mentioned? Do you have any other useful values to add?

Please leave a comment.

Best Practices for Agile Managers

Agile Managers! Sounds like an Oxymoron?

In reality, there are organizations which have functional or product manager roles which do not fit under the traditional roles defined by agile methods. Jurgen Appelo started a thread (on his blog) to capture the best practices for a newly minted agile manager.

Here is what I think (as interpreted from the Agile principles)..please add on if I missed anything important

An agile manager should:

• Focus on optimizing the "business value" being delivered by the agile team. You may decide on your own metrics for business value (qualitative, quantitative or gut feel), but key is to have a sense ..at all times
• Pursue delivery of a fully working software at end of each sprint
• Periodically (pick your own frequency) Review and optimize the 'Done' list
• Identify key stakeholders and ensure their participation (as required) during the entire project life cycle
• Set expectations clearly (with all stakeholders), manage expectations to avoid last minute surprises
• Make an genuine effort to understand all aspects of the project (example: if you are not technical, don't avoid the architecture all together, try to gather just enough understanding)
• Set up information radiators (to convey real time information to all stakeholders)
• Focus on attaining a sustainable velocity quickly and early in the project life-cycle (it helps in planning and avoids burn outs)
• Watch out for 'Smells' (things which might be an impediment to agile practices

Last but not the least, an agile manager should demonstrate thought leadership and show genuine concern for professional growth of each member of the team. It's essential for the agile manager to win the respect of the team. You would always be better of by being a 'Leader' rather than a 'Manager'

Myths of agility

In the context of Software development, the term “agility” is widely misunderstood. Even many seasoned software engineers associate agility with complex process changes to adopt ‘Agile’ methods such as XP, SCRUM, DSDM, FDD and Crystal etc. But in reality, this specious association can’t be any farther from the truth. Before you join the ‘Agile’ bandwagon and start reading a XP or SCRUM book, it is essential for you to understand the fine line between ‘Agile methods’ and being ‘agile’.

Being ‘agile’ is a state where your organization is completely adaptive to changing environment. You are driven by business value. Your entire infrastructure, not just IT department but also other business functions such as sales, marketing, finance, production, procurement etc look to maximize the business value generated for the organizations. All it requires certain level of maturity in the way you work, nothing else matters. In the context of Software development, you can adopt any methodology you like (yes, even waterfall, RUP) as long as you focus on a) maximizing “Business value” instead of “through-put” b) being “Adaptive” instead of being “Predictive” c) and Continuous sustainable improvement. All that ‘Agile’ methods do, is to enable some of the aforesaid attributes a bit more than any other traditional methods (such as Waterfall, RUP etc).

Looking from a holistic perspective, being agile is the end goal of all organization and adopting an ‘Agile’ method (for that matter any other software development method) is just a mean to achieve the end goal. However it’s unfortunate to see many organizations blindly adopt XP or Scrum process without giving sufficient thoughts to the values required to make an organization truly agile. It is, therefore obvious that such changes fail over long run.

If you care for being agile, have a look at the Principles behind agile methods. Have a open discussion within your team to determine what each principle means to you as a group. Look at your existing processes and see if they adhere to these principles (fully or partially). Start working on those processes which needs refinement. Change if you must, but only after fully grasping what change means to the overall organization. Rest assured you will ensure a successful and sustainable process change towards being truly agile.

When Agile becomes Anarchy

I have seen successful agile teams innovating on process front..and quite successfully so. While I am in favor of such evolution in Agile ecosystem, what bothers me is the resulting lack of discipline.

One of our high performing project teams has successfully implemented Kanban processes into Scrum framework, but to my surprise, in the process the team has lost focus on some key agile processes. For example, there is neither any sprint commitment (Scrum CTQ*) nor any limit on WIP items of each workflow state (Kanban CTQ*). While the team continues to measure sprint velocity, the complete lack of predictability is equally puzzling (i.e Avg Sprint velocity assumed to be 40 SP**, where as, for last number of quarters team is consistently maintaining a higher velocity). To the credit of this particular project team, it's successful in meeting sponsor expectations (The process works!?..so it seems.)

While some teams can get away with such transient process implementation (like the aforesaid team), in order to be successful over a long run, I would strongly recommend to bring in process rigor.

Agile is already lean on processes, but it requires a disciplined approach towards maximizing value from it's limited set of processes. Keeping with the ethos of 'Inspect and Adapt' if you plan to change any of the existing processes, consider this simple approach:

• Make sure the process changes doesn't break any of the agile values or practices
• As a project team, discuss and agree on the new set of processes to be adopted (if possible share with others as well - make it public)
• As a team commit to the new processes with utmost discipline

Agile without discipline would result in Anarchy.
It may work for you today but you can never be sure how it turns up tomorrow.

Thoughts? Reactions?

*CTQ - Critical To Quality
**SP - Story Points

The Agilists - Facebook Group

I have created a Facebook group (what is it?) named 'The Agilists'. As the name suggests, this forum is dedicated to foster collaboration among all agile practitioners (starting with those in my network).

If you are an agile practitioner or just interested to stay tuned, please feel free to join the group by clicking on the below link.
- Join 'The Agilists'

NOTE - Having a Facebook account is a prerequisite.

Product lifecycle in an agile enterprise

Borrowing from Dean Leffingwell. 

How to conduct effective Sprint Reviews

Thinking out loud on how to conduct an effective sprint review. The points below are written keeping project teams in mind.

Structuring the Sprint Review

• Set an objective for the Sprint review (i.e What do you want to achieve out of the meeting?)
• Start with your sprint goal (if you don't have one, spend a few minutes in sprint planning to set one). Share a subjective assessment on how the team fared against the sprint goal
• Outline how the progress on each story (of the sprint) lead towards the eventual sprint goal

Conducting the Sprint review

• Make sure the logistics are in place (Phone, webex, sametime etc) before the meeting
• Organize the sprint review around demo of working-software (though no doubt, but very effective)
• The Project team should drive the meeting (i.e make sure you are sharing your screen, you are showing the features and answering queries)
• Pause at appropriate time to encourage discussion on the value being delivered

Avoidances (if you do any of the below mentioned, you are wasting time)

• Reading stories from the backlog
• Focusing too much on the story points (vis-a-vis actual value being delivered)
• Treating sprint review as just a progress update

Are your project sprint reviews effective? Think again, and please feel free to add your perspective.

Which software development methodology is right for you?

Over the past few months, I have interacted with many IT leaders in various agile forums. Irrespective of the process maturity in their respective organizations, I have always seen a pattern in all such discussions, which invariably leads to the question "What software development methodology is right for me?"

If we have interacted, you would know my response already...

To me, this is NOT the most important question you should be asking. Before you call any agile consultant, Kanban specialist or a RUP expert (?!$!), I would recommend you find answers to the following questions

1. What are my business objectives?
2. Does my current software development methodology encourage behavior aligned to my business objectives?
3. If not, can it (existing software development methodology) be optimized to align with my business objectives?
4. If yes, Which practices from other software development methodologies can integrated with my existing methodology?

If not, (Must you change to a new software development methodology)

• Which behavioral changes you would like to see in your work force?
• Which software development methodologies encourage such behavior?

Any software development methodology should be looked as a means to an end (achieving your business goals). In my experience, the the most common mistakes IT leaders do, it to incorrectly assume that adoption of a new software methodology is the end in itself. That is a recipe for disaster.

Thoughts? Experiences?

Follow-up: What do story points relate to?

This is a follow-up to my earlier post.

When asked "What do story points relate to?"..here is how the readers responded.

Result of the poll conducted on my earlier blog post

In My opinion, story points have evolved to be a reflection of "relative" effort required to accomplish the story from just being a representation of "relative size". Here is why.

In traditional software development, the size of a requirement doesn't change until there is a scope change. The size estimation doesn't take into consideration the factors which potentially may impact the effort involved..such as the unknowns, risks and complexity. Even if projects encounter schedule / effort slippages, the size remains constant and traditionally adept project managers attribute the delays to lower productivity.

However in the value driven world of agile development, the bottom line is 'When can the working software be delivered'. The team comes together and estimates in story points to get a better handle in sprint / release / product planning. But the key aspect here is that story points intend to convey not just relative size (read scope of work), but also the capability of the development team, level of complexity and level of unknowns. Hence in my opinion, the story points best relate to the effort required to get the story 'DONE'.

Does this explanation fit your view of story points? If not, please leave a comment.

What do "Story Points" relate to?

All agile teams use "Story points" for sprint/release/product planning. However, I still notice confusion around what does the unit 'Story point' represent.

To that effect, request you to participate in the below poll and share your subjective feedback via comments.




I would compile the findings and share my thoughts in two weeks time.

Food for thought....07/18

few short articles for weekend reading...

1. Impediments to Keeping Top Talent
2. A hierarchy of failure worth following
3. How to seek and destroy organizational silos
4. How to improve a team's velocity 
5. Agile Metrics

Performance evaluation in Agile teams - Part III

In this concluding part, I am sharing the retrospective findings from our new approach towards Performance evaluation in agile teams

Continue:
1. Empower associates to select their own goals (albeit within an organizational framework)
2. Peer evaluation process

Start:
1. Periodic peer evaluations instead of waiting till the end of the evaluation cycle
2. Include more subjective feedback

Stop:
1. None

On hindsight, we realized partial success with the new process we adopted. Further in the process we realized there is a significant opportunity for disparate agile team to share and learn from each other.

Performance evaluation in Agile teams - Part II

This is a follow-up to my earlier post on performance evaluation in agile teams



Traditionally our organization followed a balanced scorecard approach where organizational priorities get cascaded down to each individual in the form of performance goals for each evaluation period. Usually the Goals of the Appraisee is tied to the goals of appraiser. Performance evaluation happens in a bottoms-up manner where performance of each individual is aggregated to the next level (i,e, individual -> project team -> account team -> solution unit etc)

Tailoring done for Self Organizing Agile Teams

While we retained the basic philosophy of Balanced Scorecard, we did a number of tailoring specific to a self organizing agile teams. Following are the salient points:
1. Introduce certain degree of flexibility in selecting your individual goals: While we retained the alignment of individual goals to organizational priorities, we allowed some flexibility for individuals to pick their own goals. We defined a framework around Impact on end customers, Impact on organization and effort towards self development and allowed individuals to pick their own goals and targets around these.
2. Peer Evaluations: While we retained the best practices of bottom up evaluations, we added an additional step of "Peer Evaluation" specific to the agile teams

Peer Evaluation process



As the name suggests, Peer Evaluation process focuses on sharing your own assessment of your performance with your Peers (i.e Project teams) and getting their feedback. While we encouraged team to give constructive feedback on areas of improvement, we deliberately avoided any criticism of performance in this forum (Other mature teams may choose to disagree). At the end of the session, each individual provides a performance ranking of rest of the team and hands it over to the 'Appraiser' or 'functional Manager' as appropriate. Looking at the sensitivity around performance evaluations, we chose to keep this part confidential (again - other team may chose to share these rankings with the team too). The Appraise/Functional manager aggregates these rankings from all member of the team and prepares the performance ranking of the entire team.

This process work in conjunction with the one-to-one performance evaluation discussion where the appraiser provides subjective feedback. At the end of the evaluation cycle, the performance ranking of the team gets rolled-up to the next level.

In the next post, I will share our experience and learning from applying the above approach within our team.

Performance evaluation in Agile teams - Part I

This is a three part blog discussing ways of doing effective performance management in agile teams. In this part, I will try to establish the problem statement. In Part II, we will discuss one approach I am trying out as a pilot in my team. In the concluding part, I will share results from the pilot.

As usual, i would request all netizens to add their valuable feedback on the way.

Problem Statement:
For quite some time, I have been grappling with finding ways to do effective performance evaluations in Agile teams.

In ideal agile organizations we should be assessing the performance of the project teams, instead of assessing performance of individuals. Extending that line of argument, agile teams should also share the realized business value delivered by their project. But that's Utopian.

In real world, enterprise IT invariably is treated as a support function to the business. Instead of sharing business value, enterprise IT is typically run with a predefined budget with a certain number of project teams. Most of the enterprises (like ours) use Forced Ranking as a means to incentivize high performance. Performance of individual employees are ranked relative to each other and the resultant grouping is fitted into the form of a bell curve, there-by separating high performers from average performers and from the rest.

This approach works for many organizations. In order to make forced ranking model work efficiently, pioneers of this model - General Electric Corp, defines following three success criteria for your performance evaluation system:

- have dimensional consistency: Its scales and criteria must be applicable across all employee categories
- be based on objective data: "You just aren't going to be able to find quantitative measures for everything that is important to you. But you can still be objective—you can make decisions that are not colored by your emotions or personal preferences."
- produce rich analytical feedback: Employees value meaningful assessments of their work more than any other performance motivator

So far so good..but things get blurry when it comes to agile teams. Is it possible to set "dimensional consistency" for agile teams? Can there be a single scale for a number of different self organizing agile teams? How objective can you get to derive performance indicators vis-a-vis following agile practices of reducing ceremonies and minimizing waste. Most important, who does performance evaluation in agile teams? A functional manager? Or (in scrum context) the scrum master/ product owner?

So how do we approach performance evaluations (maintaining the essence of force ranking from organizational standpoint) in agile teams? In following post, I would discuss the process we are trying out within my group (comprising of a number of agile teams).

Reference:
For whom the bell curve tolls
Punishing by Rewards

Agile Metrics

I am a firm believer in the age old adage 'You can not improve what you can not measure' (unrelated - here is an interesting antithesis). I believe in the importance of having the right metrics, especially in IT projects aiming to achieve continuous improvements.

Off-late i have interacted with some agile teams to get their perception of metrics in agile teams..responses have been varied, starting with outright cynicism to a mature approach towards using just enough metrics to achieve project goals. However one aspect was common through out, there is lack of awareness on various metrics options available for agile teams.

I would encourage project teams to look at all principles behind agile manifesto, and see which are the top three principles the project team values the most and consistently achieves in each iteration. Brainstorm within the team to see if the team can objectively measure progress for each of the three most important principles. Whether team velocity and burn down charts sufficiently describe team progress in each of the practices or is there a need to think about other possible ways of describing project progress?

If you see the need of looking beyond velocity and burn down charts, here are some starting points:

1. Heuristics for agile measurement: Refer to this seminal article on Appropriate agile metrics by Deborah Hartmann and Robin Dymond

2. AgileEVM : Pretty useful if you are in an organization with strong inherent PMI practices. Though AgileEVM is pretty neat in showing consistent business value, I personally am unclear on it's implementation in projects where the scope of work changes over time. Please share your experience if you have applied AgileEVM successfully in projects where the overall project scope increased during the project lifecycle.

Some metrics towards technical excellence
3. Running Tested Features: Ron Jeffries explans RTF. More detailed description

4. Static Code analysis

5. Code Coverage

What metrics do you use for your projects?

The Technical debt

In the world of agile development, refactoring of code is an essential practice.

Watch Ward Cunningham reflecting on the history and common misunderstanding of the 'debt metaphor', as he presents the case for continuous refactoring.

Ambassadors and Boundary Spanners

In his last post, renowned Agile guru 'Scott Ambler' introduced two new roles for distributed agile teams e.g. 'Ambassadors' and 'Boundary Spanners'. Here is how he puts it..

Ambassadors are senior technical or business experts who travel between sites to share information between the subteams. Getting the team together at the beginning of the project sets the foundation for communication, but without continual investment in maintaining effective collaboration between teams you run the risk of your subteams deviating from the overall strategy.

Boundary spanners are located on site who focus on enabling communication between subteams as well as within their subteam. There are typically three flavors of boundary spanners—team leaders who take on project management responsibilities on the subteam, product owners who are responsible for representing the business within the subteam, and architecture owners responsible for technical direction on the team. These boundary spanners will work closely with their peers, having regular coordination meetings across all subteams as well as impromptu one-on-one meetings to deal with specific issues.

Does these roles sound familiar? Are we hearing the need for project manager/ coordinator roles in self organizing agile teams?? Does it mean, we need some amount of command and control..even in agile teams???

Seems like Agile methodology is re-inventing itself to infuse best practices of the traditional s/w development methodology.  Distributed development team is a reality these days and it's about time for Agile methodology to do reality check and adapt to the changing needs of IT development......