Tag Archives: Project Management

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.

 

 

Applying WCM to the Software Industry

I recently spoke at Symbiosis University on how WCM (World Class Manufacturing) thinking is being applied to the software industry.  World Class Manufacturing [WCM] is the collective term for the most effective methodologies and techniques to realize the objectives of: A) Products of consistent high quality B) Delivery on Time of the desired quantity and C) Product at the lowest cost. The commonly knows WCM methodologies and techniques are TPM, Kaizen, TQM, Six Sigma, JIT, and Lean Manufacturing. This presentation shares how the software industry has been adopting many practices from the above techniques over the last decade. 

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!

10 tips for a Project Manager to get organized!

The obvious: a Project Manager needs to be organized – you have a higher chance of success! I have seen some Project Managers who are disorganized succeed on the strength of their personality. For the majority of us, it becomes important to be organized to deliver our projects better. Being organized comes at a cost – it takes time and discipline but you the long term payback is significant.

In most cases, being organized is a person’s nature. You either have it or you don’t! You can’t be organized at work and be highly disorganized at home (or vice versa). In other words, if you don’t have this skill and need to build this, you have to make that effort in all aspects of your life. If you already have it, then this blog is not for you! What I am suggesting below are some areas for you to first get organized in your personal life. Over time, as you start getting used to the change and see its benefit in your personal life, you will see the spillover on your work. You will respond to your management better and faster. You will have better data and will not be found wanting for information. So, here we go:

1. All personal records – we all do it! However, also preserve your appointment and promotion letters with their compensation details. I have been in interviews where I was asked my starting salary and how it progressed. It is an excellent yardstick on how well the person did at his job.

2. All financial documents – this includes all investment records, bank statements, credit card statements, insurance/pension policies, real estate documents, credit card receipts till you reconcile your statement, receipts of all major purchases and their warranties.

3. Build a labeled, sorted, filing system. Make sure your spouse is aware of where it is and how it organized

4. For the online guys, have a well structured document naming and folder structure. Avoid cryptic names. Use one standard convention for naming your documents. Imagine the situation when you are traveling and you do not have access to your laptop/desktop. You want your spouse to be able to email you that specific document. Date stamp file names in YYYYMMDD format – a file name sort will act as file name + date sort!.

5. Contact database – Almost every email system has something for Contact Management! Use it for your business and personal contacts. Make sure that you sync this with your smartphone repository. Have you ever lost your mobile phone? Keep a backup on Gmail or Yahoo mail.

6. Personal Finance – track your expenses/income/investments in MS Money or any other open source software like http://www.gnucash.org/.

7. Email – There are a ton of things that you can do on this front to be organized. Often, I have seen subject of the email quite unrelated to the content in it. Break that link. Keep a folder of pending transactions – emails that have not been closed and need some action from someone. I use my Inbox as the pending folder. You can use flags, tags, folders, etc.

As a Project Manager:

8. Organize your meetings and follow your action items to closure. Make MOMs religiously and publish it. An old fashioned trick is to get signatures of the attendees on a hard copy – it does miracles in getting their commitment on their actionable. Make sure that people see you following through on open items. Use a Project Management software – it will escalate for you when things are pending or not closed on time.

9. Never miss a Weekly Status Report. Once again, use a Project Management software so that this is a click of a button – not a 2hr Friday late afternoon/evening exercise.

10. Escalate issues, honestly and politely. If you do not do it at the right time, you will be later accused of napping. If you overdo it, you will be accused of making unnecessary noise. Timing is critical. No tool can really help you on this one…

In the beginning, doing all this will seem like extra effort. However, as these become second nature, escalations will come down, closure will happen faster and project execution will be smoother.

Strengthening Execution with ALM

We all are aware of the abysmally low rates of projects being delivered on time, within budget and with the desired quality. One of the most prominent reasons is poor Execution. Project Managers often are challenged with having to satisfy multiple stakeholders – their boss(es), customer(s), team members, auditors, etc. Consider the political and matrix nature of most organizations and you have a situation where he/she is being pulled in multiple directions, trying to balance between the opposing political forces.

Most of the time therefore, gets spent in trying to manage your stakeholders, communicating to them what they want to hear in a way they want to hear (so that they really “hear” you), escalating risks and issues in a manner that escalates the point but yet does not offend people, setting expectations of how the project is “really” doing, etc. In a reasonable size project in a constrained environment, this becomes a full time job. Activities like task planning, analyzing slipping tasks, tracking risks and their probability of actually happening, focusing on product quality, handling your team – tasks that the project manager should actually have been doing – get less time and focus. Depending on where the escalation is, the project manager is fire fighting one issue after another, running from one meeting to another! Before the guy takes time to breathe, the day is over… the entire environment is a high stress environment.

The irony is that because the Project Manager is not able to do what he/she should have done in the first place, the situation actually gets worse. Everyone is working 10-12 hours but the situation spirals out of control.

ALM tools significantly help you in getting the situation under control. They help the Project Manager by creating the WBS, inheriting risks from past projects or similar projects so that you do not miss out something that others experienced, tracking the project progress, getting real accurate status based on actual time sheets, building reports for different stakeholders with s single click, give the metrics that identify the right trend from the wrong trend, documenting MOMs and Action Items and tracking them to closure… the list can go on. This is 60-70% of what the Project Manager should have been doing but gets very less attention. Even when it does get the attention, it is done in a hurry or not in the right frequency. ALM tool restores this balance by automating almost 70-80% of these tasks. The Project Manager now needs to spend only 20-30% of their time on these tasks. This leaves him/her bandwidth for doing all the tasks that need proactive thinking, looking ahead with the crystal ball and trying to forecast potential problems or points of failure, do expectation setting with all stakeholders and spending time with their team members.

People sometimes complain about the high volume of cumbersome data entry. I keep reminding them of two things – 1. You would be doing 70% of these tasks today. However, it would be spread in multiple spreadsheets and documents. 2. If you really want to get data from the system on which you can make dependable decisions, then you do need to execute the project with granular, accurate, real-time data. The final result is quite worth it!

ALM tools – why is their visibility limited?

I have often wondered what has prevented the modern day ALM tools from proliferating in the market place. Haven’t we all heard about an extraordinary percentage of projects failing? So, why have most decision makers in the industry refrained from procuring such tools? The answer is pretty simple – usage of such tools have not improved the success rate of these projects.

Any successful initiative is based on three dimensions – people, processes and tools. ALM tools fulfill the Tools dimension well. Unfortunately, tools are only as good as the people who use the tools or the processes that they choose to implement. Of the three dimensions, tools are perhaps the least influential in make a visible impact.

If the passion of successful projects is what drives companies ALM tool vendors, then I believe these are areas that cannot go unfocussed. Tool competency has to be accompanied by services that will help make Project Managers more successful as well as processes that will make the overall “package” more effective.

There are companies that have addressed at least two of these dimensions. They preach the methodology that they practice and provide the toolset built on that methodology. Companies like Miller-Heiman do this in the area of Sales practices. Rally, Thoughtworks do that in the area of Agile practices. Rational was perhaps the most successful company in preaching the UML way of doing things and selling the entire software that goes with it. There are examples of other companies having reasonable success focusing on at least two of these three dimensions.

These companies did completely miss out the entire Project Management space but lack of it has not been a strong negative. We will discuss that in a later topic.

There is one more challenge for generic ALM tools. A tool that tries to automate every methodology is, to a large extent, “generic”. It does not capture the essence of any methodology. It is a combination of screens, reports and metrics of every methodology. However, it’s UI and usability does not reflect the finer nuances of any specific methodology. Its training material does not capture the essence of any specific methodology. Its consultants do not speak the language of any specific methodology. It’s Sales team does not sell the spirit of any specific methodology. Last but the not the least, its users, who use the toolset, use in a combination of different ways, which is more often than not, a “confused combination” of different methodologies.

For now, most organizations in this domain have completely ignored the third dimension. This has been left to the combination of soft skill training programs and domain specific PMI training programs. One can only wonder how successful a company could have been that defines the methodology, trains Project Managers on becoming more successful with that methodology or other soft skills and provides the toolset to automate that methodology.

Of course, no business problem has one solution. However, this seems to me one of the critical missing links that prevents the “mass” adoption of ALM tools as I would expect.