Category Archives: Kanban

Moving to the United States

An opportunity has arisen for me to travel to the United States to help out with a large transformation using Scrumban (combining Scrum, Agile and Lean Kanban).  CodeGenesys a company that specializes in consulting in this area has invited me to come over and help out with the transformation at a large Health Insurance company.  CodeGenesys also make a online visualization board called ScrumDo which I have written about in the blog articles Managing work with ScrumDo – Part 1 and Managing work with ScrumDo – Part 2.

About Agile still operates and the courses and training are still available.  They will be available on an as needed basis in Australia and elsewhere and will be subject to my availability.  So inquiries are still welcome. I hope to give training in the United States as well.  I will look to schedule public classes again after settling down in the US and the picture becomes clearer.

My relationship with CodeGenesys will be a symbiotic relationship.  I hope to learn a lot from my secondment to the US  and spread new knowledge on my return back to Australia.  Training from CodeGenesys will be combined with the About Agile courses to offer a greater suite of courses.

These will combine with consulting and coaching to provide a full array of services to help out with transformations and ongoing improvement efforts.

My time in the US will be at least 6 months and depending on conditions could go on for longer.

Please stay in touch through my email address  I tweet through the handle @n_zdunic.


Managing work with ScrumDo – Part 2

Continuing on with a series on ScrumDo, a board that is not as well known but sure to still gain more users especially for those that want to evolve their Scrum implementations.  You can read first article in the series here.

In this article I’ll present some extra features that I’ve discovered over the course of running several sprints over a couple of projects.

Multiple Sprint/Iteration View

In this screen shot we see multiple sprint views.  Selecting from the drop down we can check the iterations/sprints we’d like to see visible at one time.

Can view multiple sprints

This is been useful to move incomplete stories into the next sprint and to get a view of sprints over a release.  Here’s an example:

Use Multiple Sprint View to move to new sprint and some items into the input queue

Exceeding a WIP Limit

Here we can see the Doing/Done column has had it’s Work In Process (WIP) limit exceeded with the WIP value shaded in Pink.  This means I should really be pulling into Reviewing.

Done Column exceeded - need to pull into review - found I didn't need 52 as such because I was documenting as I went

I found that a the Doing/In Progress column WIP limit, based in Story Points, was too low.

Exceeding a WIP limit - will need to adjust it's too low

I eventually increased the WIP Limit as shown here:

WIP now set to 4 SP (If I stop using SP then I would have to switch to cards)

Scrumban for more flow

I found that I could progress to a more flow based replenishment of work, still within the context of a iteration.  No it’s not Scrum, it’s ScrumBan – at least I think it is.  I’ll leave it to others to decide on what is ScrumBut or ScrumBan (please leave a comment).  Teams can work out the best process for themselves from a sound basis.  In another project with another person we find this style works a lot better for the context we are in.

Scrumbanning - pulled in from Input Queue - fastidious scrum wouldn't permit this

Tasks can be Visible on the Board

A colleague and I found that having tasks with a story visible in some columns aids in visibility.  We used the board editor to amend the doing column to have this.  You will also notice buffer columns added to more visibly display that items were ready to be pulled into the next part of the value stream.

Reorganizing for Sprint 3 - partway through

Now for some Requests

Acceptance Criteria

It would be nice to have an explicit area for Acceptance Criteria.  We utilized the comments to achieve this, however it’s easy to lose them amongst the other comments.

Would be nice to have a section for Acceptance Criteria with Checklist, using Comments for now

Story turned out to be an Epic – keep the comments

Sometimes stories are too big and you do not realise this until later.  Now this can be tackled by improved story breakdown and this does happen, however stuff happens and things slip through.  I had one such episode where I had several comments against a story.  These turned out to be more like splitting comments, so I wanted to convert the story into an Epic.

I did this but I lost the comments as a result.  There were quite a few.  The friendly support staff restored a backup but it was too late.  My changes occurred with the window between backups.

Cool Features yet to be tested

ScrumDo has extensive integration with other tools.  GitHub integration looks cool, up against other tools that do this as well like

GitHub Integration 1

In upcoming posts I’ll show some more features like the reporting capabilities.  For example Cumulative Flow Diagrams.

A colleague has told me that he is liking ScrumDo.  It has more flexibility than tools like TFS.  Still some quirks, but overall we are pretty satisfied with the experience.

Best Posts for 2014

Reflecting back on this past year of blogging I’d thought I’d summarize the best posts of the year.  Some have been controversial and some have garnered a lot of interest.  I find the act of blogging helps me think through mental models.  They may be wrong and putting them up for scrutiny helps correct them or reinforce those models if mostly correct.

There was some 80 posts created this year.  Some of them are long at 2000 words or more and take a few hours to create.  Getting started on those can be difficult but then satisfying in the end.

The Most Popular

My review of L.David Marquet’s book Turn the Ship Around was the most popular mainly because my review was heartfelt.  The book really connected with me and the author also tweeted it and refers others to it for a summary.  My series on Personal Kanban was quite popular as well.


My Favourites

Again, my review of Turn the Ship Around is a favourite. My review of a Lean Enterprise presentation by Barry O’Reilly and Gary O’Brien was more controversial but still earned a like from Barry O’Reilly.

The Controversial Ones

The review of Lean Enterprise got at least one visceral response.  I also wrote about my feeling of dysfunctional teams after seeing the Hangover Picture constantly posted on LinkedIn.  I feel this got criticized for the wrong reasons as those criticisms ignored the feeling’s of myself and others and negated them by saying that those feeling were not valid.  This is in fact poor leadership and disregards the role of dissent in correcting incorrect behaviours.  It reminds me of my policy on listening, in my Policies section, which I feel many people struggle with.

The Unloved Ones

I really enjoyed interviewing Tadhg McCarthy of Adapt By Design.  Culture eats strategy for breakfast as stated by Peter Drucker.  This interview should have received more exposure.

Honourable Mentions

There are some more reviews in the Reviews section of my blog.  Reviews of Slack by Tom DeMarco and Scrum Product Ownership by Robert Galen deserve a mention.  My blog also paid more emphasis of the human side of work.  This article at the beginning of the year is one my my personal best, admitting that we all need to be better.

Some articles on improving work practices were included this year.  I quite liked this one on the role of the Business Analyst in the Agile Team.  Being prepared to fail and recognizing that this is a valuable thing was touched on in this article on my experience with Test Driven Development.

Looking forward to a new year of blogging in 2015.

All the Best – Nick

Agile and Lean Bookshelf

Some books on lean and agile software development.  The list is still in development.  I’ve read all of these books and will not place books here that I have not read. Some books resonate more than others, but still don’t expect instant recall of all the detail – rather the key ideas and concepts and then drive into the detail if required.

You’ll find some books are relevant to more than one section, so they will be repeated in the sections in which they have relevance.

The Lean and Lean Startup Side

Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated  The archetype Lean book for the Western Reader from leaders in the field. Real life case studies of people over process.
This is Lean: Resolving the Efficiency Paradox
Running Lean: Iterate from Plan A to a Plan That Works (Lean Series)
Kanban: Successful Evolutionary Change for Your Technology Business  Start with this for Kanban, let it sink in, read others and then come back to this.
Leading Lean Software Development: Results Are not the Point
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
The Goal: A Process of Ongoing Improvement
Kanban in Action  I nice start for those wanting to learn about Kanban, don’t ignore David Anderson’s book though!
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win  Systems Thinking for IT People.  Be nice to those Brent’s they only work in a system.
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Personal Kanban: Mapping Work | Navigating Life
Lean-Agile Software Development: Achieving Enterprise Agility
Lean Software Development: An Agile Toolkit
Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale

The Agile and Lean Frameworks Side

Essential Scrum: A Practical Guide to the Most Popular Agile Process (Addison-Wesley Signature Series (Cohn))
Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Addison-Wesley Signature Series (Cohn))
Kanban: Successful Evolutionary Change for Your Technology Business
Scrumban – Essays on Kanban Systems for Lean Software Development (Modus Cooperandi Lean)
The Scrumban [R]Evolution: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series)
Real-World Kanban: Do Less, Accomplish More with Lean Thinking
Agile Project Management: Creating Innovative Products (2nd Edition)
Agile Software Development with Scrum (Series in Agile Software Development)
Kanban in Action
Agile Project Management with Kanban (Developer Best Practices)
Agile Project Management with Scrum (Developer Best Practices)
Lean from the Trenches: Managing Large-Scale Projects with Kanban
Kanban and Scrum – making the most of both (Enterprise Software Development)
Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust
Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series)
Lean Software Development: An Agile Toolkit
Succeeding with Agile: Software Development Using Scrum
The Art of Agile Development
Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise (IBM Press)
Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series)
Scaling Software Agility: Best Practices for Large Enterprises
The Software Project Manager’s Bridge to Agility
Scrum and XP from the Trenches (Enterprise Software Development)
Actionable Agile Metrics for Predictability: An Introduction

The Technical Side

Domain-Driven Design: Tackling Complexity in the Heart of Software
Pair Programming Illuminated
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Agile Testing: A Practical Guide for Testers and Agile Teams
The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)
Clean Code: A Handbook of Agile Software Craftsmanship
Code Complete: A Practical Handbook of Software Construction, Second Edition
The Pragmatic Programmer: From Journeyman to Master
Growing Object-Oriented Software, Guided by Tests
Agile Software Development, Principles, Patterns, and Practices
Patterns of Enterprise Application Architecture
Refactoring: Improving the Design of Existing Code
Refactoring to Patterns
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
Continuous Integration: Improving Software Quality and Reducing Risk
Test Driven Development: By Example
Pattern-Oriented Software Architecture Volume 1: A System of Patterns
Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
Design Patterns: Elements of Reusable Object-Oriented Software
Extreme Programming Applied: Playing to Win
Writing Solid Code (20th Anniversary 2nd Edition)
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
Working Effectively with Legacy Code
Dependency Injection in .NET
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The Product Ownership and Agile Requirements Side

User Story Mapping
Scrum Product Ownership: Balancing Value from the Inside Out
Working Effectively with Legacy Code
User Stories Applied: For Agile Software Development
Agile Estimating and Planning
Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn))
Impact Mapping: Making a Big Impact with Software Products and Projects
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
The Principles of Product Development Flow: Second Generation Lean Product Development

The Agile Tester Side

Agile Testing: A Practical Guide for Testers and Agile Teams
More Agile Testing: Learning Journeys for the Whole Team
The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)
Testing for Continuous Delivery with Visual Studio 2012 (Microsoft patterns & practices)
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))
Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (Net Objectives Lean-Agile Series)
Specification by Example: How Successful Teams Deliver the Right Software
Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing
xUnit Test Patterns: Refactoring Test Code
Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing
Effective Unit Testing: A guide for Java developers
The Art of Unit Testing: with Examples in .NET
Pragmatic Unit Testing in C# with NUnit

The People Side

The Five Dysfunctions of a Team: A Leadership Fable
The Introvert Advantage: How to Thrive in an Extrovert World
Emotional Intelligence: Why It Can Matter More Than IQ
Fearless Change: Patterns for Introducing New Ideas
Turn the Ship Around!: A True Story of Turning Followers into Leaders
Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))
Peopleware: Productive Projects and Teams (3rd Edition)
Drive: The Surprising Truth About What Motivates Us
Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency
Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
Death March (2nd Edition)
Agile Retrospectives: Making Good Teams Great
Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision
The Core Protocols: A Guide to Greatness
Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers
Dynamics of Software Development
Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)
Project Retrospectives: A Handbook for Team Reviews
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
Who Moved My Cheese?: An Amazing Way to Deal with Change in Your Work and in Your Life
The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
Liftoff: Launching Agile Teams & Projects
The Fifth Discipline: The Art & Practice of The Learning Organization
Switch: How to Change Things When Change Is Hard
Start with Why: How Great Leaders Inspire Everyone to Take Action
Team of Teams: New Rules of Engagement for a Complex World
Principles Of Software Engineering Management
Emotional Intelligence 2.0
How to Win Friends & Influence People
Smart Questions: The Essential Strategy for Successful Managers
Great Boss Dead Boss Recommended by David Anderson in KCP Training. A model of identity.
Lessons in Agile Management: On the Road to Kanban
Thinking, Fast and Slow Science on how parts of the brain work. Involuntary vs Logical parts
Nonviolent Communication: A Language of Life, 3rd Edition: Life-Changing Tools for Healthy Relationships (Nonviolent Communication Guides) Judging or helping? Which is more helpful?

 The Organisational Side

Reinventing Organizations
Team of Teams: New Rules of Engagement for a Complex World
Maverick: The Success Story Behind the World’s Most Unusual Workplace
The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer
Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results
Why Plans Fail: Why Business Decision Making is More than Just Business (MemeMachine) (Volume 1)

 The Coaching Side

the act of coaching is distinct from the People and Organisational Sides although strongly linked

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) It’s a start but it won’t be enough
Executive Coaching with Backbone and Heart: A Systems Approach to Engaging Leaders with Their Challenges For real meat on the act of coaching. Years of experience here
Co-Active Coaching: Changing Business, Transforming Lives More meat on the idea that people have the ability to solve/change/improve their lives. Partnership wit a coach
The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever A good start, go to other sources still for more detail
A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas Build that muscle of inquiry first before jumping to a solution
Flawless Consulting: A Guide to Getting Your Expertise Used A consultant’s book every coach should have!

Managing work with ScrumDo – Part 1

ScrumDo is another online tool for managing work.  It competes in the space of tools like LeanKit, Jira Agile, Kanbanery, SwiftKanban and a host of other tools from other vendors.  The differentiation it appears to me, is that ScrumDo is slanted to a (outright) ScrumBan view of the world, combining aspects of Scrum and Kanban in what could be a much stronger product than some other offerings out there (my experience is only with LeanKit, Jira Agile and TFS/Visual Studio – not a huge amount :)).  You could run a Scrum, Kanban or a ScrumBan – and you can in other tools for that matter, but the features in built in ScrumDo make it appear or feel more targeted to this.

Here in Part 1 of a series of posts I describe the setup of the first iteration of a project I’m currently running.  In a previous post on LeanKit, I noted that I lacked a proper breakdown of tasks for big items on my Personal Kanban that was causing some morale issues – although I did get to end with flying colours, it’s not a way of working I recommend.

Note: I include many screenshots.  I recommend clicking on the image to get a clear view if you so desire.

Cleaning up the Previous Board

I did a board for the previous project but it fell into disuse.  I decided to clean it up.  The standard board presents two horizontal lanes, an Expedite Lane which anyone from a Kanban background will recognize and a lane for the current iteration.  Here’s what I started with and you can see the expedited column is blank.  It’s hardly used and I didn’t want to use it so a later view you will see that I removed it.


I used the Iteration Planning Tool to move items, but you can also use the above view:

Iteration Tool - Movinf Current to Completed

Cleaning up the Board – the Board Editor

I removed the Expedite column in the Board Editor, a view of which is shown here.  Subsequent to this I’ll show later on some other edits that include WIP limits, effectively ScrumBan-ing the board, and adding policies under the columns like Definition of Ready for stories and Definition of Done for development  tasks.

Editing the board - want to remove the Expedite lane for this project

Epics and Stories

The first thing to do was create the Epic and Stories.  I’m following standard scrum backlog grooming practice and I created the Epics and Stories.  As this a project to create course material for an ICAgile accredited course for my company, About Agile, the Epics and Stories followed the layout of the ICAgile learning objectives for the most part.  Easily filled in – not a big Release Planning session required for this project 🙂

There are a number of views for creating Epics and Stories. Here is the Backlog view:

Adding Stories to New Iteration

And here’s from the Epic Planning View:

Epics planned out - feels like 2 to 3 two-week iterations worth of work

Sprint/Iteration Planning

With a Release plan created (though Epics and High Level Stories and no more) it’s time to create the first sprint/iteration.  The first iteration was already created as shown above and is also a way to setup an iteration.  There is also some setup that can be done – interestingly one can set resource availability in hours – I wonder if this fits in with #NoEstimates 🙂 , something for later. The steps correspond roughly to part 1 of sprint planning as you’ll find in the scrum guide.

Iteration Planning - Resource Allocation

Along the way you may find that you need to change things around.  For instance I needed to to convert a story into an Epic (I’m playing multiple roles being the only person on the project – PO and Developer and ScrumMaster):

Converting Story to an Epic

I also had to move a story between Epics.  This can be done in the Edit Story view.  Notice standard Fibonacci Series relative estimation can be changed here (as well as elsewhere):

Move to another epic

And also through a specific view that converts a story to an Epic.  In this example I found I needed further breakdown and hence converted the story to an epic:

Converting Story to an Epic

Sprint Planning Part 2 – Some Task Breakdown

Here I’ll show some view that allow the first few items of the sprint to be broken down.  I don’t break down everything as the July 2013 version of the Scrum Guide guides us to do.  I just setup enough to get going and start producing, also leaving some room for the innovation.  This view shows I’m actually working on the sprint planning tasks:

Planning, cycling between choosing and how to do the work

And this one is showing how desperately hard I’m trying to think of the tasks that may be required for a task.  Inevitably there will be something I missed:

Tasks - trying to think of everything

and as always – I try and use a pomodoro/tomato timer – I sometimes forget that as well.  Here I’m taking the time to take a break during sprint planning, but maybe if your doing this in a group you’d space the pomodoro to longer than 25 minutes:

Taking a Pomodoro Break during Planning

Done some editing of the board whilst I created the Sprint Plan

Here I present some editor views.  As I was creating the plan and learning the features available in ScrumDo I changed things to suit the desired way of working.  Here I removed the Expedite horizontal lane and added WIP limits.  Most columns use points for limits except the Done columns which are using card count to force a pull into the next column of the value stream.  Will see how that pans out.

View of new Board with WIP Limits and removed Expedite Lane

In this view I’m adding a Policy and a WIP limit for the TODO column.  This view is accessible via the board editor:

Adding Policy and WIP Limit for TODO column

So I got to the end of editing the board and sprint planning and the board took more shape with the first 4 tasks, the most important, having been broken down:

Created Tasks for first few days of the sprint

Advisable to have a Sprint Goal

Yes you need a milestone to aim for and I recorded mine as part of the sprint planning task and used the time recording view to keep track of the time I spent.  As far a time spent, I’m not really sure I want to 1. Give a time estimate and 2. Record it.  Fighting off Parkinson’s Law and Student Syndrome is already hard enough.  Time estimates can be taken as targets and both of these dysfunctions can kick in.

Added the Sprint Goal as part of Planning

Tracked time for Planning - but you should save any edit before doing it as I lost my sprint goal comment when I clicked first time

Extras: Policies show up as tool tips

This policy is quite big and not easily view-able.  Not a big issue.

Policy Defined for Doing Column - possible issue with tooltip to fix

This one looks better, not so big:

Definition of Done for the Review Columns

So at the End of the Day

So I did my sprint planning and fixed up the board as shown above in the selection of screenshots.  I made a start on the tasks and found that having the smaller milestones and thinking about tasks drove more satisfying outcomes.  The experience of the previous work, which I’d not done before, was a good input and I have adapted from those experiences.  Having something to aim for what certainly helpful on this first day.

New projects almost always start off a bit haphazardly as all participants find their feet.   This really is dependent on how new the domain is and team forming attributes of a new team The trick to to reflect and adapt, something all too often forgotten or put in the too hard basket.  It’s OK to feel unsure at the beginning, but don’t let this drag on.  Take action to remedy the situation.  It may take several goes at it, but as long as a culture of safety exists, you should be able to take out some very valuable lessons and this is very important to build further from.

Here’s the board at the end of today for this project (BTW: this task, to write this blog, is on my personal board and not this one :))

In subsequently posts I’ll describe new features of ScrumDo as I come across them.  It will interesting to see what metrics and reports I can get out of it.

Status at the end of the first day - will not pull into review until we need to

Note: You can now read Part 2 of the series.

Visualize Life with a Personal Kanban – Part 3

After my last article, I said I’d be writing about the extra features available in LeanKit that allow metrics to be derived.  This will not be the only focus of this article.  I’m including my recollections of running my Personal Kanban over the last few months. Lets first start with what could be some problems.

Task Size

For the last 2-3 months I’ve been working on a project this has meant it has remained in the In Process column for this long.  Many of the other tasks are very short – they stay In-Process for hours at most.  Also when I’m reading a book this can stay In-Process for a long time.  This is also like projects and as I mentioned in Part 2 and cards like these are supposed to be a place holder for projects.

Is this really a problem then?  Maybe or Maybe Not.  Cycle time has been increasing as shown below in the Cycle Time graph from LeanKit.  I’ll talk about why this may be a problem, in so far as a Personal Kanban is concerned.

LeanKit CycleTime Increasing - June 18

 Is Task Size a Problem

Maybe, maybe not.  It could be how you perceive it.  For a Personal Kanban an average cycle time of 5 days might not concern you.  Maybe it would come back down.  Maybe it will find it’s average here and stay around the mark, reflective of the project work that is being done.

However, maybe an increasing cycle time could lead to the following types of dysfunctions:

1. Lack of Milestone Motivation

Finishing something creates a feeling of satisfaction.  Leaving big jobs in process means this satisfaction does not occur.  Feelings of ‘When will this be finished’ occur.  It then can feel hard to keep going and requires an extra bit of self motivation to keep going.

2. Procrastination

This follows from the first point.  Having a big job is more reason to avoid doing it, taking longer to get started.  Feelings of guilt might arise.  A uneasiness and even unhappiness can result.  Can this effect quality.  Perhaps, in my work has been validated to be of a very high quality.  However, for me, it has created a peaks of valleys in the emotional roller coaster.  One needs to wait to the end to get the feedback.  I did feel this emotion and asked to have a colleague look at my work midway through to validate it somewhat.  That was useful.

3.  Feedback

As mentioned in point 2, lack of feedback created feelings of whether the work was of a worthy nature.  Dividing the work in to separate smaller tasks allows feedback to asked for on a regular cadence.  I reasoned at the time that the project was a sole effort and therefore wouldn’t require such a rigor.  I think that was an error.  I think this is case for why Pair Programming is such a good practice.  Positive feedback on a constant basis should be paid back in better quality and better overall cycle time.

Don’t Put Big Projects in a Personal Kanban

Another solution is not to have big projects in a Personal Kanban.  Do they belong here?  You wouldn’t put your work projects on a Personal Kanban would you.  A project has more rigorous policies around ‘doneness’  Personal Tasks could be argued that they probably don’t have amount of rigor involved.

A project is a different Class of Service, mixing the two is probably ill-advised.  You’d rather feel good about what you are doing and having what you are doing traceable to the type of work you’re doing could help to reduce uneasiness around throughput.

Beware the Holding Pen

I found that my Holding Pen column was getting a little over used.  Long running tasks or putting off tasks is an indicator that the task is too big or just an excuse to procrastinate.  Consider a WIP limit to force resolution one way or another.

I also recommend having a WIP limit on the Ready Column.  I introduced one on this column to force me to do the work rather than have it for another dumping place for tasks, making it difficult to prioritise.  The dumping place for all idea still exists and WIP limit on Ready reminds me not to use Ready for these ideas, however ‘urgent’ stuff does tend to find its way there and stay there for some time. Maybe this limit can be revised down.

WIP Limit of Ready Column

Other Charts

Let’s talk about some of the other charts in LeanKit.  These charts are available in the Team and/or Portfolio editions and not available in the Free Edition.  They may or may not be useful in a Personal Kanban.

Card Distribution

The most interesting chart for me is the Card Distribution By Type.   I was a surprised at the amount of email I was sending at 15%.  This is not be confused though with the amount of time being spent on that task or any other task.  I tend to think my Project work is taking up more time than this 🙂

With the By Priority chart I find that I tend to allow most of my cards to be normal priority.  Rarely is something so critical that it needs immediate attention.  This may indicate that I’m not so rushed to get stuff done or a little lazy in setting the priority.  Setting priority is a fleeting thing for me, only a second or two for consideration.  It’s not a big deal.

The By Lane chart appears to show that I’m getting through work at a good rate, over 75% when you include Done and Retro lanes.  It would be even higher if I include the Daily and Weekly habits which cycle through ToDo, In-Process and Done on a daily or weekly basis.

Card Distribution by Lane June 18 2014
Card Distribution by Card Type June 18 2014
Card Distribution by Priority June 18 2014


Cumulative Flow Diagrams

Probably the most important if not most used chart in a Kanban Value Stream.  Here’s an early one.  It looks quite nice.  Seems to be getting through work quite well, this is before the big Projects entered the mix. Slight fattening of the In Process (green) band about 11 Feb 2014, only indicative of the size of the work but maybe also meaning that the work in there is too big – as I mentioned earlier this was a problem.

LeanKit CFD displaying Ready - Today - InProcess - Done - Retro - with Card Size


When viewing the chart without card size your get quite a different view as shown below.

LeanKit CFD displaying Ready - Today - InProcess - Done - Retro - without Card Size


In the next example you can see the full screen dialogue.  The bottom of the screen shows the lanes that have been selected for the chart.  This is important as I also have separate ‘small’ projects and Daily and Weekly habits which I didn’t want to include in the main kanban.  It does allow you to select separate parts of the board and do separate analysis, like on the Projects.

LeanKit - CFD - getting wary of fatening InProcess, Ready. Limit WIP - too big items in there


Efficiency Diagrams

These show allocation of work across the categories of Completed, Ready and In Process.  Lanes are allocated to these types and lanes which aren’t allocated fall into the Unknown bucket.

Below is the diagram that shows the percentage and it shows not significant variation.

Efficiency Diagram By Percentage

However this diagram by Queue Size shows a gentle increase indicating the larger items that were taken on.

Efficiency Diagram By Queue Size

However the next diagram calculates the same diagram but with card size included.  Overall I don’t read a lot into these charts from my board.

Efficiency Diagram By Percentage with Card Size


To check that I haven’t missed anything I went in search of other examples from elsewhere.  I found the documentation in LeanKit not providing a lot of clarity about how to use this diagram or not enough to make sense to me.  I did find something on their blog.  Quite interesting variations there.  Completion Rates weren’t very uniform as my examples suggest.  Looks like more complex work involved.  Could it also mean work was in different phases of the value steam.  Be interesting to compare the boards at these times.

There is another diagram called Process Control .  It doesn’t seem to work for me.  I revisit this blog entry when I work out what is wrong.


I find it enjoyable viewing work entering the board and progressing across.  All my ideas get captured as well.  I’ve fell into some traps but at least I can see them and I’m actively managing the situation to improve.  I’ve added columns, moved them around and tinkered with WIP limits and added some where I felt they were needed.  It’s getting better all the time.

Look forward to using this even more in other settings.




Customers Take Notice – Agile works when executed correctly

The litany of poor project delivery continues.  Yes these are poster children of the Agile and Lean ways of producing solutions.  Some agile does fail, but hopefully sooner.  Those that do fail can be tracked to poor execution of the foundation tenets of Inspection, Adaptation and Transparency and then others around these.  Others fail for good reasons!

The most recent grievous example of traditional delivery failing is ObamaCare (  In this story on Jeff Sutherland’s site we have a link to a Time Magazine article that is bringing Agile into the public domain even more.  Over the years there have been a number of high profile fix up jobs saved by Agile (FBI Sentinel, Medco are a couple).  I have my own as well but on a smaller scale, which I’d rather not go into detail here 🙂

One’s journey into Agile isn’t easy, but the costs of that journey are well worth it compared to the monumental waste created by traditional project delivery.

All customers need to take notice.  Some vendors don’t mind if you want traditional delivery – quarterly reports will look good for a good stretch.  Some vendors encourage Agile Delivery, don’t reject that, take a deep breath and take the plunge.  If your vendor is weak in Agility bring in outside experts to help the process work.  Politicians should be directing their government departments to go Agile.  Vendors should take a long term view and deliver quality to keep customers on board so winning the next tender is that much easier.  Paraphrasing Capers Jones , quality costs less in total cost of ownership.

The time for complaining about Agile (and Lean), wondering about what it about, is over.  Get into the books, take a course, join a user group.  Try using Kanban to ease in change.  Please do not react from ignorance if your knowledge is weak – find out more.

I firmly believe that the problems of traditional management (like Stephen Denning is talking about) can be alleviated by Agility.   Join in and help us continue to improve.  We are all still human and prone to our frailties, but lets recognize this and get on with it.  We’d like to avoid the waste, pain and litigation of the Queensland Health Payroll debacle.