Tag Archives: ALM

Pareto Analysis of Blocked Cards

The role of metrics in TPS is crisply explained in Jeffery Liker’s book “The Toyota Way”. He explains that Toyota prefers simple metrics and does not use many of them at the plant or the company level. Some of my peers may be surprised to hear this!

The author highlights his point with a simple example. During one of his visits to one of the Toyota plants, he was told that apart from a few basic metrics (like cost of plant operations, parts per million defects, some safety related and productivity), the metric Toyota finds most useful as a manager is the number of “Andon” pulls made by each Team Member to stop the production line. They regularly graph this data, noting the problems that caused the Andon pulls and use Pareto Analysis to identify the most common reasons. They take corrective measures to address these reasons. The VP of this manufacturing unit explains how “this metric provided great insight into the actual day-to-day problems faced in the production process”.

The analogy to this in software systems that use the Kanban Method, is the blocked card. Most of us who have been working using the Kanban Method have experienced that blocked cards are a big impediment to smooth flow, increasing WIP counts and cards getting stale.

If you have a physical board, it would be difficult to track this manually over time. We, in SwiftKanban (www.SwiftKanban.com), have built functionality to track this, though I would personally prefer a two level categorization.

Image

However, not all tool providers have done even this. So, the question is: are you doing an analysis of the reasons for having Blocked Cards in your Value Stream during your retrospectives? Are you putting a corrective action for the same? I suspect that teams are missing a significant potential for continuous improvement by not doing a Pareto Analysis of Blocked Cards.

I would like to hear from the practitioners how frequently they are doing Pareto Analysis of blocked cards and then defining action items during a retrospective to fix them. If you have a physical board, are you doing it manually? Look forward to your response…

Capacity Planning for Dynamic Teams following Kanban Method

1.    Abstract

Projects are often executed by dynamic teams. They start with a small core team and as the project gains momentum, add resources over time. This is commonly seen in IT service organizations that do fixed price projects. Fixed price projects have a defined scope that needs to be delivered within a contracted budget and within a negotiated timeline. For the purpose of this experience report, “Dynamic teams” or “Fixed Price projects” will be used interchangeably.

Unfortunately, as Ron Jeffries put it, “Agile is founded on management of scope, not predicting when you’ll be done, even if you had fixed team size and “fixed” scope.”

Yet, a significant portion of the software development community does want to adopt some of the Agile/Lean principles that they believe they will benefit from. For example, they see value in making smaller and faster releases to their customers to get early feedback and de-risk their project. They see value in better team interactions that can motivate people to take greater ownership.

However, one of the key assumptions in Agile is about stable teams. Stability in teams is important, both from the perspective of size and composition. Stability helps achieve self organizing teams. Stable teams make forecasting possible based on Throughput (or Velocity) of the team. If the team is not stable, one cannot use the current team’s Throughput as the basis for forecasting when the backlog and the work-in-progress(WIP) will be completed.

This makes it difficult to ask a very common management question in such projects: How many resources are needed to get the defined scope done within the negotiated timeline? Further, if there is Scope Creep, how does this impact the schedule or the resources plan? This Experience Report, based on the author’s experience in applying Agile/Lean principles to dynamic teams or fixed price projects, lays out an approach to answer these questions.

It must be highlighted that these questions and some of the approaches suggested seem contrary to well understood Agile thinking. For a true Agile practitioner, these are not the right questions to ask. However, these are questions that managements or customers will ask when they need a defined scope within budget and negotiated timeline; yet, adopt some of the Agile/Lean practices to benefit from the same.

2.    Stages of Capacity Planning

Capacity planning is done across the project life cycle:

a)    At the beginning of the project when a Resource Plan is made.

b)    During execution of the project:

    1. As the project is executed, changes happen. Things don’t go fully as originally thought off, resource changes happen because of attrition or other business priorities, etc. This calls for a defined approach of how and when Capacity Planning should be done.
    2. Further, as the project is executed, Scope Creep happens. Agile teams are expected to welcome scope change. However, when one is executing a Fixed Price project, a re-assessment is needed to find out whether the committed timelines and budgets can be maintained with the allocated resources. If not, then a dialogue with the customer is needed to converge on the revised scope/budget/timeline.

In this Experience Report, we will look at how to do Capacity Planning for each of the above situations. This report uses the Kanban tools to illustrate with examples. However, the same approach can be applied if one I executing a Fixed Price project using the SCRUM approach.

3.    Capacity Planning at Project Beginning

Capacity Planning for a team at the beginning of the project is meant to address the key question – how many resources, and of what profile, do I need to deliver the defined scope in the given time? The method to answer this question does not change compared to how one would do it traditionally.

The approach is as follow:

a)    Identify the EPICS. Decompose them to MMFs and User Stories.

b)    Once the User Stories have identified, make a high level resource capacity plan based that details the skill profile needed for each of the User Stories. One can then aggregate it the capacity plan across user stories by skill profile. So, an example of an output from such a planning process would look like this.

01

Once a detailed plan is made, it can be aggregated across user stories by skill profile as follows:

02

Such a Resource Plan will give management the confidence to deliver the defined scope within budget and stated timeline.

Once project starts, things don’t always go as per plan. This is why Capacity Planning needs to be done regularly. In the next stage, we use the Kanban Method to show how this can be accomplished.

4.    Capacity Planning during Project Execution

While an original plan is established, things start deviating from plan shortly thereafter. This is one of the reasons by many Agile practitioners discourage detailed planning (as illustrated above) in the first place.

Nevertheless, having established the need for the same in applying Agile/Lean methods to Dynamic teams, the next question to answer is – how and how often do we keep re-looking at this resource plan? We use the Kanban Method to answer this.

Below is a Board layout for the Backlog before cards get taken for Development. You will notice that this is split into 3 sub-lanes: a) Pending b) Next Priority c) Ready for Development. The Cycle Time for cards moving from “Next Priority” to “Development” should be around 1 month. The Cycle Time for cards moving from “Ready for Dev” to “Development” should be around 1 week.

03

In the next step, we use Explicit Policies to do Capacity Planning during Project Execution:

a)    For the “Pending” lane, define a policy that states “Before exit, validate resource demand for the card”. This implies that whenever a card is moved from “Pending” lane to the “Next Priority” lane, the team will re-visit the Capacity Plan for that card (as laid out in Step 1) and highlight the needed resources to the Project Manager. If resources are not available, then the card is Blocked and kept in the “Pending” lane.

This approach highlights the team management of any potential resource constraints at least 1 month ahead of time.

b)    For the “Next Priority” lane, define a similar policy – “Before exit, validate resource demand for the card.” If resources are not available, Block the card.

This approach helps identify any resource constraints due to last minute/unplanned events. It helps reduce the probability of cards getting stuck in development because of resource issues subsequently.

This process would happen for each card whenever it is moved from one lane to next, often during Backlog Grooming.

A few additional points to be highlighted:

a)    Have a narrower WIP limit as you move from left to right within the Backlog stage. This will help in cards flowing to downstream lanes if some cards in the upstream lanes are blocked for resource constraints.

b)    When assessing the resource availability in the above stages, take into account the cards that are already in progress with their current Due Dates.

5.    Capacity Planning for Scope Creep

Agile projects accept scope changes by continuous re-prioritization of the backlog. Teams continue to be undisturbed, even when Scope changes. That is not the expectation in projects that are executed in the fixed price environment. Scope changes are executed using the Change Control process. A Project Manager has to assess the impact of Scope Change on the already committed timeline and budget.

Agile methods make this remarkably simple. If you are following the Kanban Method, the team already has the Throughput data. If the current Throughput is applied to the revised scope, the revised timeline can be easily determined. This is done with the Cumulative Flow Diagram (CFD). Let us understand this with the following example:

The images below show a Board and it’s corresponding CFD diagram.

01

01

This CFD shows that for the team to complete the backlog, they need to complete the Value Stream at the 16.13 story points/day.

Now, let us consider a situation where because of Scope Creep, new cards have been added to the Backlog to the extent of 120 story points. These “new” cards are highlighted in red in the Backlog lane.

01

When CFD is plotted now, it shows the following data:

01

This shows that the desired Throughput to accomplish the revised scope within the same timeline increases from 16.13 story points/day to 18.09 story points/day, an increase of around 12%.

Once this is identified, the information can be shared with the stakeholders to discuss and evolve the best way forward. Resources could be added to the desired extent (subject to availability) or one could do scope substitution or a combination of both. Worst case, all stakeholders know that at the present Throughput, the revised scope will mean extending the timeline by 12%.

A similar exercise using traditional methods/tools would take an extended period of time. One needs to do a combination of resource loading and balancing, re-identifying the critical path, fast tracking or crashing to shrink the critical path tasks before they can conclude on the impact to the overall project timeline and budget.

6.    Summary

Capacity planning is a challenge for dynamic teams that want to adopt Agile/Lean practices. This Experience Report shows that the approach for building the initial Capacity Plan is unchanged whether the project is delivered using traditional or Agile/Lean methods. However, during project execution, using the team Throughput or Velocity, the Capacity Planning process becomes much simpler and accurate.

Learning Agile Requirements with User Story Mapping

The Limited WIP Society Bangalore Chapter held its 2nd Meetup at Pune on Oct 26. The session was hosted by BMC, India and their office. A group of about 25 Lean/Agile enthusiasts met on this Saturday morning.As in the last Meetup in Bangalore, the focus of this Meetup was also Agile Requirements and for the same reason – it is hard to establish flow and reduce cycle time when requirements are not independent, small or testable. Our experience shows that using traditional requirement definition approach, we get a set of highly inter-dependent requirements that get stuck at System Testing, waiting for each other.I started the Meetup with a detailed presentation on Agile Requirements. We discussed about the problem with requirements written the traditional way, how User Stories mitigate that problem, how to decompose User Stories and finally, doing User Story Mapping.Post a short tea break, the group was divided into 2 teams. A case study was given to both the groups. The groups were asked to first identify the sequence of steps defined above. After about 90 min of intense discussions within each of the groups following the 3 step process, both teams had their first version of the User Story Maps, though not complete.Once the User Story Mapping was completed, we discussed how to do Release Planning using the User Story Map. A follow-up question was about User Story estimation. The group was introduced to the Planning Poker approach. The Meetup ended with a quick summary of the session and a retrospective of what worked well and what could be improved in the next Meetup.

 

 

Agile Requirements with User Story Mapping

The Limited WIP Society Bangalore Chapter held its 3rd Meetup at Digite’s Bangalore office. A group of 20+ Lean/Agile enthusiasts met on Saturday morning at 10am.

The focus of this Meetup was Agile Requirements. This topic was chosen because it is hard to establish flow and reduce cycle time when requirements do not follow the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small and Testable). Using traditional requirement definition approach, we get a bunch of highly inter-dependent requirements that get stuck at System/Integrated Testing for each other.

I started the Meetup with a small introduction to the need for Agile Requirements. Post this session, Manik Choudhary, Agile Project Manager at SAP Labs, started the main session. He gave a high level overview of the larger landscape – building the product vision using Lean Canvas, using Design Thinking to validate your concept and then use a technique like User Story Mapping to build the product backlog.

With this high level view, he started with the basics of User Story Modeling. This was done in 3 stages. First, identify the vision of the product by defining the usage sequence of the product. Next, identify the Personas who will use the system and how each of those personas will use the product in the above Usage Sequence. This is the “backbone” of the product. Finally, define the user stories under each of the usage steps (within the usage sequence) for each of the personas.

With that overview, the team started the workshop. The group was divided into 2. A case study was given to both the groups. The groups were asked to first identify the usage sequence. After about 90 min of intense discussions within each of the groups following the 3 step process, both teams had their first version of the User Story Maps (see picture). Our team could only finish User Story definition for only 2 of the 3 personas that were in the case study.

At this stage, the teams were asked to vote and identify the Minimum Viable Product (MVP).

Finally, USM is not a one time exercise. The process is repeated, perhaps once a month, complimented by a more frequent Backlog Grooming.

The Meetup ended with a quick summary of the session and a final retrospective of what worked well and what could be improved in the next Meetup. As the retrospective showed, it was a great learning experience on a Saturday morning!

Daily Life of a SWIFT-Kanban Developer

Introduction
Within the Swift-Kanban development team, we have evolved our Engineering ways combining principles of Test Automation, Continuous Integration and Kanban thinking. On the other hand, as I have tried to recruit people for such a development environment, it has been difficult to find people who understand such a working environment. This blog attempts to helps explain our Engineering environment.
Stand Up Meetings
The day starts with a stand up meeting at around 9am. Given Mumbai and Bangalore traffic, there is a 10min flexibility allowed for. Since we are distributed team across three different locations (3 cities, 2 countries), many of our team members join the call remotely.

The basis for the Standup Call is the Project Kanban Board (shown below) maintained on our own product. So, we do eat our dog food:


The purpose of this meeting is to get a quick overview of the team’s current situation, find out if any development tasks have been blocked, assign the day’s tasks, discuss any customer identified defects (which are our Expedite cards) and assess any broken builds.

Blocked cards take special attention in the Standup call.

All discussions are documented as comments against the card.

Our target is to complete the call in less than 30min but this does not happen sometimes. Primary reason for this is one or two issues hog the limelight. Sometimes, one of the team members would interrupt and ask for this issue to be taken offline but we do have some “silent” team members who prefer not to break in (culture thing). So, over a period of time, we have learnt to split the call into two parts: a) have the regular stand-up call b) discuss specific issues for which only the relevant team members need to stick in.

CI Run actionable

Once the Standup call finishes, every developer checks the CI run output if anything is broken from the previous night’s full automation run. For this, there is a consolidated failure run   report from both Junit (unit testing environment) and Sahi (functional test automation environment) sent to all test members from the build (as in the right column). The report reflects not only the failures in the last run but also highlights in red automated test cases that have failed in the last 3 runs. We have experienced that test automation failures are not always linked to the product source code issue or the test automation source code but to  a random system behavior (for e.g., where the server does not respond back in time). Hence, repeat failures is important to identify true failures.

Further, we have an artifacts repository where we store the Sahi html reports that has more information about the failures. Developers use it for further analysis.

If the developer’s names appears against the failure, it his/her first task is to fix the issue(s) reported and then move on to the regular card on the board.

Developers use Eclipse for both Automation script failure analysis and Junit failure analysis. Junits can be corrected and tested on-the-fly in Eclipse.

One of the unique aspects of our development process is the association of an automation script to an individual owner. This was very important because prior to doing this, it wasn’t clear who was responsible to get a failed script fixed. It is hard from a nightly run to identify which of the check-ins(s) (from a series of checkin(s) done throughout the day) is responsible for this script to fail. Hence, we assigned the original developer for the script the responsibility to fix it. It turns out to be faster too in most cases because of their familiarity with the script, being its owner.



For this reason, we use the Test Management repository of SWIFT-ALM (where the test suite inventory exists). A snapshot of the same is shown above.

Our source code is also integrated with Sonar dashboard. On every CI run, the dashboard gets updated and provides valuable information about the java code. We have enabled various plugins on Sonar like PMD, findbugs etc. A developer is expected to look at this dashboard and correct the violations in their module’s source files on a continuous basis. Sonar dashboard gives a good insight into the coding pattern of developers and helps the team in figuring out the better ways to write code.


Development:

Once the issues from the last CI run are addressed, the developer’s focus shift to his/her main development card. Customer defects are all the cards marked in Blue and are our equivalent of the “Expedite” Class of Service. Our next focus is on the pink cards that indicate internally identified Defects and finally, they focus on the User Story that they have on their name. We also have Tasks that are equivalent to Engineering Tasks (called a Technical User Stories in many places). This priority “policy” becomes the basis for developers to pull the next   card when they are done with their present card. Global items are things like training, CI failure rework.



A few additional policies that we have defined:

1.  User Stories flow through the Design and the Functional Automation lanes.
2. At the end of the Design stage, a T shirt estimate is converted into an actual estimate.

While code review is done for all checked in code, Automation code review is only done on a sample basis.

Developers are also free to add tasks to the card, and if needed, assign some of the tasks to another developer who is expected to pitch in.

Developers work on a separate branch in SVN created for a User Story. This branch becomes the development workspace for all the developers working on the User Story. This facilitates easy coordination between the development team and informal code review can also start since the code is already committed. Once development is complete, developer merges the changes to the main branch (trunk) on SVN and deletes the branch that we created. Cruise Control gets the latest code, does the build, runs the Junits, deploys the build on QA server and runs functional Automation on all the 3 browsers that we certify the product on..
Defect Validation:
Developers are also expected to keep an eye on the validation lane. If they have filed an internal or customer filed defects, they are expected to validate the fix on the QA environment and if the fix passes, move the card to the “Ready for Deployment” lane. User Stories are validated by the Product Manager.
Deployment
We are not in the continuous deployment environment but we do deploy every time the number of ready to deploy once we have 20+ cards. We do not deploy automatically because we do have some test cases that need to manually validated for some technical reasons (third party product integrations or test scripts that fail because of our Automation tool issue).

Hope this helps understand the daily routine of a Swift-Kanban developer. It is exciting and many times more productive than how we used to develop software about a couple of years earlier.

Are you still without an ALM tool?

In my earlier Blog, I asked the question on why ALM tools have not become a project necessity? Why are they not more “visible”? While I tried to answer some of the challenges, are you one of those still wondering if YOU need one? Let me give you some real data from our own example to help you decide…

Our code base is 1.4MLOC running on 2 databases, 2 app servers on 2 OS. That means 8 stack combinations, ignoring that we run on both IE and FF. Further, because we have many customers on old versions of the product, we maintain a minimum of 3-4 maintenance branches at any point of time. So, if you fix a defect on one branch, you have to replicate that across all other branches. How many hands-on people do you believe would be required to maintain this application with a steady flow of enhancements? If you did not know our strength, I would suspect that your answer is around 40-50. We do it with an average of 15 FTEs! If one has to look for productivity examples, I cannot think of anything better than that.

We maintain our Backlogs on the tool, we rank them and estimate them and then, depending on the capacity, determine how much we can do in the next release. That just defined our Release Scope! In all my past 20 years as a delivery person, that process has taken 4-6 weeks! We do it in a couple of days.

Once our Release Scope is defined, we execute our enhancements using workflows.

Our test cases, manual and automated, are all online. They are defined module-wise and graded on their importance. Depending on the impacted modules in the Release, we identify our scope of regression testing with a few clicks.

Test execution and defect tracking is all the system. We don’t have to maintain long lists in spreadsheets trying to build pivot tables on status, resource-wise, age, etc.

Our customers file issues that we convert into to defects or enhancements. Once again, we do our impact analysis on the system, review it on the tool with comments and then, assign it for coding and testing using workflows. When we commit our changes (we use SVN), we identify the defect or enhancement it is for and completely traceability is established automatically.

My experience is that organizations handling an application of this size would have 3-4 Technical Leads managing a team of 30-35 FTEs and a full time Manager. We have less than 1FTE playing the role of a Release Manager. We meet once in a week for 2 hours. That is the extent of Project/Program Management that we do. Rest is all online…

My CEO gets his full dashboard on the system, real time. No multiple versions from different managers, no data manipulation, no dedicated operations staff preparing Excel/Word reports on Friday evenings or over the weekend.

The results: we have made a release every quarter for the last 2 years. We have slipped once by 3 days. We have brought our defect rates down by over 30%. Of course, we have built a great team but without one integrated tool, we would have been in a mess, doing a lot of rework!

So, if you are not on an ALM tool, get on one! In 6-9 months, you can’t imagine building software projects without it. How many times do you handwrite a letter anymore?