Category Archives: Kanban

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.

Advertisements

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.


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 info@aboutagile.com.  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 waffle.io

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.

Best2014

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