Tag Archives: Kanban

Avoid the Workflow Masquerade

Here’s a tip for scrum teams.  You are almost certainly using a task board.  If not start today.

That task board typically consists of the standard TODO, Doing, Done style.  Sometimes you will see the Doing column divided up even further – some mature teams realise that but a lot don’t so here comes the tip.

Simple Board

Typical Simple Board

In doing sprint planning or planning for a User Story the team identifies a number of tasks required to complete the story.  For example, perform detailed analysis, code the UI, code the business logic, perform testing.

It turns out to be quite a laundry list of tasks.  Within that list is always a pattern.  That’s right always.  All your user stories almost certainly involve a component of analysis, coding and testing.

So the tip is to make that visible and stark to everyone viewing your board.  Evolve from the three column format of ToDo, Doing and Done and divide that Doing column into Analysis, Code and Test.

More Workflow Board

Go for this.  Workflow is visible

Whilst your at it, define some common policies for those columns.  For instance for coding – code and test UI, code and Test Business Logic layer and so on so forth.  That’s called your Definition of Done.

What does this do for the execution of the sprint?  Here are several things it can and should do.

  • Sprint Planning becomes more focused on asking real pertinent questions about what’s coming up rather than diversion on getting the laundry list together.  You could really ask the what if questions of the Product Owner and making a deeper start in technical implementation details and discerning the risky parts of the work.
  • Make the flow of work more visible.  This will increase the effectiveness of daily standup.  Speaking to the cards on the board and seeing where they are at, how long they have been in a part of the workflow causes more transparent and focused discussion of the work.  Of course the team should be willing to discuss the reality of the situation and some will refuse to do that even when it’s staring them in the face.  Note:  This is when the real rubber hits the road – the Scrum Master, Agile Project Manager will be willing to seek out help the team discover the causes and deal with the organisation impediments.
  • Show the real time for each part of development.  This can help the team improve on specific problem areas.  Because there is real data for each point of the process, the team can choose where to focus their improvement efforts to decrease the overall time to deliver.

So you may ask.  Is this Kanban.  The simple answer is no.  A Kanban System has more components – most importantly WIP limits on workflow steps.  However use of a these ideas more readily found in Kanban systems will still create visibility.  Evolution to more flow based systems could be an end result or perhaps just a hybrid like Scrumban.

So avoid the workflow masquerade.  Make those tasks into workflow and get on with real work.

Advertisements

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.

Board

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.

Conclusion

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 (heathcare.gov).  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.


Review: Scrum Product Ownership by Bob Galen

As Bob rightly says there’s not a lot of coherent writing on the role of the Product Owner in Agile.   One of my previous blog posts outlined the importance of the role, but then also provided links to find more information from guys like Roman Pichler, Mike Cohn and James Sutherland.  Scrum Product Ownership: Balancing Value from the Inside Out is one of a couple of books that attempt to give pragmatic advice on the role of this pivotal and important part of the agile machinery.

Pragmatic is the operative word.  Bob sensibly applies the knowledge and thoughts of others including current sparring partners Ken Schwaber (Scrum.org) and Dean Leffingwell (SAFe).  All ideas are up for grabs it seems including his own.  He quite obviously, to me at least, doesn’t remain dogmatic to one particular point of view and applies ideas as appropriate to the context at hand.  This is a good thing, and in such a guide the reader needs to be informed of the best thinking from all points view.

Bob is candid also about previous writings shortcomings as well.  For instance, the role of Product Management is quite large and Product Ownership only deals with a portion of the activities of Product Management.  Therefore it’s important that there be symbiosis between the two roles and not a hand-off.

I also like the idea of no single wring-able neck.  The PO can be assumed to be person in the gun when things go wrong.  I also do not hold this view as it’s the team who are collectively accountable and in fact usage of the term in my opinion is an anti-pattern and indicative of something wrong in organisational culture.

And to further add to the pragmatic nature of the book, there are many practical tips.  Bob talks a lot about management of the backlog more than the a list of items.   For example, I like his 20/30/50 rule for backlog refinement.  That is the top 20% or product backlog items should be at or near a level of detail for it to be immediately pulled into a sprint when required.  Meaning work to groom these items is constantly occurring driven by the PO with expected assistance from the entire team.  And by near enough ready there are 30% left during the sprint to fine tune and make new learning as work progressing which lines up with Scrum Guide statements.

Overall, the book emphasizes the immersive and totally involved nature of the PO role.  This is backed up with concrete examples of the types of activities required for success.  From this it can be seen that it is a full time role that needs firm backing and support from management.   I’d recommend it for the reading list of upper management as well.  It’s easily read and not overly long so can be read in a few sittings.


Project Phoenix: A light introduction to Systems Thinking, Theory of Constraints, Lean –> DevOps

 For me this was not a great read despite the hype surrounding the book.  But don’t let that stop you from reading this book.  In fact if you are interested in learning something about Systems Thinking, Theory of Constraints, Lean and Kanban this is the perfect introduction in the form of a business novel.

Now a novel is usually read for enjoyment, but I found the rubber doesn’t hit the road till about Chapter 14.   It’s a bit a long introduction til we start getting into solutions.  Then it starts to shine and the disaster looking like having a horrible death goes through a remarkable transformation.

Again if you’re not familiar with any of the concepts this is a great introduction.  If you’re interested in improving the state of your workplace grab yourself a copy.  It’s especially important for demonstrating the need for a more symbiotic relationship between all parts of service delivery and hence the rise of DevOps.


Is Age an Issue with Agile and Lean Improvements

This past Monday we were treated to a fantastic talk from Joakim Sunden who is an Agile Coach visiting from Spotify.  There were many great talk aways from the talk which you can read about here in the article Scaling Agile at Spotify.

The article talks about the scaling model at Spotify from Squads -> Chapters -> Tribes -> Guilds (not strict linear and hard boundaries).  All great stuff, however a question from the audience got me interested.

The question from the audience was something along the lines: ‘How old are the people at Spotify?’

This drew a pause from Joakim, not really expecting the question I suspect.   He drew breath and said that they we all younger than himself.  Now Joakim is not old, in fact I’m older, and he wears a funky hat, tshirt and sneakers.  He looks younger than he is, he later revealed his age and it was 39.

But this has got me thinking.  Why would someone ask a question like that?  Is it because it’s because as we age we become less amenable to change.  I was shocked to think this.  I regard myself as reasonably progressively and I’m actually a little annoyed that these better and more humane practices for working in software development are still taking so long to take hold or worse not applied correctly (flaccid agile).

It would seem that the younger generation are more inclined to take on these improvements.  One can even go so far as to say that Spotify could not have succeeded without a younger person’s mindset.  This mindset in more attune to Lean Start-up and they carry on the Lean Startup philosophy now that they are a larger company with 300 or so people.   If we were to apply traditional thinking we would not be enjoying the great product Spotify provides today.  In fact there are numerous sorry stories of venture capital funds being used up on starting a company without actually producing a product.

So older companies and companies that stick with older styles of working could be in trouble.  Not right now, but lets see in 5 to 10 years time.  It seems apparent to me at least, that these older companies aren’t changing because of the older people running them (yes a sweeping generalization).  We would like them to change for a number of reasons but is Age a barrier?  Do we need to wait for the next generation to come through?

Now I’m not proposing any fast fix to the problem, if indeed it’s perceived as one.  Going back to the questioner in the audience, his question seemed to implicitly assume an age hierarchy and that because older people were still present we could not progress with these changes out of ‘respect’.   Respect for people is a core component of Lean Philosophy and is called out explicitly in Agile Methodologies as well like eXtreme Programming.  Here is just one suggestion for a way forward.

Provide Safety

Allow mistakes to occur in small batches and ensure learning occur.  Toyota used the Japanese word – ‘Anzen’ which means safety.  This word will become more well known going forward.  Joshua Kerievsky is his company Industrial Logic is a major driver for this.

Will be writing some more about this in upcoming posts.