Getting nowhere – at high velocity

I put this down for my own future reference a couple of weeks ago: I think David Anderson made an excellent observation with the side-comment

Oh, one thought, there is a way to cheat to make your flow efficiency look good - only measure it inside the Sprint ;-) and not from the point of customer commitment to delivery.

The original reference was in far more complex context,
discussing flow leveling and heijunka – check out the whole discussion on the mailing list – but I think this statement alone is worth re-visiting several times.

Many of the agile projects I have witnessed over the years were in really good shape and churned away story-points at a quite satisfactory rate. Yet, some of them were looked down upon by top management as unsatisfactory from a business point of view and a couple of them even got shut down.

To me this seems to be because of the same 'blind-spot' that could be one of the reasons behind the fact that – according to the Standish Group – 41% of agile projects do not achieve the expected result.

To have a successful project there is much more involved than just writing software and creating 'potentially shippable products' – so our process considerations should not begin and end with the creation of software. Instead they need to start and end at the customer and have to incorporate software-creation as an integral part of this process.

From this perspective measuring and optimizing the development team's velocity can be misleading. In fact, sometimes highly misleading. Apart from the simplest way to enhance your velocity (by just padding the estimates) even a real enhancement of this part of the process does not necessarily speed up the time until a customer is able to use any new features.

Wich brings us back to David Anderson's remark - you really have to measure the whole value chain. Not only inside the sprint but including all the adjacent areas.

• the time it takes from idea generation to the decision if the idea is going to make it
• the time it takes to really ship a potentially shippable product
• the extra iterations it takes to 'harden' the product, reduce 'technical debt' or one of the many other ways to account for thinks that should have been in the sprint in the first place
• etc.

When you start measuring lead-times like this – and focus on the flow of singe requirements in these measurements – you'll get a lot more insights into your real process.

Let me know what you think!

Cheers,
  Michael

Yes you can (because I think so)

a.k.a. “works on my machine” or “works in my world”

The Situation

Developers declare function after function ‘ready’ and the customer still complains that “nothing ever gets ready” - unhappiness ensues.

Example

This little exchange really happened…

Consultant: “Has the issue #whatever been resolved?”

Tester (customer): “Oh yes, that was the one where we couldn't do #some_important_thing”

Developer (supplier): “That's been handled for ages - you can do #that_important_thing"

Product manager (customer): “No, I still can't do #that_important_thing”

Manager (supplier): “It is possible to do #that_important_thing"

Tester (customer): “I wanted to try it this morning and it is still not possible to do #that_important_thing“

Developer (supplier): “I am sure! I have implemented that. You definitely CAN DO #that_important_thing”(in an aggravated tone)

[one or two more circles like that, voices getting louder]

Consultant: “Ahem...”

Tester: “What?”

Developer: “What?”

Consultant: “Dear Tester: _In what way_ couldn't you do #that_important_thing?”

Tester: “I don't see any menu entry related to #that_important_thing in my main screen!”

Developer: “Oh - you're trying to do it with your own account! That won't work of course …"

Tester: “There is another account?!? What's the name? Where is it mentioned?”

Developer: “Oups … we might have to work this out a little more …”

And thus both the developer and the tester learned something new about the system and its interaction with the world.

The Problem

The parties clearly communicate on different levels of abstraction – while the developer was referring to the theoretical capabilities of the system the tester was taking about the things he actually was able to do with the system at that point in time.
Abstraction differences like this oftentimes can take days or weeks to become visible, especially if the parties involved communicate intermittently and use media like e-mail or a ticketing-system for their conversations.

A Solution

Go to the real enduser (or as close to the real enduser as possible) and watch her using the newly added system-capability.

Related lean/TPS concepts

Genchi Genbutsu / Gemba Walk

Related values from the Agile Manifesto

Customer collaboration over contract negotiation
Responding to change over following a plan

Related Scrum Values

Openness
Respect

Expectation Management: Mind the London tube notifications

A real life situation

Munich

A bright but icy winter morning in southern germany: Dozens of people stand on the platform at a local train-stop in Munich's outskirts. The display reads "train arriving". Ten minutes later the crowd is visibly unhappy, swearing and freezing. The first would-be passengers start to leave the platform in search for other means of transportation.

The whole attitude is "We [strongly disklike] those (explicit deleted) responsible for the public transport"

London

A rainy day in England. Hundreds of people walk into the tube station at tottenham court road, quickly glance at the sign that posts the current outages in the London transport system and quickly decide to use the ‘Northern Line’ and the ‘Circle Line’ to get to ‘Victoria Station’ since the ‘Central Line’ runs only at 50% and takes much longer this morning (and is probably heavily overcrowded as well)

The whole attitude is "business as usual"

The Situation (related to the software world)

In a computing environment some resource (a called service, the internet connection, memory, disk etc.) is not available or at its limit and the System just ignores it until it finally fails. (Another version could be planning meetings, where the fact that the amount of work can not be done in the available time (or that some preconditions, like known requirements etc., are not yet met) get ignored until after the deadline hits.)

Example

Almost all software that does not offer sensible graceful degradation strategies and thus shows an error message only after the user tried to access a – probably vital – function of the system. (E. g. E-Mail clients that say "Encryption Error while initiating secure connection to server" after polling the mailbox for two minutes … while the computer actually is not connected to the internet.)
The physical world example is in fact the German railway system (and even worse a lot of the public transport operators) where arrival times of trains and busses are sometimes displayed based on plans instead of the real situation.

The Problem

The user loses trust in the system and either switches to alternatives (e.g. if the system with the un-announced problem is a trouble ticket system the users might start sending mails instead of using the ticket-system, in the physical world people switch from public transport to private cars etc.)

A Solution

Communicate everything you know about probable system malfunctions as early and visible as possible. Plan your outages and be honest about them. Design software with sound graceful degradation strategies.

Related lean/TPS concepts

Andon
Heijunka

Related values from the Agile Manifesto

Responding to change over following a plan Working software over comprehensive documentation

Related Scrum Values

Openness

Requirements - a different IPO than that at the stock exchange

I really do love Mike Cohn's format for user stories, but while formulating requirements in the form

"As a <type of user> I want <desired system interaction> so that <desired outcome>"

is very helpful for capturing requirements, it is in no way sufficient.
The point is not only that user stories really have to be written from a user's point of view.
Writing genuinely from a users perspective means that there should not be any story

"As an internet-user I want the system to perform garbage collection so that the server doesn't have to have too much memory."

because, quite frankly, most internet users don't care about garbage collection or the server's memory - they care about response times, user experience and (hopefully) the service that is provided.

But there is more to good requirements than just writing a story from a users point of view – one of the intriguing stories from Tom DeMarco's The Deadline is the one where a bunch of people read a 18-binder specification for a system and none of them dared to tell the project manager that they did not really understand what it was all about. Those binders where full of technical detail and elaborate formulas but lacked a couple of important things nobody noticed at first.
Until somebody asked "Where does the data come from?" and another one chimed in "Where do the outputs go to?" After that magical moment the spell was lifted and all kinds of missing information were was surfaced. In the end the specification was reworked and the project could go ahead.
Which brings us to the basic point of every operation in a system - there has to be an Input, some kind of Processing and an Output. In the olden days there was a name for that concept, it was called the IPO model and used to be applied to hardware as well as to software.
And even though we (hopefully) don't write our programs anymore as the sequence 'input division', 'processing division' and 'output division' the basic structure for requirements is still quite valid. If the input or the source of the input is unclear it is hard to decide how it should be handled. If the postprocessing is unclear – the output – it is hard to decide what to do with the results from the processing.

So for every requirement – if it is formulated as a user story or in any other way – before the implementation starts it should be clear what that user-story's IPO is.

Till next time
  Michael Mahlberg

D is for Design ... and T for Verification

That is, if we talk about software development and the acronym TDD.
Often translated as Test Driven Development the acronym has been around since the late 1990s and especially the book by Kent Beck – rightfully at that time in my opinion – made people think of TDD as a development technique.
Now when you ask different people what "development" is, a lot of them might argue that it is about coding only – while others take a much broader view. This leads to many people (including Kent Beck if I recall correctly) pointing out that the second D in TDD is very strongly about the design aspect of development.
Since I came into closer contact with some of the proponents of Exploratory Testing (ET) a couple of years back I can't help but wonder if the whole term is misleading. Of course it is about a certain aspect of testing, but those engineers who "really" do testing in the hardware sector (e.g.: with cars, planes, elevators etc.) would consider such tests only as checks or verifications, which don't require a specialist in testing to perform them. After all, everything that is done in these "tests" is to check whether a certain assumption by the developer is met by the system. (Or if the axle distance is really what the designer specified, or if the elevator cable really is capable of holding the specified weight, or... you get the picture)

The (hardware) testers I know on the other hand do something different – and usually only leave a pile of scrap metal when they are through with their tests. They test how much weight is necessary to break the elevator cable, at which speed or lateral acceleration the torsion changes the distance of the axles (which usually doesn't bear to well with the car) and so on.

And TDD simply doesn't give us that kind of tests. Those tests that look for the unexpected or un-specified. And that is is why we still need a lot of non-automated (e.g. exploratory) testing.

So please bear in mind that in a true cross-functional team TDD has it's place in development but so does true testing know-how besides TDD.

Untill next time
  Michael Mahlberg

From the customers perspective...

... a story starts and ends with the customer experience. There are no technical stories.

The technical temptation

From a technical point of view two stories A and B that share some basic functionality might look like an opportunity to extract the technical commonalities in a story C. What tends to happen is that you wind up with three stories A, B, C that can be easily "estimated" and have an obvious order of implementation - you start with implementing the technical commonality C and then, once that is stable you can do A and B on a tried and trusted foundation.
Nice, isn't it?
No - it is not!
Now you would have three stories and none of them conforms to the I (independent) of the INVEST concept for good stories. And what's worse: you end up with a story that is not testable by the user - story C. To add insult to injury, it is even your first story, further delaying the deployment of code that is useful to the end-users.

A solution?

For me the solution to this scenario is to really plan, estimate and analyze in four dimensions. Take the time into account. If you implement A first then A is much bigger than B because once it is finished B gets all the development effort from A for free – or at least the part that turns out to really be usable for both A and B. So B is actually bigger on the inside - unless you travel on a different timeline where B gets developed first. In that case A would be the story that gets the benefits.
In either case, the important message is:

Don't burden the customer with technical stories to get better story-sizing, just look at every story in the context of the moment when it gets implemented.

Value gets delivered only when new capabilities are available to end-users.

Untill next time
  Michael Mahlberg

No Risk - no Gain?

"If a project has no risks don't do it" - that's what Tom DeMarco and Timothy Lister state on the very first page of chapter one of "Waltzing with Bears", one of the better books written on risk management.

Initially this statement may seem counterintuitive but actually most techniques applied in Agile software development and its management are about controlling risk. Timeboxing? Reduce the risk of overengineering or overanalyzing. Test Driven Design/Development? Reduce the risk of untestable, tangled, unstructured software. Pair Programming? Reduce the risk of poor code quality and lost focus. Daily Standups? Reduce the risk of uncoordinated (or duplicated) work. And so on. On the other hand a different kind of risk is seldom mentioned: the risk of not reaching the project's goals!
If no one – not even the owner of the project – sees "not reaching the project goal" as a quantifiable risk, what does that mean? Primarily two ideas come to mind: either the project is not really important and nothing bad is going to happen if it doesn't succeed or no one even considers the possibility that the project might fail due to yet unknown reasons. Neither of these scenarios seems particularly appealing to me.

So the message from Tom DeMarco and Timothy Lister is twofold in my perception:

1. Don't take on a project that doesn't matter to anyone. (i.e. where there is no risk in failure)
2. Don't take on a project where there is no intention to address common risks (i.e. a project where good practices – like those from lean and agile software development are not even aspired)

Untill next time
  Michael Mahlberg

P.S.: And yes, this is also a recommendation for the book "Waltzing with Bears: Managing Risk on Software Projects"

The Spice Girls on requirements engineering and root cause analysis

Just the other week I came across an interesting thread on the "kanbandev" mailing-list. It was all about "have you asked the Spice Girls question?" which seems somewhat odd, if you consider that this mailing-list is about managing Software development projects...
turns out it is only about the second verse of "wannabe" : "So, tell me what you want, what you really, really want" [you can (and should) ignore the rest of the song for the purpose of this post].
That one sentence actually captures remarkably well what differentiates a shallow requirements or root cause analysis from a thorough one: Asking beyond the obvious to find out the need that fuels the obvious.
according to Jabe Bloom Steven Bungay formulated the question a bit more formally:

[...] This should be encapsulated succinctly in the form... We should do What in order that Why.
For example... We should implement Continuous Delivery in order to minimize Lead time.

But "Tell me [...] what you really, really want" seems to stick a lot better than just "why".
So thanks, Jabe Bloom, for raining this!

The best way to do hardening sprints

What's the problem with hardening sprints?

Hardening sprints are often considered a sign of mis-interpreted Agile and a process smell. But then I read in answer to Ron Jeffries, who pointed out that hardening sprints simply mean that you where not "Done" the first time around.
In that answer I read that should be almost always due to overcommitment.
Really? Well - I've never seen this.
If I see hardening sprints at all I usually see teams putting the hard part last and then ending up with a huge number of 98% done stories that will be "fixed right before the release" - of course this accumulates and the transaction cost of the release become higher and higher until you end up with a whole Sprint to fix the small things that now form a huge, interconnected blob.

The solution

Get to "DONE" early. Not as in "code complete" or "checked into source control" or "automated tests did run" or even "accepted by client" but as in "There is nothing left that has to be done for this story" Just don't do hardening sprints!

Additional comment: When the requirements conform to INVEST so should the implementation

The (well know?) INVEST formula for story-design put independet as the top property of a good user-story.
But what good is an independent requirement if the implementation is strongly coupled with other stories? Of course there is a limit to the independence, especially if you have a newer story relying of an already "done" story. But an older story should never be dependent on a later story (Really bad: "it will work once we've got the implemented, so let's just consider it 'done' for now") and the stories of one iteration should be as independent as possible.

Post-mortems are for dead projects - what to do with the living?

"He's dead, Jim" – the famous quote from "Bones" McCoy in the original Star Trek may be one of the shortest post-mortems one can think of, but it's not necessarily what you want in an Agile retrospective. What you might want instead is the attitude of Star Trek: the Next Generation's captain Picard - "Make it so".

From post-mortem to retrospective

But then again: the history of retrospectives is a history of misunderstandings...
One – plausible – version I have heard goes like this:
When the idea of project retrospectives came up in the context of early space missions, the idea was in fact to learn for the next iteration. But "the next iteration" would have been the next iteration of a rocket design, and the previous iteration would now have been reduced to a lump of metal shreds after it's successful test flight. Under these conditions it must have seemed quite fitting to borrow the term post-mortem – after all there wasn't much left moving at the "landing site". Developing safe ways of landing was not quite as high on the list of priorities as getting off the ground in the first place.
Gradually the scope of post-mortems expanded and soon the term was used to describe the process for all kinds of projects and was even adopted as a general term in commercial software development.
In 2001 Norman L. Kerth wrote a book titled Project Retrospectives: A Handbook for Team Reviews in which he made a strong case against the use of the, then accepted, term post-mortem. Before Esther Derby Diana Larsen's Book Agile Retrospectives came out, this was the definitive guide on retrospectives for me (now both books share that place) and I always tried to follow his emphasis of the fact that we don't do retrospectives for the past but for the future.

So let's use the term "Retrospective"?

At least there is a somewhat common understanding of the term.
When Tom and I laid out the structure for the Hands-on lean and Agile practices course we decided to go with the term "retrospective" – partially because that term is more widely recognized and people would have a clearer picture of what we talk about in that part, and partially because "retrospective" is the term commonly used in descriptions of the mechanics of such a review which makes it a good search candidate when looking for additional information.

How about "operations reviews"?

Nowadays I'm contemplating to suggest naming this section of the course "operations review" – a term used in the lean and Kanban literature. Although there are many very tight definitions of that term pointing out that an operations review is not at all comparable to a retrospective, these "clear" definitions are contradictory and some (a lot) actually suggest a certain similarity between operations review and (healthy) retrospectives.

Now what's it with this nitpicking with words?

Is it really important how we call this activity in our daily work? If we start with the intention in mind – looking forward, wanting to influence the future – won't the rest follow?
Well, modern brain science has it's own take on this.
As humans, our expectations and actions are influenced by the language used. In one very well known experiment people where told that they where tested on word-understanding while in reality their physical behavior was the subject of the experiment. One group had to work through a series of words with connotation of old age while the other group worked with words implying agility and youth. Sure enough the "old word" group was measurably slower on their way out from the testing facility. Even though this specific experiment on `priming´ has been disputed lately, the effects of priming also are one of the things the whole advertisement industry thrives upon. One last argument I would like to quote for this influence of words are the Implicit Association Tests from the harvard university. In these tests unconscious beliefs can be discovered by measuring the time it takes to identified words after the brain has been 'primed' with simple but powerful concepts like 'good' and 'bad'.
I don't know about you, but if I have the chance to 'prime' the whole team conducting the activity, I would rather like prime them with a concept that directs our attention to the future than setting them up for looking at a project that's still running with the mindset of a retro-spective, "looking back from a distance". Although much closer to "being in the present" than the mindset of a post-mortem, it still sets us apart from the things we want to influence. For my ears an "operations review" sounds much more like a thing I would undertake to influence what I'm doing right now.
I'm open for suggestions, but whenever possible I propose that we use words like "operations review" instead of "retrospective" or "post mortem" – at least until we find an even better way to put it.

Theoretically Agile is quite simple - as long as the theory is Theory Y

When the whole agile movement started there was a huge amount of success-stories everywhere to be heard. But nowadays, as Agile has entered the mainstream at least partially things have changed. As Michael Sahota points out in his "...Agile Adoption and Transformation Survival Guide" the success rate of agile projects nowadays follows the bell curve pretty much like everything else.
When I run the team building simulation from the Hands-on lean and Agile practices course we very often find that the highest performing teams are in the realm of recreation – and it is my impression that there is a significance in that, that is worthwhile to explore.
Talking about motivation and people's engagement Theory X and Theory Y come to mind. In the 1960s Douglas McGregor developed Theory X and Theory Y at MIT. Two theories that have a considerable influence on how people and projects get managed – even though many managers are not aware of those theories. While Theory X assumes employees are unwilling to perform and have to be tightly controlled, Theory Y assumes the complete opposite - that people are highly motivated and just need to be supported.
I don't want to go into which theory is more valid - especially not without discussing Theory U which takes a completely different approach. But what strikes me ever so often is the similarity between the assumptions of Theory Y and the assumptions of most agile methods – and actually this is one of the reasons why the success/failure distribution for agile projects is developing the way it is. In the early days people were attracted to Agile projects by their enthusiasm and willingness to explore new ways of working. Actually the early "war-stories" from those agile teams fit perfectly into Theory Y wording. When – for example – a team hijacks a meeting room as a permanent collaboration space that's pretty much people wanting to excel and create their ideal working environment. But the more Agile is crossing the chasm to widespread adaption the more it gets pulled into the realm of Theory X – largely because most major companies are run based on Theory X. And thus we see a conceptual difference between the assumed environment for Agile (Theory Y environment) and the actual environment for many projects nowadays that run under an agile umbrella (Theory X environment).
This mismatch is – in my humble opinion – one of the main reasons why Agile has lost a lot of it's edge over "classical" management.

Till next time
   Michael

Uncharted Territory - exploration vs. guided tours

Yet another case for the use of adaptive methods in product development...

The good tour-guide...

... be it in a city or in the outdoors, has been to all the places he guides you to, has friends in every second venue, has intimate knowledge of the secluded spots so he can show you what the eye of the unknowing passer by would surely miss. That's the kind of tour guide I would want on a tour in well-known territory. But then again: what about the truly explorative excursions? Those places, I want to go to, to discover new things, unknown wonders or scarce resources - would I really want the same guide for this?

... may not be the best scout

If I go into uncharted territory my main focus is not to have a guide who knows all the places (that would somehow contradict the "uncharted" part, wouldn't it?), but someone who knows how to read the terrain, who knows how to work a compass, how to triangulate a position even when we haven't been moving in the intended direction for quite a while, someone who can figure out how to go about it if we need fresh supplies, and so on. Maybe the tour-guide from the previous paragraph also has those qualities – but the skillset is definitely quite different.

What's that got to do with software development?

Well - when Tom and I worked on our Hands on lean and Agile practices course I once again realized that, while traditional methods mostly took the tour-guide approach. Most of the tools in the Agile toolset really help you to be a better scout while the lean toolset seems to cover both aspects with a special emphasis on the transition. That way I like the Agile practices for allowing me to navigate in uncharted territory while the lean tools give me a way to quickly make this territory accessible for repeated tours.

How do they fit together? - Another Tale of Kanban and Agile Principles

Some say they are contradictory - I think that is the wrong word - complementary is more to the point.

What's the beef? Explicit lyrics ahem... policies

One of the Kanban Principles (the fourth to be exact) requires the team to "... Make Process Policies Explicit" while the probably best known statement from the agile manifesto invites us to value "Individuals and interactions over processes and tools."
Now when Tom and I prepared our hands on lean and agile practices course we both knew from experience that there is a lot of value in both approaches. But I still was baffled when a colleague from the Limited WIP Society Cologne pointed out the contradiction in these two statements and it took me while to come up with an answer.

Explicit is not a four letter word

Many people I know in the Agile community are sceptic towards explicit rules because they tend to be written in stone – especially if they come from the outside. But in an Agile environment (same as in a lean environment) that doesn't have to be the case. Not, if the team (or the cell if you use lean terminology or however the relevant unit is called in your context) owns the process policies - whether they are explicit or implicit. Making them explicit does not make the un-changeable.

"Explicit" makes it tangible

On the contrary - as long process policies are implicit it is hard to discuss them. Once they are written down – for example as an exit condition for a status or as a work in progress limit – it is easy to refer to them (the hard part is identifying them in the first place) and the team can change them explicitly whenever the need arises. Visible to everyone and without reliance on tacit knowledge. They might even start to track how often they change certain policies as those changes might point to some opportunity for improvement and the numbers could provide valuable input for the next operations review (or retrospective if your focus is Agile)

Explicit policies make it easier...

... to focus on "Individuals and interactions over processes and tools" because the important agreements between the individuals are out there in the open – tangible and negotiable.

The term conflict is vastly misunderstood

"We never have any conflict in our team"!

For me that is a really, really sad sentence. I really love to work with teams without quarreling and bickering – but I very much hope that there is conflict.

The meaning of conflict

What is `conflict´ after all? According to the english Wiktionary conflict is:

Noun conflict (plural conflicts)

1. A clash or disagreement, often violent, between two opposing groups or individuals.
   [...]
2. An incompatibility, as of two things that cannot be simultaneously fulfilled.
   [...]

And while almost everybody thinks about the first interpretation, the second one is equally valid and extremely valuable to recognize.

It's all about managing conflict - and that's a good thing

This is yet another thing that popped up when Tom and I prepared our hand on Agile and lean practices course - a lot of the techniques in lean and Agile are there just to handle conflicts in a reasonably civilized way:

• We prioritize work-items because they are competing for development time - there is a conflict for the time
• We queue deployments - there is a conflict for the deployment machine
• We use A3 reporting to point out conflicting interests.
• etc.

Recognizing conflict is an enabler

Without recognizing conflicting interests as such there is no way to resolve the conflict - take the original idea behind (non-automated) continuous integration: Software developers in the nineteen-nineties realized that they ended up with incongruent systems, when they all just committed their work to a central repository whenever they had a working result.
Apart from testing mechanisms and some other technical details, there was also a hidden conflict - the conflict for exclusive access to the system for modification. Recognizing this conflict enables people to find solutions. In the original example from Kent Beck, integration happened only on one machine, thus mediating the conflicting request for access to the system by queueing them. Denying this conflict on the other hand prevents solutions.
(Or this denial leads into misguided attempts on Jidoka like continuous integration servers which should really be called build servers and more often then not are just used as a fig-leave ... but that is another story – which will be up here shortly).

Conflict, there's just no way around it…

…but there are many ways to handle it wisely - by applying tools and techniques to resolve or manage it. As with change in the subtitle of the first eXtreme Programming (XP) book, fighting it only makes it worse. In XP they say "embrace change" - the same is true for conflict if handled responsibly "embrace conflict".

Priorities 101: I have to fell trees ...

Once upon a time ... ... I was wandering around the woodlands, when I heard a faint noise that drew my attention. I closed in on the noise and coming closer I heard heavy breathing and moaning and swearing and cursing - and the sound of an old mechanical saw cutting through timber.
Then I finally came to a clearing in the woods and saw a huge guy covered in sweat, wielding and old and worn out buck-saw to cut slices from an enormous tree he had cut down earlier.
I greeted him friendly and inquired as to why he was swearing and cursing so much. He looked at me friendly and explained with great patience "You know, the work of a woodworker can be really fulfilling if you have the right tools and are able to really excel at your work. But me? I only have this worn out buck-saw and I have way more work to do than I ever can finish."
So I asked him: "But what about those sharpening tools over there? Why don't you use them to sharpen the blade?" He looked at me worriedly. "Haven't you been listening?" he sneered, "I have way too much work to do, I DON'T HAVE TIME TO SHARPEN THE BLADE". And with that he turned around and started sawing away at the giant tree again...

I have heard and told this story in a dozen different ways - but I constantly have to remind myself to take my own advice. It's just too easy to get carried away in the everyday struggle of "getting stuff done" to take a look back at the big picture.
When I worked on the Hands-on lean and Agile practices course together with Tom Breur I realized that I had a lot of tools in my back that I constantly introduced to other people but neglected to leverage in my own work. Re-introducing things like A3 thinking and root cause analysis into my everyday (business) life has proven to be quite effective – and I am really happy that I took the time to sharpen the saw a little bit.

Software development is such a new field?

Software 'engineering' is not such a new field anymore, is it? After all we have been writing software since the late forties – so our field is more than sixty years of age.

Strangely enough, I keep hearing the argument that this is such a young field of engineering and we "don't yet have the experience to make it an exact science."

Is that really true?
How about building planes? That's quite a new field as well, right? If we start the timeline with the Wright brothers, we would have to start in 1903 (if you'd want start with Otto Lilienthal I'll raise you a Babbage – and I would answer a DaVinci with a Leibnitz – or even a Pingala if I have to. So, just for the sake of the argument let's stick with powered flight and 1903). So the Boing 747 – which had it's inaugural flight in 1969 and is still in service with many airlines – was designed when the craft of building planes was roughly the same age as the craft of building software is today.

And I doubt that you would refrain from stepping aboard a Jumbo-Jet because it was designed at a time where "the field of aircraft development was still very young and the results where not always predictable."

So I think, we should put more emphasis on the things we already can do – let's not complain that our internet connections is slow on a transatlantic flight – let's be amazed that we do have an internet connection on a transatlantic flight!

And let's not complain that software development is not determinedly predictable but let's embrace all the techniques we do have to manage and navigate this uncertainty.

In essence: we do have the tools – we just have to use them!

BTW: When Tom Breur and I designed the hands-on lean and agile practices course we found that there are so many tried and proven practices even from our own hands-on experience that we had to actively limit the number of practices to make it a digestible sized course.

What's in a name? (a.k.a. "I don't think that word means what you think it means")

Why is it so hard to get the challenges of software-development across to people who are not from "our field"?
To be quite honest: I don't know. But I do have an inkling about some of the more obvious points. One of them, that has been pointed out numerous times, is that we tried to compare software-development with production for a really long time - instead of comparing it with, well, development.
But let's not linger on that aspect - let's look at another one that has not been covered quite as well. Language and mental models. In most other fields the words and their physical representations are put to the test quite early - even if the words themselves may be ambiguous. No one would really try to use hazelnuts or walnuts and cross-bow bolts when a manual speaks of "nuts and bolts".

So, what's different in Software development? A lot! One of the main differences though is, that we don't work with concrete material (nuts and bolts) but with concepts - words representing things from the physical world. Or even worse: words representing things from the physical world that represent concepts that represent intangible things - like money or time.

But let's just focus on the words for a second - they can mean a lot of different things to different people. For example my grandmother has quite a different notion of the concept "button" than my godchild does, as I am sure you can imagine.

Or, as Lewis Carrol put it in "Through the looking Glass":

'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.' 'The question is,' said Alice, 'whether you can make words mean so many different things.' 'The question is,' said Humpty Dumpty, 'which is to be master — that's all.'

And this is not only true for the concepts we use inside our craft but also for the concepts we employ to create, envision and define our products.
Let's just look at some examples...

• For some people "A3" refers to a paper format – for others it refers to a way of thinking (actually also based on the paper format due to technical reasons, but that is another story).

• For some people "XP" is an operating System – for others it is a software development process.

• A Retrospective can be a very interesting art exhibition (for example on Ansel Adams) - or a very formal technique to optimize the way people work together.

And so forth...

So from my point of view one of the challenges we face is in the meaning we put in words and concepts and how much they can differ across organizations or even within a team.

What to do about it? Take the time to find your own meaning for the words, join industry groups to discuss those meanings and get a little bit better applying the concepts every day. And never rely on a word meaning what you think it means - always verify with the people with whom you're working, that you're talking about the same things - even if you use different words.

Shameless plug: And perhaps attend some trainings where you can experience some of the concepts behind some of the words first hand...

We don't have a problem ... IS a problem

"Do you have a problem?" – "No, we don't have any problems around here" - "Oh, that is a problem"

What? – I have to admit, that this conversation might need some explanation.

The dialogue above depicts a typical situation that arises when groups first start to introduce continuous improvement. In our culture, problems are so tightly connected to bad things that we tend to either block them out or try to solve them as quickly as possible - even if the latter means circumventing the problem in the first place... instead of really going to the root cause of the problem and in fact solving it.

But as Jerry Weinberg once stated "Once you eliminate your number one problem, number two gets a promotion." (The Secrets of Consulting, page 15) – so the real question is "Are you aware of your current number one problem?"

To achieve continuous improvement, it is important to be aware of your problems - and to keep in mind, that under changing circumstances, yesterdays solutions tend to become todays problems – which makes it even more important to take a close look for and at each and every problem with a fresh and open mind as unbiased as possible.

Cover all the Angles

What gave planning such a bad name?
"In 'Agile' we don't do estimates!"
"We do not plan ahead - we just do what is necessary at that Moment in Time"
"We don't know what we will find out, so let's not try to plan the un-plan-able"
Guys seriously... Of course the kind of planning that emerged in the 70s, 80s and 90s of the last century, where people try to plan what other people do a year in advance down to a very detailed level does not make sense - but does that really mean that we shouldn't plan anymore?
After all, the ability to plan ahead is what made it possible to evolve from hunter-gatherers to settlers. And this planning did not include assigning "Caveman A" to sharpen the sickle on February the 20th and "Caveman B" to have a delivery relationship on his task to "fetch some sharpening stones, suitable for stone age sickles" with an end-date "not later than February 19th". But the planning still included all those things that could be addressed - plus contingencies. In a reasonable manner. With all members of the relevant community being responsible for their respective contribution.

But somehow planning really got a bad name, when responsibilities got piled up on the shoulders of "the planner" and instead of covering all the sensible angles for the problem at hand, "the planners" started to cover all the angles of attack to their backs.

And instead of planning for things that can be planned, it became more important to produce plans that seem airtight so that the poor guy who wrote it can avoid being attacked.

But don't misunderstand planning in 'Agile' or lean - it's not "no planning" it is way more planning - it is just not done by someone from outside in advance, but occurs more often and is done by the people who are best suited to make the decisions.

On a sailing boat you don't necessarily plan for the exact wind that you find on the day of the regatta, but if the race is well planned you do have the right sails on board to enable the highly trained and specialized (!) crew-members to make the best of the situation. Each and everyone responsible all by himself!

Fortunately, the lean approach brings us some of the planning back. So now the topic of planning no longer is as much of a taboo as it used to be for a while.

One place to experience some of the methods and approaches for lean planning is the hands-on workshop on agile and lean practices Tom Breur and I plan to run in the autumn of 2013

I hear and I forget; I see and I remember; I do and I understand.

Benjamin Franklin... Benjamin Franklin? Or was it Confucius? He supposedly said:

Tell me and I forget, show me and I [might] remember, involve me and I understand.

Or was it actually Xun Zi (also written as 'Hsün Tzu', but not to be confused with Sun Tzu of "The Art of War" fame), the confucian philosopher who said:

"Not hearing is not as good as hearing, hearing is not as good as seeing, seeing is not as good as mentally knowing, mentally knowing is not as good as acting; true learning continues up to the point that action comes forth"

Wether you'd like to rely on the Wikiquote rendition of the saying or not, modern behavioral science shows us that there is actually quite a big measurable difference between learning by hearing and learning by doing.
That fits well with the recommendation that can be found in 'The Toyota Way':

"Start with action in the technical systems; follow quickly with cultural change [...] Learn by doing first and training second."

Quoted from the first two 'general tips' for organizations on a transition towards lean (emphasis added)

And perhaps this also is the reason why simulations (or games if you're not too heavy on political correctness) are such an important part of 'Agile' and lean trainings.
The only thing I am still missing in most of these simulations (except for the getkanban game) is the usage of the real techniques. That is one of the reasons Tom Breur and I created the Lean and Agile hands-on training with a strong focus on all the management methods, applied in some well known simulations.

Lean is not Agile, is it?

We live in a time where project management Methods exist in abundance and traditional methods compete with Agile (with a capital A) and lean approaches which in turn compete with each other.
But do they? First of all methods hardly ever compete - it's people who do the competing. The approaches just exist and either oppose each other, complement each other or have no relationship whatsoever. The Agile movement mostly was a counter-movement against the overly structured approaches to software development that came to live in the 1980s and basically this movement re-instantiated good practices from the 1950s and 1960s as for example Craig Larman points out in his article Iterative and Incremental Development: A Brief History.
The whole lean approach in turn surfaced as the Agile movement was taken over by the same people who enforced the rigorous methods of the 1980s and more and more problems in the value chain, but outside the core development efforts, became visible. David Anderson – one of the fathers of Software Kanban – calls Kanban (which is related to lean software development) a "post-agile" approach, which doesn't really help in differentiating Agile and lean but emphasizes the fact that they are not the same.
From my experience companies that focus on agile have highly productive teams but often lack an efficient flow across the value stream while companies focusing on lean tend to have a real efficient flow but tend to lack efficiency inside the teams. To employ agile techniques inside the stations along the value stream while managing the value stream itself in a lean manner to me seams to produce the best results.
To get a first hand experience of how to integrate lean and Agile approaches you might want to come to the workshop that Tom Breur and I will run on May 28th & 29th in the Netherlands