Tag Archives: Lean

Turbo charge your productivity by combining Personal Kanban with GTD

Personal productivity and time management tools/methods have always been a subject of interest. Numerous methods and tools have been developed over the years. However, few seem to stick over time. Given that any tool or method needs a certain level of discipline at an individual level, is there a method that can really stick, help you manage better, visualize what you need to do and most importantly, stick? In this blog, I am going to share my own experience of tackling this challenge.

I got exposed to Lean thinking when we first started using the Kanban Method for our software development. That was about 8 years ago. Since then, I started using Kanban Boards, visualizing work, limiting the number of things on our plate, etc. It was a transformational experience.

A few years later, I came across Jim Benson’s adaptation of the he Kanban Method to personal productivity, called Personal Kanban. Personal Kanban adopted 2 principles from The Kanban Method. I will talk about in brief:

  1. Visualization
  2. Limiting Work-In-Progress(WIP)

1. Visualization does 2 things:

A) It lets you view your work items as a card, physical or electronic. Suddenly, an amorphous in-mind memory item becomes something that you can see, track (or even touch and feel, if its physical). In the picture below, you see a few examples of a person’s ToDo (“Use Kanban”, “Try Kanban Tool”, “Learn About Kanban”, “Get Some Sticky Notes” and “Get a White Board”).

t1.jpg

(source: http://lifehacker.com/productivity-101-how-to-use-personal-kanban-to-vizuali-1687948640)

B) Put them on a board where you can track their progress. In the most simple form, the Board will comprise of a Backlog(ToDo) -> InProgress (Doing) -> Done. The picture above shows this in its simplest form.

We can use an Electronic Tool like (www.swiftkanban.com) to build a similar Board. An electronic tool can be used to indicate and track many other things. For example, I can add a Comment as I am progressing on the card, Block a card, raise a Risk/Issue, etc. Most importantly, being accessible on a mobile, my Personal Kanban system is always with me. If something comes to my mind when I am shopping in the mall, I can add it on the Board immediately, without having the burden of having to remember when I get back home! So, my electronic version of the above Personal Kanban board will look like this:

t1.png

The next step is to create a “Next” lane (see below). Introducing a “Next” lane between Backlog and the In-Progress Lane helps focus on what I really need to work on. In the process, it consciously deprioritizes what I cannot work on now. That helps reset expectation with other people if I was supposed to get back to them. Unmet expectations, external or internal, are known to generate a lot of stress! So, just prioritization help bring down stress levels!

t1.png

2. Limiting WIP: Contrary to the conventional thinking that multi-tasking is great, current behavioral science tells us otherwise. In fact, HBR says that multi-tasking brings down personal productivity by as much as 25-30%. Multi-tasking increases stress levels and people get burnt out. Defining a WIP limit, i.e., how many things we are going to work on at the same time, again helps us prioritize what we must do now. Once again, like the Next lane, it gives us a list of cards that we will NOT be working on and set expectations to myself/others.

So, where does GTD (Getting Things Done) fit in?

GTD helps us in “Getting” the prioritized card done. There are few key practices from the GTD body of knowledge that tremendously boost the effectiveness of Personal Kanban. We will discuss a couple of these below that I have found to be most useful:

  • Mind-sweep: GTD strongly recommends clearing everything from the mind and moving to a system of our choice. The mind should be used to doing things; not trying to remember things. For a Personal Kanban user, the system of choice is our Personal Kanban system.
  • Contextualize: GTD recommends contextualizing cards into buckets. Contextualization helps by clearly having a set of cards that we need to work on when we are in that context. In other words, we are not carrying the burden of full WIP always but ONLY what is in the context that we are in at the moment.

The two most elementary buckets are: “Work” and “Home”. Everything we do can be categorized into those two buckets. We go one level deeper. Almost all cards will have one of the following immediate actionable:

A) “Call” someone as the immediate next step.

B) You need a “Computer” to do the immediate next step on the card.

C) You need do an “Errand” for the immediate next step on the card.

D) You can add an “Others” bucket. I have it but rarely used it.

Categorize all our cards into one of these above buckets. These are your WIP and hence, should count towards your WIP limits.

However, in addition to the above, there are cards where the next actionable is not on us. We are waiting for an external event or a response from someone else, etc. For example, let’s say we need to get a new Passport. Once we have submitted the application, we are waiting for the Government to do a physical verification of the person by the police (at least, in India). You don’t want to mark it as done because it isn’t! Such a card, where the final outcome is pending and we need to track it till it is “really” done, is categorized under “Projects”. These cards are not part of your WIP. The next step is not with us. Such cards also fall under both Work and Home categories.

As a result, your Personal Kanban board will look something like this:

t1.png

Once all the cards have been contextualized in different buckets, we have dramatically increased our focus when we are in any particular context. When we are at home in front of the computer, we know exactly what all needs to get done. When you are stepping out of home, you have a ready list of errands that you need to act upon.

I have also added one lane called “Agenda”. Here, I track any conversation that I need to be have with my directs at work or family members. So, I don’t need to store in my mind what I need to discuss with them! Remember, a free mind means more of the “mind” is focused on doing things – not remembering things.

As a result of applying Personal Kanban and GTD together, the “revised” Personal Kanban+GTD principles are:

  1. Visualize your work
  2. Prioritize by enforcing WIP limits on yourself.
  3. Contextualize your work
  4. De-stress by prioritizing – get back to people whose expectations might not be met!
  5. De-clutter your mind – use it to get things done; not remember things.
  6. TRUST your system of choice!

Last but not the least, use a mobile app to build your Personal Kanban so that you have it always with you. A recommendation would be SwiftKanban product, where I have my own Personal Kanban and from where some of the screenshots for this blog have been taken.

Happy Kanbanizing!

Advertisements

Applicability of Agile/Lean/Kanban Methods for fixed scope/budget projects (with short duration)

The Pune Chapter Meet of the Limited WIP Society was held on Mar 8, 2014. This session objective was to address challenges faced by Lean-Kanban practitioners in their projects. Participants from 4 different organizations attended this session. A couple of problems were posed by the participants (Meetup Link) ahead of time. We decided to work on the first one for this session.

Problem Statement: Some projects are fixed scope, fixed budget and have relatively small duration – 3-4 months. In this case, would it make more sense to go for: a) Pure Critical chain or Microsoft project plan based date based approach b) Combination approach: Critical chain based planning followed by Kanban execution. c) Pure Kanban flow based execution approach with no date based plan for individual stories.

The team started the session by working in teams to identify what aspects of Lean/Kanban facilitate small project execution that have fixed scope, fixed budget and small duration (“+ives”) and what aspects don’t (“-ives”).01

Next, they came to the white board, brought all their points and grouped them together. The result looked something like this!01

Result: The team, working independently, had identified 18 positives vs 14 negatives in adapting Lean/Kanban/Agile principles to fixed scope, fixed budget projects with a short duration That a very positive reinforcement of their suitability. Therefore, Option C was taken as the way forward for the rest of the session.

While the session started with a focus on projects with short duration, it was evident that except for a couple of points, this discussion was valid for project of fixed scope/budget, independent of any duration.

The following Positives were identified when applying Agile/Lean methods to these projects:

Positive Contributors

Planning

  • If using SCRUM, defined planning activity
  • Small Cycles
  • Estimate upfront (high level) and understand the feasibility of delivering
  • Divide into stories; complete logical business flows
  • Can help in sustainable pace

Quality:

  • Higher Quality Delivery
  • Stable Software
Scoping and Prioritization:

  • Early Start of mature (well defined items)
  • Focus on prioritizing – very relevant
  • Principles of Agile help; focus on blockers
  • Power visualization

Early Feedback

  • Still relevant
  • Demos are confidence building

Team

  • Team empowerment is positive
  • Collaboration
  • Encourage small team size
  • Cross functional teams

After a brief discussion on the positives, since the positives were stronger than the negatives, the focus on the remaining session was how to mitigate the negative factors in these projects.

The group decided to focus on the negative contributors. Each group was given one of the negative areas to focus on. They were asked to break up the negative contributors to the next level (identified as LI below) and identify possible resolutions for the same. Then, all teams converged and refined the possible resolutions in each of the areas. The following negative contributors were identified with a clear path to resolve them.

Negative Contributors
Planning Area:  01
Negative Factor:MSP is used for Portfolio and Program Planning..Resolution Approach: Lean Methods exist for Portfolio Level Planning, like Portfolio Boards. We need to educate that it a myth that Agile = No planning.
Hence, training, education and pilot programs need to be considered as a means to bring about awareness on the importance of planning and the methods available.
Negative Factor: For such small projects, the team might have good visibility of the scope. Budget, scope and timeline for such projects are often well defined. Hence, they might be tempted to plan heavily upfront and execute based on that..Resolution Approach: High level planning is good and if the details are available and if everyone feels assured about it, then doing isn’t a negative. Avoid detailed estimation, planning to man hour level and then getting into variance tracking. This will lead to timelines getting met at the expense of quality and work-life balance. Negative Factor: In a very dynamic environment, MSP helps in quick impact analysis..Resolution Approach: This is not accurate. With MSP, the defined path was cumbersome. One would find the critical path, then do all kinds of jugglery like fast tracking, crashing, etc. It was based on estimates and we all understand that estimates are dead on arrival!So, we need to move all stakeholder discussions to velocity/throughput centric discussions. To enable this to happen, a lot of training needs to happen for all stakeholders involved.
Negative Factor: No Dates; hence, things pile up.Project Manager does not get sense of delays; lack of timeline; project delivery date is variable..Resolution Approach: The obvious answers the team came up with was to have time boxes (what SCRUM does). Also, it was discussed that Kanban does not have anything against Due Dates. In fact, many Kanban team use Due Dates. The risk is that Due Dates should not construed as milestones that puts pressure to finish the job, no matter what.
Resource Management:  01
Negative Factor: MSP helps in Resource Planning, Capacity Planning..

  • Cards pile up in the end; no flexibility to take care of scope uncertainity.
  • No targets for SWP; ST is not able to plan testing
  • Sudden resource requirements that come up case disruption to the whole project
Resolution Approach:

  • The best way forward is to have stable teams. However, if this is not possible in a given environment, we should be able to visualize this constraint and give time to stakeholders to plan resources. The way to do this is document in this blog.
  • Another approach is to under-allocate critical resources. They are often called in to help others or take care of some critical work in the pipeline.
Testing:  01
Negative Factor: One has to test repeatedly, specifically regression. Since the project duration is short, the tendency is to test at one shot in one batch.Assumption Testing and development are being done by 2 different people..Resolution Approach: Automation
Where automation is not practical or feasible for whatever reason, the team felt that right documentation or Knowledge Transfer to the tester can help reduce repeat testing. If the tester understands the scope of each user story well, then he can focus on the scope of that user story and in subsequent test cycles, focus on scenario based testingIn a specific environment where ST is expected to “Certify” the product quality and hence, need to re-test “all” test cases, including unit level test cases, the recommended approach is to focus on reviewing the comprehensiveness of the Unit Test Cases and Unit Test Results. That would help Dev teams get better by not taking Unit Testing lightly. By ST doing unit level testing, it makes Dev teams continue with their current practices.In cases where Dev teams are mandated to Junit testing, ST teams can seek the Junit Code Coverage data to understand the level of comprehensiveness of Unit Testing.
Env/Infrastructure:   01
Negative Factor: The team identified Configuration, Sanity, Missing HFs, Connectivity, Overloading of environment as all related issues to environment, infrastructure..Resolution Approach:

  • Environment/Infrastructure planning cannot be a batch mode process. Just like capacity planning, Env/Infrastructure needs to be continuous process. Whenever a card gets prioritized within the backlog, all its environment and infrastructure needs can be defined on a card and put in a parallel swim lane to track them to closure (see screen shot)
  • Get people from the Infrastructure/ Environment teams involved in the Sprint planning process; if you are following the Kanban method, pull them in whenever Backlog grooming happens.

01

The 1st Limited WIP Society Meeting Pune Chapter

The first meeting of the Limited WIP Society Pune Chapter happened on Jul 20. Over 20 participants from 5 different companies attended this session.

The first session was presented by Sutap Choudhury from the Amdocs Transformation team. Sutap explained the challenges of the traditional development models and the rationale behind the Agile/Lean/Kanban adoption within Amdocs. He explained the Kanban core practices using Henrik Kinberg’s animation slides. At the end of this session, multiple questions were asked around the implementation of Kanban. One of the questions asked was around the practicality of having cross functional teams – how practical is it to have people from one value stream lane move to another lane to help out on a Blocked card? It was explained that while it may not be 100% possible to get fully cross functional teams, it is important for the team keep this objective in mind and look for opportunities to implement the same. Cross skilling the team will always help tackle such bottlenecks. Another question was around the differences between Kanban and SCRUM. It was discussed that SCRUM/XP are time-boxed execution models in contrast to a continuous flow approach in a Kanban system.
The second session was presented by Hrishikesh Karekar, also from the Amdocs Transformation Team. He explained the challenges of implementing Kanban in a large project – a project of over 800 man month, with over 150 resources over a timeline of 9months. The key challenges that this team experienced were around: A) Splitting Requirements B) Managing Execution and C) Understanding whether the project is on track from a budget perspective. To help manage project execution and tracking project budget consumption, Hrishikesh explained the adoption of Earned Value Management. In the initial days, Amdocs adopted Earned Value tracking by giving part credit to a card when it completed part of the value stream (similar to % progress in MS Project). Unfortunately, this approach led teams to keep pulling work so that the Earned Value % increases, instead of focusing on completing work. Amdocs is now considering adopting the AgileEVM method, wherein a card gets credit when it completes the value stream. Expectation is that while this will strongly encourage teams to complete work as soon as they start on it.
Hrishikesh summarized the session with three key learning:
1.      Telling people “Just do it” just doesn’t do it.

2.      Mindset issues as well as “Real issues” especially when the ecosystem is not agile.
3.      Coaching strategy needs to be agile as well – know when to persist and when to let go.