Tag Archives: Kanban

Attention to Quality gets Results

Most managers, and some ‘Agile’ coaches, I encounter shudder when the subject of quality comes up.  They think quality hampers delivery.   In some ways they are right, you do want to achieve balance, avoiding polishing too much because it can cause being late in delivery  (in mission critical projects it may be better to over polish if the cost of failure is high).

Some managers may shudder because, ooops I may have been found out and I’ve been pushing my teams to push out code which is not really ready.

Other managers, maybe the inexperienced ones but not always, have no idea what quality is.  They tend to believe the lies their development teams’ say when they say it’s ‘unit tested.’

As a manager, quality is one of if not your biggest concern.  Addressing quality is an economic concern as well and managers are responsible for economic outcomes.  Bad quality will slow down your team.  But not just that, it will also slow down your organisation.

How does this occur?  How does it slow down your organisation?  Well I’ve seen this time and time again when I come to a new client.   Work is at a stand still and when I dig a bit deeper I see the same issue appear.

Yes, teams are overwhelmed with work.  So limiting WiP will help.  Using workflow mapping and lean techniques will identify bottlenecks.  Yes address those.   Importantly, in the bottlenecks I find that the reason for those delays is the negative feedback of poor quality.

I see upstream, product ideas waiting to be developed and tested with the customer because there is a wave of poor quality slowing down the delivery pipe.   Overwhelmed with defects teams struggle to pull new work into development.  When they do eventually pull that work in, it is developed with such poor quality or worse the facade of quality (e.g. formal QA) that it further feeds into the negative feedback loop.

That loop gets even slower to run such that it turns into ‘3 month Stabilization’ phases or an entire quarter whereby the organisation freezes any new releases into production to avoid an outage.

These sort of mitigating steps often occur after some sort of disaster has occurred which has its root cause in poor quality.  One big example is releasing a new version of software such that it shuts down an assembly line at a factory and affects thousands of customers who are prevented from using their mobile devices.  The cost there was millions of dollars.

So asking for quality is easier said than done.  Or does it have to be that hard.  Usually workers are over-burdened.  So limit WiP as was mentioned earlier.  But then ask for quality.  Now that they are not over burdened they can put their efforts into producing quality output.

Give teams the space to improve and they usually will.  Sometimes as a coach I can give them some training and they will do it all by themselves (this interview demonstrates this) to a point, and sometimes being involved with them is needed from the outset or when levelling out or stalling out occurs.

In my experience, results can happen very quickly.  For an organisation I was recently involved with it took three months to go from a cycle time per feature of 40 days to 3 days.  This involved addressing quality and bringing in aligning practices from extreme programming and specification by example.  Reducing WiP and batch size also assisted.  This happened in stages, guided by data from a Cumulative Flow Diagram that mapped the stages of delivery and guided improvement efforts.  The first stage got it down to 9 days (by applying WiP limits, Policies on size and changing the Test Strategy) and then, the next stage, amplifying the unit testing practices to remove an archaic and slow UI testing bottleneck (sunk cost fallacy associated with that) really accelerated the flow of work.

AgWorld, the published case study, did it in 6 months.  They did chose to do for themselves which is fine.  They can achieve a lot more with a coach who can bring the practices quicker and help avoid stagnation which does tend to happen as well.

Find a slow process, you more often than not find poor quality.  Address quality and just observe how things get better for everyone.

 

Advertisements

What makes you Fit for Purpose?

Can someone answer this question?   Well yes, I can help.  In short it’s what you do, be that individually but mostly in a team, to ensure anyone you serve receives the service you provide in a reasonable time frame with appropriate quality.

Where does that start?

It starts with understanding who your customer is.   Taking steps to learn about the customer and what satisfies them.  There are some tools available to you to help like Customer Surveys, Customer Interviews, Customer Empathy Maps, Personas and going to see for yourself.

Somewhat lagging but still providing information about the customer and their needs ( which can and are probably changing) is a Net Fitness Score which is an alternative to Net Promoter Score.  If you are producing software you can add code to capture data about how your customers are using the application.  This is is part of a process called instrumentation that is done to computer programs.

This takes us into the area of measurement.  In addition to customer measures, a team can also use other metrics to ensure delivery is just right.  By just right, we mean that any feelings of over-burdening (muri) are minimised to ensure that a team can sustainably deliver work.

Here some measures include, service response times (cycle time) for the different types of requests a team gets.  Are we able to deliver those reliably.  By reliable we mean within the realms of probability and not exact measures.  Knowledge Work being naturally variable in nature we tend to defer to probabilities like a Service Level Agreement. 85% of the time we can deliver in 3 days as an example.

In aiming for better on-time delivery you may need to eliminate muda or wasteful activities.  You may find amplifying collaborative activities and learning new skills will help. These type of improvements stem from understanding the nature of different requests like demand (high and low periods), expectations of quality and when request are expected to be fulfilled (Cost of Delay).

Another measure is acceptable defect levels, with the aim to reduce these to a negligible level.  Defects may need to be balanced with responsiveness.  If you require greater responsiveness then Fit for Purpose may mean acceptance of higher failure load (another name for total defects).  Responsiveness may also mean less predictability and some work may have an have a wider range of delivery date performance.

If failure load is high, then addressing some level of quality can also have a bearing on on-time delivery.  In software development that means ensuring little or no technical debt.  High levels of technical debt lengthen cycle times as a team looks to deal with the complexity of software laden with technical debt.   Continually reducing and maintaining low levels of technical debt will help maintain reliable delivery.  It will also allow innovation to occur because the team is freed from the burden of low quality.

Addressing these and becoming reliable means you will have confidence to communicate service level expectations within reasonable levels of probability.  Doing this with appropriate quality will often result in plaudits to the team and reversing what may be many sources of dis-satisfaction for the customer and team a like.  Find out what makes your system of work Fit for Purpose.  Work hard on reaching that level.  Agility will be a natural result.


The Importance of Shared Purpose

My latest blog is actually one written for my employer here in the United States, Code Genesys.

You can take a look at it here and is on the importance of shared purpose.  Keep practicing that because it’s hard for first timers and anyone whose experienced for that matter.  Well worth the investment in time 🙂

I have an example of a company who go to great lengths to maintain their purpose.  An old blog article written 2 years ago.


Where’s the teamwork when we can’t see each other

I’m an Australian working in the USA coaching highly distributed teams. We speak English but even then there are slight differences, like Australian English and American English and even within America like from South to North.

We find it’s hard to get people to use video cameras. They are cheap however the culture tends to not encourage use of them. It’s always hard to collaborate at the best of times and distribution would be a good excuse not to do that.

Seems most distributed companies can’t get past just the phone and a little screen sharing.  When we use just these, we can’t see each other’s facial expressions and body language.  It’s hard to know how to react to feelings and we have to assume or turn up our intonation sense when listening (perhaps even speakers and listeners can make more us of their voice to relay feelings).  Another big issue is having attention – where I work inattention is called ‘multi-tasking’ and we know that don’t work.

Overall, this is more a problem around the difficulties in collaborating and the fears around that.  We’ll need to work on that to allow the tools to be useful.  Make it safe.  Create the culture and camaraderie of teamwork and reward that.  Highlight even when people are doing things that harm teamwork via a team working agreement.  Realization can quickly occur after that and a team can self correct.

Then there is technology, my friend Agile Bill Krebs, is teaching and coaching on tools to assist the distributed work place.  There are simple tools like join.me which is down the low end of the spectrum through to immersive environments like Minecraft.

The technology is there – it just needs a willingness to try using it and adapting to use it to it’s utmost advantage.

Your last resort is to abandon the distributed model.  That can be avoided I suggest.

 


The Ladder of Leadership and Kanban

Here’s a comparison of David Marquet’s Ladder of Leadership which derives from his work as a nuclear submarine captain and writing his book Turn the Ship Around and then subsequent workshops and writings and the Kanban Method.

The Kanban Method says start where you are.  Other frameworks require a more explicit transformation to new roles and ceremonies.  The Kanban Method also says Improve Collaboratively and Evolve Experimentally (using models and the scientific method).  Of it’s 9 values it also states Leadership.  Acts of Leadership from every level.

A model that you can use to improve and create leadership from everyone is called the Ladder of Leadership (although not explicitly steeped in the scientific method, it is a model).  It starts where you are.  Everyone, and this doesn’t matter what position one holds, is looking to be told what to do.  This is where mostly everyone is.

The Ladder of Leadership recognizes this.  Everyone can use the model as a frame to help each move up the ladder to become more intentional.  By recognizing where someone is on the ladder whilst in conversation, a colleague can frame a question using the next rung on the opposite side of the ladder.

The Ladder of Leadership – Capt. Marquet

Measurement of success comes via a proxy from other measurements like faster cycle times, better quality (less failure demand) and people should be happier and if they aren’t something is still awry.

It takes some time to achieve this.  One must be prepared to stay the course despite the bumps in the road.  If it doesn’t work on one occasion, reflect upon that.  Realize we are humans, have a laugh and try again using what you’ve learnt.  The ultimate aim is to create leaders not followers.  Leaders can relieve bottlenecks and fix problems quicker and with more knowledge than someone further away from the problem.


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.


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.