Nov 062013

Local staffing firm and winner of the Most Non-Ironically Orwellian-Sounding Twitter Handle Award tweeted this the other day:

All successful change initiatives start here


That’s a pretty bold statement for a company that’s never done a change initiative.  All successful change initiatives start at the top.

This idea is actually not unheard of.  You hear it other places, mostly as the result of disillusionment.  You can’t be an agile consultant very long without having the surreal experience of a company hiring you to help them change, then deciding they don’t really want to change all that much.  As agility begins to cascade upward and outward threatening all extant presuppositions and practices, they stand, Gandalf-like, bellowing that YOU SHALL NOT PASS and breaking the bridge before all that hubbub you’re creating in their developer teams gets to accounting or whatever.  There was one organization in particular where I felt they were paying me a very good amount of money for the privilege of ignoring me altogether.  Like I said, it’s a very surreal feeling, especially when people can and do ignore me for free.

However, the truth is that change that begins at the worker level can and does work.  In fact, my most successful “agile transformation” started with a development team, and once people saw the points being put on the scoreboard, the changes cascaded throughout the organization, changing their culture, levels of trust, rate of delivery – all kinds of good stuff.  I’ve also seen change initiatives start at the top and fail miserably because, even though management was behind it, none of the workers were.  It was something forced down on them, and they could get with the program or get out.  People were resentful at worst and apathetic at best, confident in the knowledge that this was management’s new fad, and next year it would be something different.  Change initiatives that start at the top without the full buy-in and participation of the ground up have a high risk for failure, and I speak from experience.

So, is it the case that all successful change initiatives start from the ground up?  That’s also incorrect.  Nobody can destroy a company’s agility like their leadership, and I’m going to go along with Deming here and say that the vast, vast majority of a company’s performance problems rest with leadership (ironically, vast amounts of time and money are spent on structures trying to pinpoint failures in the work force – “We need to hold our people accountable” is usually followed by an unspoken “because the problem sure isn’t me”).  Your pilot project can outperform everything in company history, and management can still shut you down.  It would be nice if good results were the final word in these kinds of decisions, but anyone who thinks data is the final word in an argument has never been in a long-term relationship.  So, change initiatives that begin at the roots level without the full buy-in and participation of management also carry a high risk of failure.

If change initiatives that start at the top are prone to failure, and change initiatives that start at the bottom are prone to failure, then what are you supposed to do?  Start in the middle?

The first part of the solution is, as Deming says, “The transformation is everyone’s job.”  You have to be willing to address the organization as a whole.  Agility has ramifications for everyone, and can actually be harmful if you only optimize a particular segment.  Can you imagine what would happen if you could make the front driver-side tire on your car go 50mph faster than the other wheels?  A similar thing happens to organizations where agility is only increasing in one place.  If you want to transform an organization, everybody has to know that what you are doing is going to affect everyone from the CEO to the night janitor.  Naturally, this can cause concern, and this leads me to my second part of the solution.

The second part of the solution is that organizations are resistant to change because of the way we try to make them change.  When we blame an organization’s agile adoption difficulties on their industry, culture, or people, we haven’t gotten to the root cause.  The root cause is that your way of changing the organization is setting it off the way a cold virus sets off your body.  “What the hell is this thing?” says your body, and the fever goes up to try to boil it out of you, the snot spigots unload to try to flush it out of you, and sometimes other unpleasant things that tend to happen at inopportune moments.  This is what organizations do to alien matter introduced into their system.  And believe me, brothers and sisters, I am preaching to myself as much as anyone on this point, as I can cite instances in my career when I was happy to blame the transformational difficulties on the company instead of the way I was going about things.

Yosemite Sam

Yosemite Sam (Photo credit: Wikipedia)

Change initiatives have to be done with a respect for people and in a manner that drives out all fear of losing their job (Deming, again).  This is the genius of Kanban: the changes are incremental, evolutionary, and the ideas and decisions come from the people doing the work instead of something imposed on them from the outside.  You can’t just go in like Yosemite Sam hootin’ and hollerin’ with pistols blazing.  When people start responding with resentment or fear, that’s your cue that you have done something wrong; it is not a cue that something is wrong with them.  What kind of misanthrope would you have to be to start thinking about getting rid of people who are actually doing you a huge favor by reacting negatively to what you’re doing?

When you start with where workers are at, and you give them the tools to visualize their work, and you help them define what they’re doing, and you help them measure how efficiently that work is being done, and you ask them, “So, what do you think we should do?” you are on the road to people being valued, giving you buy-in, and coming up with better solutions than you could.  Do you sometimes need to bring in ideas from the outside to get people started?  Sure, sometimes – but even then, it’s something you want them to own, not something they have to comply with.

Change initiatives from the top can work; change initiatives from the bottom can work, but both are risky.  Successful change initiatives start with everyone, and they are done by listening and building up your people instead of forcing it on them or getting rid of them.

Enhanced by Zemanta
Nov 052013
Industrial Engineering and Management building...

Industrial Engineering and Management building at the Technion in Haifa (Photo credit: Wikipedia)

I was talking with Lean/Agile Developer and overall smart guy Travis Dietz about requirements, and I brought up my old saw about requirements being inventory.  It’s an analogy that comes from the factory, which is where a lot of the ideas that inform Lean software development and Kanban come from.  Manufacturing was certainly Deming’s primary point of reference.  Principles, techniques, and even artifacts (control charts, flow diagrams) in this way of thinking most likely have their origins (or at least their ancestors) in manufacturing and industrial engineering.

How appropriate is this, really?

I mean, the Agile community has fought and is fighting hard to correct a misunderstanding about software development that we largely owe to NASA: the misconception that most software development projects are not fundamentally different from any other kind of building project.  You figure out what you want, an architect draws up all the plans, and the plans go to the workers to build out.  Because the plans have already been made, you can scale productivity just by adding numbers.  Also, past experiences should enable you to say how long a given development project will take if you can get a look at the plans.

In deterministic ways of building, this works all right.  If I have to make car doors, someone has drawn up the plans for a car door, and it’s my job to crank them off the line.  If my station averages 20 car doors a day, then when you ask me how long it’ll take to make a thousand car doors, I can give you a pretty good idea.  This environment – deterministic construction – is largely the environment much Lean thinking was generated in and is almost Deming’s whole world.

Software development, however, is non-deterministic.  Although you might have experiences that are similar at some level in the past, every problem is a new one.  Every bit of software you write has never been done before (because otherwise, you could buy it or just re-use the code).  Each feature is an act of problem solving and creativity, and we’ve all learned the hard way how quickly detailed plans become invalid.  Once you get to the battlefield, you have to adapt.   Software development is more like making a sculpture for a client than it is building them a car.  Given that the nature of the work itself is rather different than manufacturing, how appropriate is it to use optimizations from manufacturing?

Let me begin by saying that to dismiss insights from manufacturing because it’s manufacturing is pretty dumb.  Many advances in the field of software development did not come from software development, originally, and you should never close yourself off from wisdom that might come from a different field.  If you’re going to rule out every field that is different from software development, then you’ve pretty much ruled out every field, including the ones that you like and use all the time in your software development.  Math is a very deterministic field as well, but you’re going to have a hard time programming without it.

But the question remains, how far can we really take this?  For instance, I have pointed out some things from martial arts that I believe have relevance to software development, but I don’t think practicing takedowns will help us write better software.  I think the solution may be in the distinction between laws, principles, and techniques.

Laws are universal truths that everyone everywhere has to deal with.  For example, people have to sleep.  Therefore, no matter what field you’re in, you don’t want to schedule people for 24 hour shifts all month.  People can only be in one place at one time, therefore, we do not assign people to five separate teams and expect them to be fully available to each one all the time.  They’re laws built into the nature of the reality we all share, so dealing with these laws is automatically going to be something that spans all fields.  Any insight that comes from some fundamental law of reality is pretty much guaranteed transferable somewhere else.

Principles are also general truths, typically derived from laws, but they are not always universal to all places and all times.  “Avoid the Bubonic Plague” is a good principle, but generally speaking, it’s not really applicable to most people today.  On the other hand, we might consider a principle like, “Employees should be empowered with the tools and authority they need to do their work efficiently.”  Although you could probably find an edge case or two where this didn’t apply, it pretty much applies everywhere.  Maybe someday when we live in a telepathic hive mind, concepts like “employee” and “authority” will no longer serve a purpose, but at least in our current context, it’s a pretty good principle and relevant to all kinds of work.  When applied to many different fields, you see good results.  I’d say that the vast majority of the concepts and recommendations of Lean, Kanban, and the various thought leaders in that area operate at this level.  You have to understand how the principles apply in your context, but they are more or less truths that are bigger than a specific field.

Techniques are specific implementations/practices of something, usually derived from principles.  These are only valid insofar as they operate in accord with their principles and are usually heavily conditioned by specific context.  For instance, in most of the apostle Paul’s letters to churches, he tells them to greet each other with a holy kiss (Rom. 16:16, 2 Cor. 13:12, 1 Thes. 5:26).  In the first century near east, a chaste kiss was a culturally standard form of warm greeting.  It was a way to show that you were a community and had a level of affection for one another.  In modern, American churches, you are likely to be maced when trying this out.  In our time and culture, a kiss has romantic connotations, or at the very least suggests a particularly close affection like a relative or a very old and dear friend.

In modern America, the church members might shake hands, hug, smile, slap on the back – something that signifies warmth and community to us.  The principles of community and affection span both times and cultures, but the specific implementations of those principles are very culturally conditioned, and if you went around to American churches trying to kiss everyone because “Paul told you to,” someone would rightly argue that you had confused the principle of Paul’s instruction with the cultural particulars, once they had slapped you.

It is in this area where, in software development, it is appropriate to go through these other industries at the practice level and decide if they’re really helpful in our context or not and, if so, do they need to be modified to better suit non-deterministic work?  One good example is control charts.  We (software developers) generally do our control charts based on probabilities rather than standard deviations, because we don’t have a consistent completion time we can use.  The principle is the same – we are measuring our throughput so we can make informed projections, offer our customers service level agreements, and have conversations about things that look out of whack – but as for how that actually gets done, you can’t just lift the practice out of Toyota and drop it onto a software development team.  You have to figure out if the practice will actually help you embody the principle, or whether it might need to look different or be scrapped altogether.

So, I will continue to borrow insights from manufacturing.  That environment is much older than software development, and they have discovered principles about work, flow, quality, and how people perform their best that we’d be idiots not to consider just because it came from manufacturing.  But when it comes to practices (and principles to some extent), we need to make sure we are thinking critically about the nature of non-deterministic work and the best way to embody those principles for us.

Enhanced by Zemanta
Aug 272013
Retrospective 5 (Pinestone)

Retrospective 5 (Pinestone) (Photo credit: .:fotomaf:.)

Kanban does not prescribe any particular meetings.  It leaves it up to the workers to decide what meetings have value and how often to do them.

One meeting that I’ve found has value nearly everywhere I go is the good ol’ Retrospective made famous by good ol’ Scrum.  As long as we think of retrospectives more generally as a regular time for the team to talk about improving itself, you’ll find retrospectives many places you find Kanban and/or Lean practices, including Toyota.

Having extensive experience with the traditional Scrum retrospective, though, I think there are some things that can be changed to make it flow better with Kanban’s intent and, in fact, I think it even produces better retrospectives for Scrum teams as well.

The traditional Scrum retrospective basically follows the format of each team member stating what things went well (things to keep doing), what things did not go so well (things to stop doing), and what things could benefit from change (things that could benefit from change).  The Scrum Master records all these and, ideally, the team selects some to work on for the next sprint, and they talk about these items as part of the next retrospective.

You don’t have to be a Scrum Master very long before you watch these meetings devolve into a dry, useless mirror of the daily standup where no real value is added or degenerate into an unfocused whine-fest.  The value of the classic retrospective tends to drop so quickly that, if you head over to LinkedIn and start rummaging through the threads in the various agile and Scrum groups, you’ll see tons of threads asking how to do retrospectives differently.  In these threads, hilarity ensues because 90% of the consultants and coaches only learned the practice but never really understood the purpose, so you get surreal ideas like, “I use Legos in my retrospectives.  I buy everyone ice cream.  I dress up as Sailor Moon.  I have my retrospectives underwater in SCUBA gear.” and so on.  Ideas that try to make the meeting more engaging instead of changing the meeting to better accomplish its intended purpose.

I would like to share with you what I think is a good way to change the meeting to better accommodate the way Kanban effects organizational improvement.  It is not the objectively best way, nor is it a good thing to do in every organization, but here it is.

The first part of the meeting is to go over the metrics – specifically, we review the Cumulative Flow Diagram and the “Control” Chart.  Together, we discuss flow.

Did you catch that?  We don’t talk about making low numbers higher or high numbers lower.  We talk about the flow of our work.  What does the data imply about where things are not flowing smoothly, and why might that be?  Are there communication issues?  Too many handoffs?  Is there a small part that is affecting the whole?  Is the whole thing screwed up?  We are concerned about the areas where work is not flowing smoothly and taking cues from areas where it is.  We talk about where we would like to be and how our situation is different than that.

Notice this is very similar to talking about what is going well, what isn’t going well, and what are areas for change.  The main difference is that we are talking about an objective situation as a team as opposed to navel gazing into our personal feelings.

Once we have talked about these things, we discuss as a team what we believe the one area is that needs the most love.  Usually, the data strongly suggests an area, so there is little debate.  Then, we brainstorm ideas of how to improve that area.  We vote on one idea, enact that, and see if it made a difference when we get together next time.

Here are the key points:

  • The discussion stays about our work, not things or people outside our work that we can’t control.
  • The discussion stays objective.  The metrics are what they are, regardless of what our individual feelings might be.
  • The metrics are a catalyst for discussion and inquiry, not a substitute for it.
  • The focus is on improving our flow, not going faster.  Take the kinks out of your hose, and the throughput will increase.
  • The focus area and the solution both come from the team, not from the outside, creating instant buy-in.
  • One and only one change is introduced so it can be measured.

One might argue these are the basic intents of the Scrum retrospective, and that may be, but I would then counter-argue that the traditional format is not the most efficient way to accomplish those intents in many cases.

Enhanced by Zemanta
Aug 142013
Kanban in miniature

Kanban in miniature (Photo credit: jhritz)

For some years, now, David Anderson has vocally separated Kanban from “agile” or “agile methodologies” like Scrum, XP, and so on.  I never really understood why this was.  Although obviously Lean is found in several industries as is the use of various elements we find in Kanban, easily the most common place to find Kanban in the wild is in software development, and specifically software development teams trying to become more agile.

Also, you have to understand that I came to Kanban as a progression of sorts from Scrum.  Scrum helped me achieve a lot of the things I was trying to get out of a more agile software development experience, and when I came across Kanban, I saw it as (in my opinion) a better way to get at those same things.  But I didn’t see it so much as a different kind of thing from Scrum; just something that did some of the same things better.  So, in my head, Scrum, DSDM, XP, Kanban – these were all the same kind of thing, just with varying approaches and doing some things better than others.

But now, after having engineered the use of Kanban in a few different organizations and observed its power and value, as well as doing research trying to accumulate something intelligent to say about its differences with SAFe as it bulldozes its way into the market like a hyperactive wrecking ball that just demolished a Pixy Stix factory, I think I’m beginning to see what David’s been on about.

Agile and agile-ish methodologies can link their spiritual heritage to the concepts that became embodied in the Agile Manifesto – the signatories of which are names that you’d recognize in the field, like Ron Jeffries of XP fame and Darth Sidious of Scrum.  This Manifesto articulated principles and concepts of what agility was looking like in software development (and specifically software development, I might add – it says right there in the preamble).  People began to create and collate practices and systems that, in their minds, did good jobs of expressing in practice and technique those agile principles.  You do these things, and you are getting closer to expressing those principles more fully and more comprehensively.

What I have been discovering over time, though, is that Kanban actually makes nothing more agile, nor does it improve anything.

Rather, Kanban is an efficient, effective way to show you where you can improve, the best places to improve, and what the impact will be.  In other words, Kanban gives you everything you need to improve quickly, efficiently, predictably, and get the most bang for your buck.

When I was a kid, dentists would sometimes give you these red tablets for you to swirl around in your mouth after you brushed your teeth.  They tasted like they were made from Hell’s own brimstone and the ground up bones of dentists that had passed on, and perhaps they were, but when you spit the stuff out, there would be red areas on the surfaces of your teeth that you missed while brushing.  They didn’t clean your teeth; you had to do that.  But the red tablets drew your focus immediately and visibly to the areas that needed your attention and the severity of your lack of attention.

Kanban is like that.

Making your work visible, limiting your work in progress, measuring the flow of your work, making policies explicit, and managing to flow are all designed to give you exactly what you need to apply your improvement brainpower.  Where do these improvements come from?  From you, of course.  Nobody knows how to do the work better than the people doing the work; not an agile coach, not a consulting company, not a manager of the people doing the work – the actual people doing the work are your best source of ideas for improvement.

Organizations usually don’t lack opinions about how to improve; what they lack are ways to get their work situation under control so they can meaningfully study it, ways to sift through the good ideas from the not-so-good ones, ways to know what their priorities should be, ways to project the impact on the work, and ways to measure the actual impact to see where adjustments to the good ideas need to be made.

So, why is Kanban not agile?  Because Kanban doesn’t increase your team’s agility one single iota.  What it does it create the conditions and foundations necessary and  provide you with all the intelligence you need for kaizen – an ongoing journey of improvement, driven by the people doing the work, but always viewing how it improves the system as a whole.

Enhanced by Zemanta
Jan 282013
English: It shows that agile methods are focus...

English: It shows that agile methods are focused on different aspects of the software development life-cycle. (Photo credit: Wikipedia)

I haven’t had much time to write, lately, but I thought I’d assist the pithy Bob Marshall in preserving the following paper by Grant Rule.  It’s a paper that’s like pretty much completely right.  You can quote me on that.

What’s wrong with the project approach to software development?

January 11th, 2011 Author: pg_rule

Pretty much since “software” was first invented (60 years ago?), numerous folk have been promoting an ‘engineering-led’ approach to ‘software projects’. Yet this advice goes largely unheeded, with the result that the relative success of IT projects is poor, and has improved very little during all my years in IT (38 and counting). Given that such admonishments seemed to have had such little effect in all that time, I also find myself asking, “Do I think it likely that further exhortations to those involved in ‘software projects’ to change their project practices is likely to achieve improved value delivery to stakeholders?”

And I have to conclude that the answer is “No”.

Following Albert Einstein’s adage that, “The definition of insanity is doing the same thing over and over again and expecting different results”, it seems to me that we need an entirely new approach. A new approach which goes to the root causes of what actually goes wrong in the end-to-end process. Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?

Observation of what actually happens in organisations suggests there are two root conditions to the problem:

  1. Those responsible for business strategy are disengaged from, and know relatively little about, software- intensive systems and technology. So they structure their organisations so that software & technology people are segregated into silos. In those silos, the inmates talk amongst themselves in whatever arcane language they choose. But importantly, they don’t communicate (or interfere) with the ‘real business’.
  2. Everyone conspires to pretend that software-related activities should be managed as ‘projects’. That is, as chunks of work that start and end (on more or less clear and agreed dates), that have more or less well- defined goals, that contain a list of activities (tasks) that are assigned by a ‘project manager’ to a project team to which ‘resources’ are assigned for a limited period.

The results of studies too numerous to mention shows that most software projects are ‘challenged’ or ‘fail’. One study suggested that the majority of experienced project managers (and I am sure, folk playing other roles) expect at least 1 in 3 of the projects they lead to fail! As systems become more complex, and larger, they employ more teams combining projects into programmes… which further reduces the likelihood of successful achievement of the overall goals.

My conclusion is that we need a complete change of mindset. We need to move away from the inherently batch & queue concept of the ‘project life-cycle’ (as promoted by organisations including BCS, APM, PMI, OGC, SEI, NCC, ISO, IEEE, IET, etc. etc.) to a different approach.

I suggest that the required new mindset will accommodate the ideas of flow production and lean systems thinking that first began to be developed systematically (in e.g. automotive engineering) around 100 years ago. (Of course, one can trace elements of flow production & lean at least back to Carthage c.300-200 BC, but let’s ignore the history for now.)

I posit that Tom Gilb’s Evo method, and other agile methods such as XP, Scrum, Flowchain, and software Kanban, etc., begin to achieve ‘better’ results compared to ‘traditional’ big-design-up-front, wholly batch & queue methods, precisely because they encourage workers to focus on smaller batches of stakeholder value. In other words, value in terms the software developer can get to grips with.

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C- suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Flow production (toward which Evo, Flowchain and Kanban currently make the nearest approaches IMO) would:

A) Make the entire end-to-end, whole-life, ‘concept to consumption & retirement’ process of defining, deciding, acquiring, designing, developing, operating, supporting, maintaining & replacing software- intensive systems a visible, inherent part of normal business operations… forcing issues onto the management horizon so they can be addressed as business issues – and not just something technologists worry about.

B) Because it would be apparent that software & IT issues were causing interruption to (or even cessation of) the flow of value, C-suite executives would have to recognise the pressing need to engage with software & IT related issues just as much as they do with other kinds of business issue. Conversely, the engagement of the ‘systems and software engineers’ with ‘the business’ would also be stimulated, the role of each and the communication between them finally becoming acknowledged as a main artery of the organisation’s lifeblood.

Flow production can only work effectively with the active engagement of all involved. For this reason it is a far more sustainable business model than other, perhaps more familiar, approaches. It embeds the ability to flex and respond to market forces deeply into the organisational culture. The focus on ‘the unforgiving minute’ forces constraints and problems out into the open where everyone can see them. It won’t allow problems to be swept under the carpet, or passed from one department to another like the proverbial buck. Hidden problems will always result in debts in one or more of the five kinds of capital. And such hidden debts, whether financial, technical, intellectual, social or environmental, all too often bite you when you least expect it. They will injure or kill the project – and destroy stakeholder value. Even if the project avoids repaying its hidden debts, this usually means that the debt has been passed-off onto one or another unsuspecting stakeholder group (sometimes, the end-customer or taxpayer). Which must be judged as unethical behaviour.

Unfortunately, not only have most people in the software industry been taught to sit in their silos and focus largely on coding, they and their masters have developed a cultural love affair with the project concept. To the extent that everyone assumes that all work has to be compartmentalised into projects, the very epitome of batch & queue thinking. Tell me what you think. Has the software project had its day, or is there another way of revolutionising workpatterns in the software industry?

Enhanced by Zemanta
Sep 272012
English: Photograph of Steve Denning

English: Photograph of Steve Denning (Photo credit: Wikipedia)

This is a question addressed in Steve Denning’s article that uses it in the title.  I have already talked about why one should appreciate Denning for what he does, but also take him with a grain of salt.  I want to take a look at the actual article content.

First, it’s notable that these points aren’t actually Denning’s.  Everything he says about kanban comes from an e-book by Michael Sahota.  Michael Sahota is a Scrum coach who, to his credit, also has some experience with kanban.  This means he escapes the critique of 99.999999% of the Scrum dudes who critique kanban – that being that they have no experience with it.

But it’s interesting to note that Denning’s actual arguments essentially boil down to, “This other guy said these things about kanban, and that sounds probably right to me.”  This is what I mean about the grain of salt.  Agile coaches, consultants, and commentators will have made astounding progress when they stop proclaiming religiously what someone else has said and actually observed it for themselves.  If there was ever a field where it was necessary to become your own authority figure, it’s consulting, and there is no other initiation into that level than trial, tribulation, and victory.

If someone has been leading their company through Waterfall and has been kicking ass, I can’t argue with her.  Why?  Because she’s actually kicking ass.  I honestly can’t imagine this actually happening with Waterfall, but you see my point.  I see far too many agile “authorities” boldly proclaiming what does and does not work, what companies should and should not be doing, and what the agile community should and shouldn’t be doing, and it’s just ridiculous to me because I know they have no clue.

The crux of Sahota’s/Denning’s argument is that kanban can work with existing practices and, unlike Scrum, does not challenge an organization’s culture.  Sahota qua Denning points out that kanban can address cultural change, but it doesn’t intrinsically require it the way Scrum does.  He then goes on to discuss kanban’s usefulness as a sort of slow “gateway drug” to more rigorous agile practices, such as Scrum.

The first problem with this is a confusion between rate of change and lack of change.  An organization that moves to kanban will have to change – culture, practices, values – everything.  However, kanban does not require bulldozing everything an organization is currently doing.  Rather than crushing the rock like another rock, it erodes the rock like water – pointing out the sharp edges that need smoothing and, organically and over time, carving out the Grand Canyon.  It challenges a company’s practices and culture slowly and incrementally, but it does challenge them.  You can’t do kanban and refuse to deliver incrementally.  You can’t do kanban and measure success by conformity to up front estimates and requirements documents.  But we don’t uproot everything at once.

Scrum, by contrast, requires a pretty big displacement of practices.  You can’t really incrementally Scrumify, and this is generally discouraged.  The irony is that you can’t change culture overnight.  The idea that forcing an organization to adopt Scrum is going to instantly transform an organization’s culture is not only ridiculous but a key factor in many difficulties people have adopting Scrum.  They do all the Scrum stuff, but the culture hasn’t had time to change, difficulties ensue and… guess what, Scrum doesn’t work!  No, it does work.  It’s just that you tried to take people from 0 to agile in thirty seconds.

The second problem is that Sahota/Denning confuse leaving a value stream unchanged with leaving an organization’s culture/values unchanged.  This is ironic, given that one of the thrusts of the overall article is that a set of practices are not the same as a culture.  Kanban begins by mapping what an organization currently does to produce value.  It doesn’t recommend changes right off the bat; it just makes the value stream visible.

Have you ever noticed that almost no organizations have done this prior to kanban?  Have you ever noticed that it is rare for an organization to have a visual map of what their inputs are, what their customers want, and how they produce value?  Do you know why this is so rare?

Wait for it.

Because thinking critically about how you deliver value to a customer and all the things that hinder that is NOT USUALLY PRESENT IN THE CULTURE.

Mapping the value stream is a challenge to the culture.  Making work incremental is a challenge to the culture.  Identifying bottlenecks and constraints is a challenge to the culture.  Allowing work “phases” some slack and having them go idle if the downstream is full is a challenge to the culture.  If you don’t think so, walk on up to your manager and say, “Hey, I’m not going to develop any new features, today, because QA has their plate full.  I’m going to help QA, instead, to get that moving,” and see how that goes.  It’s a challenge to the culture!  Folks, I have been at this a while at a pretty good number of companies, and I can promise you that the kinds of questions and activities kanban raises are not ones that allow cultures to go unchanged.  Just because you begin by mapping the current process does not mean you will change nothing.

Finally, there is the idea that kanban is suitable for organizations that aren’t ready for a “real agile” methodology like Scrum.  It might be a lightweight gateway into them, however.

I have to admit that I find this completely puzzling in light of what actually happens in the industry.  Not only have I been at this a while, many of my friends and colleagues have as well.  I also actively read books, blogs, and interact regularly with agile coaches not just in America, but in other countries.  All that to say that, while there’s tons going on that I don’t know, I feel like I have a high level idea of what the trends are in our industry.  And I have never, not even once, heard someone say anything like, “Yeah, we mastered kanban, and once we were rockin’ along on that, then we knew we were finally ready for Scrum.”  No one does that, and if your organization has, they would have burned you as witches in Salem because of your freakish abnormalities.

By contrast, the stories of organizations moving from Scrum to kanban are legion.  That isn’t to say there are more orgs doing kanban than Scrum.  That’s not at all true.  Scrum is way more common and popular.  But when you hear about orgs switching from one to the other, it is virtually always people going from Scrum to kanban, not the other way around.  And as a CSM, I can tell you that doing kanban well is every bit as rigorous and challenging as doing Scrum well.

Is kanban agile?

Well, if agility means delivering valuable software more quickly, then yes.  If agility means incremental delivery of the most valuable items, then yes.  If agility means challenging the culture to value learning, observation, and adjustment to change over guesses, contracts, and trying to eliminate variation, then yes.  If agility means uprooting everything an organization is currently doing, then no.

Sep 262012
English: Billie Joe in 1994 Español: Billie Jo...

English: Billie Joe in 1994 Español: Billie Joe en 1994 (Photo credit: Wikipedia)

Steve Denning wrote an article, yesterday, addressing the question of whether or not Kanban is agile.  I’d like to address the points in that article (which all came from someone else, actually), but before getting into that, I want to address some meta issues with the article that I feel are best done by talking about the band Green Day.

By the time Green Day released their album, Dookie, they had long since abandoned punk rock.  However, you can still hear some attachments to that genre in their music.  Dookie got lots of time on MTV (some of you young’uns may not remember that Music Television actually played music at one point) and the radio, both of which led to a popularity the band hadn’t really enjoyed prior to that time.

A curious thing, happened, though, as these newly minted legions of Green Day fans professed their newfound love of punk rock.  These people did not cut their teeth on The Clash, but Green Day represented punk rock to them.  Anyone who knew what punk rock really was knew Green Day was not that, including Green Day, themselves.  Sure, their music was enjoyable.  Sure, there were elements in there from punk rock, but it wasn’t punk.  It most definitely was punk, however, for college students all over America who had no basis for comparison.

Is Green Day an enjoyable band?  Sure (my favorite Green Day song is “Minority”).  Was their popularity good for punk rock as a whole?  That’s harder to figure.  On the one hand, their popularity exposed a new generation to some punk rock elements that perhaps they might never have heard, otherwise.  Perhaps some of these even went on to explore punk and proto-punk bands and developed a fuller appreciation of the music and the philosophies that boiled at the heart of the movement.

On the other hand, for every one person who knows Green Day isn’t a real punk band, there are fifty who equate them with punk rock.  Is this good for punk rock when Green Day is their flagship representative in pop culture?  Is it good for the punk movement when college kids are hanging out at Starbucks talking about how they’re all into punk and their favorite bands are Green Day and Good Charlotte?  Debatable.

This is the basic struggle I have whenever I read a Steve Denning article, of which there is no shortage.

On the one hand, I love that, because of his labors, agility and discussions about agility are flowing into the mainstream when they otherwise wouldn’t.  The man writes for Forbes, for Thor’s sake.  With virtually every article, he tells the business community that your days are numbered if you aren’t agile, and that agility isn’t just a set of software practices, but a principle-driven movement that is intended to transform a whole organization in thought, practice, and values.

On the other hand, he doesn’t really understand agile.  He has an ok grasp of Scrum, but that’s about as far as it goes.  Each article of his is about a 70/30 misunderstanding/good stuff split.  It has elements of agile, but it isn’t, and he really ought not to be the flagship representative of it.  I have mentioned this in passing, before, using his example of calling Apple an “agile” company.

Unfortunately, to the masses, he is.  He is the Green Day punk rock experience to masses who are unfamiliar with writers who actually get it, or the agile coaches who are producing actual victories in the field, or the philosophies and “bands” that bubble in the heart of this movement.  He is, essentially, the patron saint of People Who Talk About Agile Who Don’t Really Know What They’re Talking About, through no real fault of his own.  It just so happens that he’s popular and accessible, much like Green Day.

Most of you probably harbor dreams of opening punk rock clubs.  If you were to do so, and a band wanted to headline at your club, and they described themselves as Kansas City’s greatest punk band, and then proceeded to cover Good Charlotte songs, you might rightly wonder if they really knew what punk music actually was.  This is analogous to how I feel when I see his articles being thrown around agile discussions.

Which brings us to this specific article.  There are, as expected, some misunderstandings and misapprehensions.  Further, the vast majority of the article is quoting someone else’s book.  This is something that is always a red flag to me – when the majority of the information someone shares comes from someone else.  There are people who blog or tweet and 90% of what they put out there is from somewhere else.

It’s not that such information isn’t helpful; it just tells me that you have no authority of your own.  You don’t have a well of your own knowledge and experience to draw from.  You don’t have the level of synthesis that has made what you claim to espouse part of your heart, bones, and blood.  You don’t have the ability to extemporaneously apply your thoughts to a wide variety of practical situations in practical ways.  This isn’t a bad thing, but it is kind of dicey when you’re a consultant, and it’s especially dicey when you’ve written a book on management and write for Forbes as the voice of agile.

Tomorrow, I’m going to get into the particulars of his notes about Kanban, but I want to frame the context correctly.  I hope Denning continues to learn and continues being a voice for agile.  I hope he exposes more and more people to these issues and gets more discussions going.  I have read him for a long time and will continue to do so.

But keep in mind – he ain’t punk music.

May 102012
Post-It Note Impression No. 14

Post-It Note Impression No. 14 (Photo credit: Kevin H.)

Should an organization use a physical visualization of workflow (such as a whiteboard and sticky notes) or an electronic one?

Personally, I prefer the physical ones. They tend to be way more visible, easier to have group discussions around, any changes are immediately visible as they occur, and physically moving those cards around releases endorphins.

There are decent reasons for electronic versions, though, especially if your team is distributed. Also, whiteboards don’t do cool automatic calculations and reporting. The main issue is that using an electronic tool can sometimes reduce actual interaction and collaboration, which is something tools should facilitate rather than replace.

Until recently, the best anti-whiteboard argument I’d heard was this:

I don’t like a physical whiteboard because I have to walk all the way over to it whenever I want to know something.

This came from someone who sat about twenty feet away. We’re still considering buying him a spyglass.

This was the reigning champion until I heard the objections, below. Individually, either objection is a solid contender, but when you consider they both came from the same person less than two minutes apart, they become the gold standard for anti-whiteboard objections.  They are:

When people walk by the board too briskly, the sticky notes can come off.


Sometimes, the cards are hard to move if they stick too much.

So, if your office is populated by world-class sprinters or chronic arthritics, you might consider an electronic solution.

Oct 202011
Visualization of the KANBAN concept.

Image via Wikipedia

I’ve decided “Kanban” sounds too exotic and buzzwordy.

From here on out, it’s the Stop Nagging Me Board.

The Stop Nagging Me Board (SNMB) shows you at a glance what has been done, what I’m currently doing, and what remains to be done.

The SNMB shows you how long I spend working on a particular piece.

The SNMB shows you where that piece is with regard to the larger process, all the way through deployment.

The SNMB shows you when a piece is in trouble or is being roadblocked for some reason.

The SNMB shows you when I’m ready for more work, when I’m swamped, or when I’m idle.

The main items on the SNMB are written in language that is meaningful to both of us, not just me, although there might be additional information on the SNMB that is only meaningful to me.

The SNMB will tell you more just by looking at it than a timesheet could or the act of poking your head in my cubicle to ask me how the project is going. It will tell you more than an hour long status meeting. It will tell you when there’s an issue where you can assist me or when more input is needed.

The SNMB is to overzealous project managers what crucifixes are to vampires.

I think instead of trying to get buy-in for various “agile” and “lean” techniques and philosophies, I’m just going to tell teams, “Do you want to get nagged less? Put this board up.”

Oct 122011
Eager Scrum teams

Image by mnordin via Flickr

When we last left our heroes, I was talking about some of the recurring issues I’ve found that Scrum seems to foster – most of which revolve around timeboxed iterations as the primary means for limiting work in progress and generating metrics. So, if you were looking for a solution to those issues, what would you do?

Ditch the timeboxed iterations in favor of something else? Ayuh.

Everybody thinks in terms of features.

Kanban uses individual features for limiting work in progress and calculating metrics, and this is great because features are something everyone understands. When I have a conversation with the business about which features are where in our pipeline, they understand that. When I talk about which sprint we’re on or which sprint we’ve targeted for feature X, that’s not at all intuitive. More conversation needs to happen just to fill them in on what a sprint is and how it works.

However, with Kanban, all conversations revolve around features, themselves.

It’s important to note, too, that business users will always make their changes with regard to features, not sprints. They will not ask to change the priority of sprints or add or remove sprints to the work queue – they ask all those things in terms of features.

Reporting progress becomes very easy. A Kanban board is intuitive and the derivative metrics are easy to provide. Have you ever tried to show a business user a sprint burndown chart? Did it answer their vital questions? ‘Nuff said.

Metrics are tied to features.

With Scrum, metrics are tied to timeboxed collections of features. With Kanban, metrics are tied to individual features. This is great because, instead of offering what sprint a feature is slated for, I can give a projected date for that individual feature.

Since change requests also happen in terms of features, I can easily demonstrate how the removal or addition of a feature will affect the timeline. Reprioritization has absolutely no effect on my planning or timeline, because I’m not scheduling features in blocks of time. With Scrum, reprioritization requires me to restructure the content of my sprints, but with Kanban, we have no sprint to restructure. We just keep getting to features as they come up in the workflow like always. That backlog could be a seething cauldron of reprioritization, and it will have no effect on us at all.

This also helps when incorporating other teams to help us get the job done. For any particular feature, I can give a projection of when we’ll need that completed, so we can schedule them as far in advance as we need with a good degree of accuracy. Sure, that date could change based on user requests, but that’s always the case no matter what process you use.

There are no Hell (insert time increment).

There are no artificially imposed deadlines in Kanban. You have projections, but you don’t have any sense of “by date X, amount of work Y must be done.” The projections are based on actual metrics based on your actual rate of speed, not promises based on what you think you can get done.  In fact, the presence of a Hell Whatever in this process is an indicator that you have a bottleneck or need to revisit your work in progress limits as opposed to being a natural by-product.

With Kanban, I set limits for each stage of work in progress, and those act like floodgates to my workflow. Are people too idle in a particular phase? Increase the limit. Are people swamped? Decrease the limit.

The whole point of the Kanban board is to visualize the workflow for the whole world, and if you aren’t getting a nice, even flow, this is immediately visible to everyone, and you can see exactly where you need to make changes to get a nice, even flow.

With Scrum, this visibility is just not there, and the structure of the process just takes the Big Deadline Problem and distributes it into the Lots of Smaller Deadline Problems.

Kanban is not process-heavy.

That doesn’t mean there’s no process; it just means a lot of the implementation details are negotiable.

There is no KanbanMaster. There are no specific roles that must be filled with specific responsibilities. This allows you to establish these as your business environment sees fit. It can accommodate teams with or without project managers, self-directed teams or externally-directed teams, people with multiple roles or people with granular roles.

It used to be that, when people said, “We tried Agile, and it didn’t work for our environment,” I used to automatically assume they just did it wrong.

While I admit this is still the case an overwhelming majority of the time, I now ask if they tried to do Agile via Scrum (for many orgs out there, “Agile” is a synonym for “Scrum” – I blame successful marketing), because a strict Scrum operation might indeed not work easily in some environments.

Do you need a Product Owner? You don’t. You need a Voice of the Business, and that can take many forms, from one person to a group of people to a (ugh, please don’t do this) requirements document. Kanban recognizes there are principles an agile process needs to implement, but prescribes few implementations.

This is as opposed to Scrum which codifies its implementation and demands that your organization change to accommodate it. People who modify Scrum to fit their environment are viewed with a sort of derision, said to be practicing “Scrumbut.” And I get this, because in order for Scrum to have a chance of being successful, you pretty much need to do all of it or none of it.

Kanban and lean can be done with incremental optimizations. You certainly can uproot your entire methodology and establish a new, streamlined machine, but you don’t have to. You might, for instance, just set up a board to make workflow visible. If that’s helpful, you might start branching out with other lean optimizations here and there. Or you can just say, “Hey, I think we’ve gotten to a point where we’re agile enough. Let’s just cruise with this until we hit pain points, then we’ll optimize some more.” These things are simply not great options with Scrum.

I could say more, but really, most of this boils down to what the central unit of your workflow is going to be. Is it going to be a feature, or is it going to be an increment of time’s worth of features? I think the former unit of measurement and conversation is way more useful to organizations.