Positive Incline Mike Burrows (@asplake) moving on up, positively

January 3, 2015

Two years on

Filed under: Books,Kanban,Values,Work — Tags: , , , , — Mike @ 10:45 am

I deliberately delayed the usual end-of-year review to today, the 3rd of January. It’s the second anniversary of my post Introducing Kanban through its Values and I was curious to see how well it was holding up. It is after all the seed that grew into my personal highlight of 2014, the publication in September of my book Kanban from the Inside.

Although the margin isn’t huge, I am not at all surprised to find that this two year old post tops the list of most-read pages of 2014:

  1. Introducing Kanban through its values
  2. Kanban Values exercise released
  3. My book: Kanban from the Inside
  4. STATIK, Kanban’s hidden gem
  5. Announcing Featureban
  6. “How deep” rebooted: values-based depth assessment
  7. Kanban: values, understanding & purpose
  8. Pulling change through the system
  9. A process of knowledge discovery
  10. Understand motivation for change

#7 is representative of 2013 – a followup to #1 and part of a journey of rapid exploration. The 2014 posts represent the fruit of that earlier work, ideas and tools rounded out and made reusable through the writing of my book. I’m thrilled that others refer to STATIK without my prompting (I declared it a success in July). The values exercise and Featureban are popular on slideshare. Matt Phillip flew across to Europe to describe (among other things) his company’s use of the assessment tool (see his deck The Kanban Iceberg; the video of his London talk should be available soon).

What does 2015 hold? For the next three months at least, more delivery management work with Valtech on UK government digital projects. Some private training classes no doubt, and (fingers crossed) a new 1-day public class “Inside Kanban”, probably in partnership with our growing community of UK-based training providers. I have other irons in the fire, but beyond March I’m still open to offers, whether it’s consultancy, training, or interim management.

In the meantime we’re moving house. A second foster daughter joined our family last year, and a Georgian cottage built into a Derbyshire hillside no longer meets our accessibility requirements. The new house is a bungalow on the edge of Wingerworth – still Derbyshire, but flatter and much closer to motorway and intercity railway links. Can’t wait!

December 30, 2011

2011: Another big year

Some highlights (the work-related ones anyway):

  • Feb: Set up Positive Incline Limited
  • Feb: Kanban Leadership Workshop (aka Kanban Coaching Workshop) with David Anderson in London
  • Mar-Sep: Continued part-time dev management role in Budapest, Hungary (and a big thank you to my former colleagues at Encore International, now part of M&C Energy Group)
  • Mar-May: Kanban consultancy in Johannesburg, South Africa as a DJA&A associate
  • Jun: The Kanban Leadership Retreat in Reykjavic, Iceland (#klris)
  • Oct-Nov: The Lean/Kanban conferences in Antwerp and Munich and the LESS conference in Stockholm (#lkbe11, #lkce11 and #less2011 respectively)
  • Nov: Speaking to my local (Matlock) business networking group about Kanban. Not just for techies! (#MBCnetworking)
  • Dec: Joined DJA&A full-time (more on that next year)
  • Dec: Leading my first 2-day DJA&A Kanban class in London

Top posts of 2011:

Older posts still going strong:

June 14, 2011

On remote coaching

Filed under: Kanban,lean,Work — Tags: , , , , , , — Mike @ 1:04 pm

This week I did my first Skype-based coaching session (my first at least as consultant rather than manager) and I’m pleased to report that it was a satisfying experience all round. An away-from-the-Kanban-board discussion avoids getting sucked into day-to-day minutiae; instead it’s an opportunity to step back, review and plan. It has a lot in common with the Agile retrospective, but a good model is A3: we need to get behind the annoyances and what may be over-personalised issues and work hard on finding the words to express root causes and potential ways forward in ways that lead to positive change.

Away from the board we can think bigger too. How can we work better with teams upstream and downstream? Are we involving the right people promptly and effectively enough? Can we help bring about higher level change that would have greater and longer-lasting impact on projects beyond our own?

Of course it helps immensely that I already know the client well, having working relationships and collaborative partnerships that go back several months, spending weeks on site (abroad) getting to know both the issues and the people. From the client’s perspective, it’s a cost-effective way to ensure that progress is reviewed regularly and that appropriate interventions are made before we get to the point where more hands-on support is again warranted (which will happen!). From my perspective, it creates the capacity to support multiple clients at once. Mutually, we learn from each other’s experiences and manage the peaks and troughs in demand. How very Lean!

February 28, 2011

Positive Incline Limited

Filed under: Kanban,lean,Project Management,Work — Tags: , , , , — Mike @ 9:38 pm

Not just a blog, from March 1st Positive Incline is a multi-client management consultancy :–)

My specialties:

  • IT/product development process design, organisation, operation and improvement
  • Kanban, Lean, Agile development
  • The design and implementation of business process and quality improvement initiatives

My biases will be familiar to regular readers:

  • Speed, flow
  • Transparency, visualisation
  • Observation, evidence, feedback loops
  • Continuous learning & relentless improvement
  • Customer focus (getting right behind the sources of demand)
  • Sound project/process economics

I come from a development background (I still love programming); a former development manager, product manager and leader of change initiatives.

My job is to help you understand your organisation’s systems more deeply (not just conceptually, but how they really behave in practice) and to help find both improvements and ways to keep them improving for the longer term.  Look elsewhere if you want an off-the-shelf solution laden with jargon or lots of acronyms!

February 13, 2010

Experimental: Pylons validation (un)decorator with JSON support

Filed under: Web Integration,Work — Tags: , — Mike @ 12:24 pm

In this gist (it’s not even a patch, just some stuff I keep in my app’s lib/base.by) is a refactored @validate.

On the surface it’s just the same as the standard pylons.decorators.validate:

    def update(self):

but it has been broken up into a number of controller methods, each of which is usable directly. So if you find the decorator inflexible, you can write your actions in the undecorated form

    def update(self):
            self._parse(request, schema=MyForm())
        except Invalid as e:
            return self._render_invalid(e, form='edit')

It’s more than just a stylistic change; in addition to the usual HTML form data it will also accept POST data sent in JSON and send back any validation errors in JSON too if the client so desires. The presence of JSON is recognized by an sent_json() helper that looks to see if request’s route had a format parameter set to ‘json’ (see previous post) or if the Content-Type header is ‘application/json’; responses work similarly via an accepts_json() helper, but checking the Accept header.

Throw in a render_json() helper and here are idioms for actions that will quite happily accept and produce JSON or HTML. First the traditional, decorated look:

    def update(self):
        if accepts_json():
            return render_json(a_json_serialisable_thing)
            return render('template')

And undecorated:

    def update(self):
            self._parse(request, schema=MyForm())
        except Invalid as e:
            return self._render_invalid(e, form='edit')
        if accepts_json():
            return render_json(a_json_serialisable_thing)
            return render('template')

The undecorated form is slightly longer — potentially addressed by sharing exception handling controller-wide — but it offers the intriguing opportunity to move some validation to the model &emdash; any Invalid exceptions raised in the try block will be rendered appropriately, regardless of where they came from.

October 6, 2009

Principles of Product Development Flow – review & retrospective


I have been encouraged by Eric Willeke and Alan Shalloway via the kanbandev group to share my thoughts on Donald Reinertsen’s new book Principles of Product Development Flow and I promised a review that would also serve as something of a personal retrospective. As book reviews go the result is probably a mess, but you can read clean & tidy book reviews elsewhere!

Why the retrospective? As past readers of my blog will know, I’ve recently undergone some significant change of late. I left behind a 12 year career in the City, took a very welcome 3 month break from work, and at the end of that time made something of a lifestyle change by moving well away from London to live in a cottage in the picturesque Derbyshire Dales. At the time we committed ourselves to the move I didn’t know exactly would come next but there was sure to be a Lean flavour to it, and during my time out I quickly fell in with the Kanban crowd. When I landed my new role it was clear that Kanban would feature prominently from day 1; two months have since passed…

Back to the book: it’s not about Kanban (though it is mentioned). Neither is it a book about software development (it’s much more general than that, though the specifics of software development occur frequently throughout the book). It is however a book that has shone light on both subjects for me – not as another methodology book, but by strengthening significantly my understanding of how development processes work in general, helping me to really understand why I’ve seen what I’ve seen in past projects (good and bad, mine and others’), and by helping me to crystallise how I can deal in an economically justifiable way with things that appear on the surface to be completely intangible.

To be more specific with that last thought, what excited me most about the book was the way it ties the management of queues – covered very well in their own right – to economics. This happens early in the book, changes (or at least changed for me) the way the rest of the book is read, and hugely increases its value. It may sound academic, but I found it motivating (if occasionally uncomfortable) that I could link so directly the way I run projects past, present and future to business performance. And making that link was straightforward; it’s a book that is free of hand-waving and its examples ring true to my own experience.

Diving in

Let’s get down to details with some quotes:

The issue is not queues, it is the economics of queues (p17)

We can define waste as a failure to optimize [globally] our economics (p33)

Optimum queue size is an economic trade-off (p68)

Focus on the wrong queue can actually create push rather than pull. Why (speaking in retrospect with embarrassment at my own stupidity, not to criticise the jargon of certain branded methods) emphasise the development backlog when you haven’t achieved flow downstream? Are all of your queues even visible (always, to all, on the wall)? Do you have any idea – even roughly – of your cost of delay (“COD”) and consciously optimise (portfolio-wide) to minimise it? I’m beginning to get a handle on my COD, and the numbers are staggering, especially when I’m tempted to apply a P/E multiple to the answer!

But other queues may not matter so much. On my Kanban wall I have a “Proposed” column preceding “Prioritised” and it’s my job to move items between the two. I don’t lie awake feeling overwhelmed by the large number of proposed items – in fact quite the reverse: it feels good to deny attention to work (even whole projects) that would only add delay to work actually in progress. Is the movement between the two columns push or pull in nature? Probably a bit of both, but it’s one part of the process that won’t get reduced to a system of rules – the sequencing and regulation of work going into the process is far too important for that, and I have the book to thank for giving me a fresh perspective on my personal responsibilities toward both the process and the end result.

Use CFDs to monitor queues (p71)

Cumulative Flow Diagrams (CFDs) can be done independently of Kanban but they make most sense done together – just log each day the number of work items held in each column and chart cumulatively over time – easy! What does my chart reveal? I work a pattern of alternate weeks, one week with the team in Budapest and one at home and this is reflected very clearly in the chart. Most re-planning happens when I’m in Budapest (near both team and customer), leading quite naturally to a 2-week cadence for the whole team. The CFD does hint at the cost of being apart and we work hard collectively to mitigate it, but my data collection gets a little patchy when I’m away so I haven’t properly quantified it yet. I check the CFD regularly to measure lead times, to look for any signs of growing bottlenecks that aren’t already glaing at me from the wall, and I plan to use it as a presentation tool in future management meetings.

It’s nice to discover that one can monitor lead times so easily and I’m prepared even to read some predictive power into the chart without ever requiring development estimates. In fact estimates have become yet another thing to be added the ever-growing list of supposedly indispensible things that I’m simply not missing. And let’s face it: so often they’re rubbish anyway!

Create [decentralized] systems to harvest the early cheap opportunities (p40)

Understanding decentralisation and delegation is especially important when running distributed development. Here’s a technical example (though the point isn’t the technique): I don’t (can’t!) review every line of code that gets committed but it is easily decentralized. Not only can developers review each other’s code, but my loathing of duplication in code has been communicated strongly, along with a counterbalancing worry about breaking working code without economic justification. As a result, the kinds of refactorings that lead to a smaller codebase and consequently to a smaller maintenance headache happen regularly without my direct involvement, and (thanks also to investments in unit tests and a CI system) seemingly without too much pain. But is this really a “cheap opportunity”? Yes, one has to be concerned about overdoing the up-front investment, but in our case it has already made for a more comfortable and productive environment and I’m happy that the pay-back period is short enough to make this a no-brainer.

Onwards and upwards

All of this has been drawn from or prompted by just the first three chapters, there being nine in total. Reinertsen goes on to discuss variability, batch sizes, WIP constraints, controllability and feedback before taking an interesting turn with a chapter on decentralisation, drawing heavily from military theory. All of it is excellent, some of it very quotable, some of it very valuable reference material (and no less readable for that). I make no apologies though for emphasising the core concept Don surely intends to keep at the fore as we continue with the rest of the book.

Nits to pick? Only one springs to mind, and it’s not a problem, just a minor missed opportunity. It follows from the book’s analysis of the economics of the timing of decisions that an un-made decision has real economic value, but this could have been made explicit. A link to Real Options Theory would have been very nice here, and it might have informed some of the later parts of the book. I have a vague recollection that Real Options do get mentioned, but I couldn’t find it in the index.

I have two concluding remarks to make. The first is about Kanban, and it is to restate a comment I made on one of the mailing lists: implementing Kanban was undoubtedly one of my better professional decisions in a 20-something year career as developer, project and program manager and now the senior IT guy in my new organisation. The second is about the book: quite simply it’s brilliant; buy it!

July 13, 2009


Filed under: Web Integration,Work — Tags: , , , , , — Mike @ 11:12 am

Yes, things are a bit slow on the blog front at the moment. Excuses: we move to a Georgian cottage in the Derbyshire Dales on Wednesday, I start an exciting new job on August 3rd (more on that nearer the time), and we have a new miniature schnauzer puppy named Klaus!

I haven’t forgotten described_routes and path-to though. There’s a serious link header tidy-up underway that delivers an efficient discovery protocol. Details to follow…

All in all, I’ve had a very enjoyable and quite productive 3 month break from full-time work. As well as the Ruby and Python programming I’ve been hanging out (as @asplake) with the #kanban guys on Twitter – a great bunch of people – and enjoyed @dpjoyce’s SkillsMatter presentation on kanban at the BBC in person a few weeks ago. It has also been good to clear the house of clutter (how Lean is that!), though to be honest, most of the credit for that goes to my very hardworking wife Sharon, who has been wonderful throughout this period of great change. Credit too to my teenage boys for agreeing to take this leap into the unknown!

April 30, 2009

Moving on up

Filed under: Project Management,Web Integration,Work — Tags: , , , , — Mike @ 4:10 pm

Tough times in the City of London, and I am “no longer required in the office”. The ugly black cloud hanging over the financial services industry (and investment banking in particular) has a major silver lining for me though: it creates the exciting opportunity to move to the beautiful Derbyshire Dales, and closer to my wife’s family. More on that closer to the time.

Meanwhile, if your organisation needs an effective technical leader (development manager, programme manager, agile project manager) with a strong sense for architecture, perhaps you should consider me. I enjoy travel, but I will need work that is either reasonably local (Chesterfield, Derby, Sheffield, Nottingham, say) or can be done mainly from home (Matlock Bath).

Why hire me?

I’ve been doing the “protocols and formats” thing for several years, with influence or direct control over integration protocols at enterprise and consortium level for the past eight or so years.  Returning to real-time front office development three years ago, I embraced REST as a tool for architectural improvement, reusability, testability, scriptability and so on.  So hire me if you need a system architecture that values these things over specific technologies.

I’m also big on learning, and although I do spend a lot of time reading and experimenting around my chosen areas of interest (to which my blog I hope testifies), this is not just for myself.  I have coached individuals and organised and empowered teams large and small for continuous improvement, and have had considerable success at improvement projects around capacity, reliability, business process and development process.  Again, some of these projects have had enterprise-wide impact.  So hire me (even for a short time) and know that I will leave your teams in good shape.

For further details, LinkedIn has a career summary, CV on request to mjb@asplake.co.uk.

Powered by WordPress