Tag Archives: leadership

Intangibles matter

Posted on by
Reply

Elroy Dimson (Emeritus Professor of Finance at London Business School, writer on investment strategy) recently wrote

Risk means more things can happen than will happen.

Perhaps I have been reading too many physics books lately, but this quote got me thinking of parallel universes as a metaphor for risk management. How much do we really know about the universe we live in now? Are there future universes out there that we should try to create or to eliminate, that way shaping our journey into the unknowable?

Evil Spock!
One universe to avoid

In Kanban, Intangible work items are those that affect our destination some indeterminate or distant time in the future. They’re uncertain (we’re dealing in outcomes that may never materialise) and hard to value, but their potential impact is sufficient to make the habit of these small investments a very good one to nurture.

This isn’t the first time I’ve linked risk management with Intangibles; see for example “Intangibles, value and risk (or: Portfolio thinking)“.  I return to the subject as part of an ongoing conversation with my friend and collaborator Jabe Bloom (@cyetain) who has kindly given in to my pleading for him to publish his “Space Shuttle” exercise.  Read about it here.

Tempting as it might be to focus mainly on eliminating downside risks, it’s important to understand that a healthy portfolio actively seeks upside risks too. Invest in your people, and one of them might surprise you. Product and platform investments might leave you better able to take advantage of market opportunities that are hard to see right now. And as I’ve argued before, not every process improvement should wait on the identification of a cast-iron ROI. Keep investing in the 4P’s of capability (People, Product, Platform, Process) and help bring those happier universes into existence!

If that’s too fanciful for you, I finish with this from Wikipedia’s page on Intangible Assets:

Competitive intangibles are the source from which competitive advantage flows, or is destroyed.

Intangibles matter; the worst risk of all might be to underestimate them.

2011: Another big year

Posted on by
Reply

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:

Lean reading marathon

Posted on by

I have just finished reading these five books in quick succession:


The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century by Stephen Denning


The New Economics for Industry, Government, Education by W Edwards Deming


Toyota Production System: Beyond Large-scale Production by Taiichi Ohno


Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother


The Lean Startup: How Constant Innovation Creates Radically Successful Businesses by Eric Ries

The Denning book has a very interesting take on old and new models of business leadership, with lessons that business can draw from the Agile and Lean development communities.  A good and interesting read but a couple of nits to pick:
1) Scrum receives special attention but without any real analysis of why (or why not)
2) With 70+ recommendations it was easy to lose track of the underlying principles

I would have left Steve Denning there, but he came to LESS 2011 in Stockholm this month, giving an excellent keynote and holding a Birds-of-a-Feather (BoF) session on leadership storytelling. I was greatly impressed by both, two of the best sessions of the whole conference. His book The Leader’s Guide to Storytelling: Mastering the Art and Discipline of Business Narrative is now on my reading wishlist.

I approached Deming and Ohno together as an exercise in going back to original sources – both books must surely be required reading for anyone interested in Lean, even if only as historical reference points.  I was however very struck by the timeliness of the Deming book nearly 20 years after publication and appreciated his warnings against the dangers of “tampering” (a word he uses with some precision) with systems that are prone to random variation.  The Ohno book gave great insight into the origins, influences and historical context of the Toyota Production System, and most especially the exceptional determination and clarity of vision with which Ohno and his mentors applied themselves.  My lasting impressions from this pair of books aren’t so much technical but the feeling that I have encountered some remarkable people.

Mike Rother’s Toyota Kata is my book of the year. I could only read it slowly, finding myself at regular intervals putting the book down to think!  It fills a big gap in Lean literature, explaining the Toyota Production System not as something fixed but as the result of decades of ongoing work, that work being the expression of a uniquely self-sustaining and self-renewing approach to management and leadership.  I wonder if there is an organisation outside the armed services that does this quite so systematically and thoughtfully?  There are lessons we can take away on making transformations endure, but still must be admitted that not many organisations have Toyota’s staying power. That’s a humbling thought.

Taking Ohno and Rother together, it seems clear that Toyota’s approach to improvement relies less on good tools or the employee suggestion box but rather on working towards process goals which would seem well beyond the reach of most other companies.  It is no wonder others struggle to keep up!  Continuous improvement seems such an easy thing, but it is no easy option when you are led with focus and determination, guided by a “True North” to which few would dare aspire.

Last but not least, Eric Ries’s Lean Startup book.  My expectations were driven downwards by the Twitter hype surrounding this book, but I was wrong to be so cautious!  There is real depth here, surprising insights right to the last chapter.  In particular, the “validated learning” concept seems set to be regarded as one of those oh-so-simple but elegant and language-changing ideas. It resolves so many of those frustrating loose ends that get argued about endlessly in Agile and Lean circles, such as the “why” of development work, the meaning of “done” and the appropriateness of metrics.  Now we have new and powerful ways to talk about the values, economics and direction of Lean development that sit very well with Kanban.

So, quite a marathon, but what a great investment!

Yes, Kanban scales

Posted on by

Yes, Kanban scales, but perhaps not quite in the way you expect.

Let’s start at the beginning. First follow the foundational principles[1]

  1. Start with what you do now
  2. Agree to pursue incremental, evolutionary change
  3. Initially, respect the current process, roles, responsibilities & job titles

then adopt the core practices

  1. Visualize the Workflow[2]
  2. Limit WIP
  3. Manage Flow
  4. Make Process Policies Explicit
  5. Improve Collaboratively (using models/scientific method)

These three principles and five practices are what define Kanban.  Not sticky note commandments (“On the first day thou shalt pull a sticky note from the Ready column and by the fifth day it shall be entered unto the column of Done”) but a collaborative framework for leading change.

But change to what?

Kanban’s home turf would appear to be software development, the focus of David Anderson’s book. But Kanban doesn’t come with a predefined process – we start out by applying it to existing processes – and it’s a not hard to imagine it being applied to other team-based “knowledge work”.

Personal Kanban scales this down to the level of the individual.  Some of the principles and practices lose emphasis in this transition, though this effect is lessened if we recognise that even personal effectiveness and improvement are best played as team sports.  The wide diversity of work typically seen in Personal Kanban tends to lead to very generic process designs and a lack of explicit policies, but this is counterbalanced by the idea of creating very context-specific Kanban systems, perhaps just for a season.  What could be more explicit than a specific process made visual?

So we know that Kanban scales down nicely; what about scaling it up?

This question is often taken to refer to things like the Kanban equivalents of “Scrum of Scrums”. Some organisations have replicated these with success, but to focus mainly on the mechanics would be an example of thinking at the level of sticky note commandments.

Instead: How might we visualise and manage flow across a whole business value stream of which software development is just a component?  At portfolio level, what could it mean to limit WIP and what kinds of effects might we expect to see?  These are great questions; to ask them as an act of deliberate change leadership is to start applying Kanban at scale, beginning a journey towards a Lean organisation.

So yes, Kanban scales. Not by adding layers of complexity as we scale up, but because the foundational principles and core practices aren’t actually very sensitive to scale.  Some might call that cheating!

[1] See http://finance.groups.yahoo.com/group/kanbandev/

[2] The back of my business card (see http://yfrog.com/hs7wx0j) has the pithier “Make work visible” and the Personal Kanban book says “Visualise work”. Both are fine I think.

A new box on top of old boxes

Posted on by

I just read these sentences in Implementing Beyond Budgeting (Bogsnes):

It is so much easier to add on than it is to take away. You buy a new a box and just put it on top of your other boxes.

Most of us start with Kanban by adding it on top of what’s there already; “start from where we are” is the advice (and it’s good advice).  But what will you dare to take away?

“Influencer”, or Kanban and models for change

Posted on by

Consider this progression:

  1. Operating a development process, using Kanban as a visualisation and scheduling tool
  2. Continuously improving a development process, using Kanban to manage flow locally
  3. Relentlessly tackling root causes that lie outside the scope of the development process of #1 and #2, driven by the latter to improve flow end-to-end
  4. As needed, designing and implementing radical change at the levels of #1-3, driven by #3 to improve flow for multiple value streams
  5. Embedding a change management and improvement process/mindset that sustains #1-4 for the long term

Kanban implementations led by people who understand its principles will set out to do #1 and #2 together, though one might hope that #2 will follow from #1 even in a “cargo cult” implementation.  #3 and #4 become natural as peer teams in increasing numbers surface the same issues and learn to collaborate on their solution; #5 then becomes implicit, perhaps manifested explicitly in support structures.

Bottom-up progressions like these have a lot going for them:

  • They can be started by anyone, pretty much anywhere
  • They’re not disruptive initially (but don’t rule out later disruption)
  • Judicious reading, training, coaching and mentoring can speed the process

But (and the answers to these will vary by organisation):

  • What exactly are we trying to achieve?  How will we know that we’re on the right track?
  • From where will come the support necessary for success in #3-5?  What’s to stop the whole thing from hitting a ceiling of organisational indifference or fizzling out, failing even to sustain #1-2?
  • How long should it take?

I’m a bit skeptical when it comes to top-down initiatives too, so what’s the alternative?

Back in April I mentioned Crucial Conversations by Patterson, Grenny, McMillan & Switzler in my post Crucial Conversations, Respect and Kanban.  I went on to read Influencer (their book on influencing change) and am now getting stuck into Crucial Confrontations by the same authors.

“Influencer” is about influencing and leading change.  I like this book a lot; it appeals to me as a Systems Thinker and it has the most teachable model for organisational change I have yet come across.  I hope I don’t do the authors a disservice by presenting it thus:

MOTIVATION ABILITY
PERSONAL Make the undesirable desirable Surpass your limits
SOCIAL Harness peer pressure Find strength in numbers
STRUCTURAL Design rewards and demand accountability Change the environment

If you can’t remember the content of the boxes you can still remember to ask “why change?” and “how?” at each of the levels of Personal (e.g. you and your peers), Social (e.g. team) and Structural (bigger picture stuff, e.g. organisation, process-wise).  These are good questions to ask also of your development system and each of the systems that surround it – see my recent post on portfolio management for an example of a surrounding system.

This “everywhere out” approach may look daunting, but the trick is to look ahead, to try to pre-empt impediments to change and to identify leverage points, i.e. those places where just a little effort (e.g. policy adjustments, better articulated goals) might unleash significant changes in outlook and behaviour.  Examples could include lead time as an organisation-wide improvement focus, with (say) inventory limits as a policy lever and the availablity of Kanban training as an enabler.  Collectively, these hit most of the boxes above.

None of this is to rule out bottom-up approaches, since a growing number of positive examples (“bright spots”) are key to success in that Social level, and the stronger your base of social capital, the easier it will be to engage at the Structural level.  But let us draw some “meta advice” from the “Influencer” framework: take the trouble to understand how change works, in theory, in your organisation and in organisations similar to yours.  Look for those bright spots!

Lines not boxes

Posted on by

Richard Veryard’s recent post on Emergent Architecture reminds me of the architectural meme “lines not boxes”. It’s a powerful approach that I followed explicitly in much of my time in enterprise architecture and web-centric development (“trust in open protocols and formats rather than closed technologies”) and I believe that it has value as a metaphor for process and organisational design too.

People aren’t boxes

Traditionally, we organise people by assigning them roles defined in terms of skills and tasks. Whilst some people seem to need the certainty that goes with this, it’s a practice I have actively resisted, whether as team member or manager. Putting people into boxes constrains opportunity, responsibility and creativity.

It seems to me more humane and more supportive of learning and growth if instead we make visible what needs to be done, define what good results looks like, maintain the minimum set of policies needed to ensure reliability, then create the space in which people can perform. And it can work for whole teams, where responsibility and creativity become manifested in self-organisation.

“Done” is only the start

Where there are different teams supporting different parts of a process, an over-emphasis on “what done looks like” has the effect of holding work back even when unfinished work could have considerable value downstream. In our “lines not boxes” metaphor, this is like defining the interchange formats to be used between systems but neglecting the communications protocols that carry them. An extreme example is the stage-gated waterfall approach to projects, where documents need not only to be completed but also reviewed and signed off before they may be acted upon in later project phases.

Under time pressure and faced with document-centric hurdles, smart teams learn to reach out and collaborate outside of the formal process. Smart organisations encourage this – making collaborative problem solving part of the process, building on successes rather than merely defending uneconomically against every eventuality (not to mention protecting every rear end). Once this is allowed to happen, it is my experience that artefacts start to get delivered in negotiated chunks and lead times take a significant turn for the better.

This is good news indeed: organisations build structures and introduce process overheads as they grow and rarely do they encourage flow. It is a relief to discover that bottom-up, flow-based approaches such as Kanban can prove effective even in the face of functional silos, not only helping teams to work more effectively within their functions but highlighting where a small investment in collaboration between silos will reap big dividends.

Crucial Conversations, Respect and Kanban

Posted on by

About a month ago, Benjamin Mitchell kicked off a thread on kanbandev called How does the Kanban Method reduce fear about role changes if change is emergent/unpredictable, mainly a discussion of what Kanban meant by “respect”. I couldn’t quite put my finger on it at the time but I was not completely satisfied. Now that I have finished reading Crucial Conversations: Tools for Talking When Stakes are High (Patterson, Grenny, McMillan and Switzler) I have a much better sense of what I was missing from that conversation.

This excellent book is all about how to handle better those crucial conversations where opinions vary, the stakes are high, and emotions run strong. Highly recommended, and I have added the related books Crucial Confrontations and Influencer to my reading backlog too.

One (of many) very relevant part of the book explains how mutual respect helps to create a safe environment into which all participants in a crucial conversation can contribute. And without safety, the book argues, real dialog is impossible.  Where mutual respect needs to be created, focus on similarities instead of differences.

Now I can draw a parallel with what we do when we use Kanban to surface, investigate and address difficult process issues in organisations. Whether we are acting as internal staff or external facilitators, our task is to get the heart of things, to be “seekers after truth” (Senge-style). This requires dialog! Hence the “Respect for people” pillar of Lean, the “Respect current roles and responsibilities” of Kanban, and Deming’s “Problems are 94% in the system”. To these I could add some favourite phrases such as “it’s about the work”, “organisations have needs too”, and several more that move the focus away from the person to the work and to the broader system, creating safety. Speaking from recent personal experience I can say that they really help, together of course with the facilitative mindset that goes with them.

So when I hear hear managers or team members personalise their criticisms of others (“they’re so unprofessional”), see references (even in jest) to “evil management” or consultants speaking in ways that seem disrespectful of their clients, I cringe and (increasingly) I challenge. How do we improve anything by starting with blame? Instead, what reasonable explanations might there be for the behaviours we observe? What might we all be missing?

It’s easy to judge (and yes I see the irony: perhaps I’ve just been a little guilty of it myself here) but it doesn’t get us very far. Catch me making more serious infringements and you are invited to call me out :-)

The A3 challenge

Posted on by

My previous post has been sitting there at the top of my front page for too long now, and it doesn’t reach my usual levels of positivity!  So let’s change that with a quick challenge:

  1. Can you relate the features in your development backlog (or at least the prioritised and in-progress portion thereof) to an identifiable business initiative?
  2. If – for real or in your imagination – you justified (compellingly), scoped and planned each of these business initiatives in just two sides of A4, how many of the features in your backlog would deserve a mention?

I take it for granted that you organise most of your development work by feature.  Large initiatives are allowed sub-initiatives, each also described (compellingly still)  in no more than two sides of A4 (real or imaginary).

The “A3″ of this post’s title refers to an A3 report, presented on a sheet of A3 paper (the size of two sheets of A4).  I wholeheartedly recommend John Shook’s Managing to Learn if this concept is new to you.

Learning together: Kanban and the Twelve Principles of Agile Software

Posted on by

This post is a spin off from the recent Scrum/Kanban debate.  Not wanting to let a situation go to waste, it seems a good time to affirm shared values, which I do here via the Twelve Principles behind the Agile manifesto.  I’m grateful to Joshua Bloom for his excellent input.

Commentary on the twelve principles of agile software

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.

Kanban: Check. We pull business value through the system, creating flow.  It should be recognized however that sometimes we create value by means other than delivering software (sometimes even by not delivering software!).  Furthermore, the act of improving the system generates value as it increases the capability of the wider organisation to generate value.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Kanban: Check. We actively limit work-in-progress (WIP), facilitating late prioritisation and minimising the impact of change on lead times.  We actively work to clarify the customer’s priorities so that the team can manage risk by properly sequencing work.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Kanban: Check. We make deliveries at intervals consistent with customer need and transaction cost.  We seek to minimise transactions costs attributable to the software development process, thereby making shorter delivery intervals economically optimal.  Highly advanced teams look towards continual deployment concepts to limit the inventory of complete yet not deployed software. We believe the best requirements come from software already depoyed being exercised by the customers/users. Achieving flow to the end-user generates higher value faster.

Business people and developers must work together daily throughout the project.

Kanban: Check. The development team and customer must learn together, in relation to both the problem domain and the delivery process.  The visual element of Kanban promotes transparency and creates triggers for customer interaction.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Kanban: Check. Build processes that respect individuals; empower them to learn and to improve the system.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Kanban: Check. Visualization and models allow face-to-face conversations to scale effectively. Limiting WIP prompts teams to have conversations DURING difficulties.

Working software is the primary measure of progress.

Kanban: Delivered business value is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Kanban:  We work within and share responsibility for the capability of our system; sustained long-run capability cannot be built at the short-term expense of the individual.

Continuous attention to technical excellence and good design enhances agility.

Kanban: Check.  And we look to increase capacity by identifying and reducing the failure demand that results from inattention to quality.

Simplicity – the art of maximizing the amount of work not done – is essential.

Kanban: Check.  Furthermore we actively manage work-in-progress, minimizing work not finished.

The best architectures, requirements, and designs emerge from self-organizing teams.

Kanban: Check, and process too. Leaders (inside and outside the team) must foster emergence, not squash it.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Kanban: Check. Continually even.

Conclusions

So there you have it, no fundamental conflict but a couple of clarifications and some changes of emphasis too.  It has to be said that these small differences do add up to a shift of mindset, but it is one that much of the Agile community has taken on board as a result of the increasing influence of Lean.

If I were to pick out a key thought it would be this:

The development team and customer must learn together, in relation to both the problem domain and the delivery process.

This lesson would be recognised by much of the Agile community I’m sure.