Finally, once we become agile, all the planning goes away, doesn’t it?

No, it does not.

To quote a few things

“Responding to change over following a plan” -- http://agilemanifesto.org

The manifesto does not say “don't plan!”

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” - attributed to Dwight D. Eisenhower

The major difference between agile planning and old style planning is that agile planning doesn’t happen up front, but just in time.

In mathematics there is a concept of an inherent complexity of a term that remains constant. A friend of mine explained it to me many years ago, but I can’t find the “law” related to this topic on the net. The basic idea is that it is quite easy to make a formula more simple by –for example– introducing a formula sign for the integral, but the overall complexity of the term remains the same. Introducing the integral sign only moves the complexity to a different place.

What kind of planning

Something similar seems to be true for planning. Without having at least some kind of plan it is hard to keep a group of people marching in the same direction, so you have to plan at least a little bit. If you ever hiked in an area without roads and pathways you probably noticed that it is only possible to plan in detail for the stretch of the way that you can actually overlook, but without having an idea about your next major destination you might end up spending the night in the open without anything to eat or drink.
So there seem to be at least two kinds of planning going on. Whether you relate those two types of planning to ideas like release planning, iteration planning, and task planning or not is of course up to you. (Some people might also think about release planning, sprint planning 1, and sprint planning part 2. But please remember that not all agile is Scrum)

Now for the big question:

Who’s doing all this planning in agile?

Most of the time when adopting agile you get rid of the fact that other people plan your work. But the flipside is, that –most of the time– the whole team has to take on the responsibility for planning. All of them. So don’t think that getting rid of other people planning your work also means getting rid of planning itself. Agile is very much about common sense, but that doesn't make it easy. Inherently tough things stay tough.

So, what are your plans?

till next time
  Michael Mahlberg

Addressing risk does not mean eliminating it

"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 best books written on risk management.

The last time I wrote about risk I focused mainly on the project level of things. Recent discussions led me to revisit thins topic within the context of the risks themselves.

Eliminating risks also takes away opportunities. Big time.

Depending on the source there are many different definitions of the term "risk." Mmost of the time it comes down to the severity of an unwanted outcome multiplied by the probability of that scenario. The names for “unwanted outcome” and “probability” differ from field to field, but the gist stays the same.
There are so many things one can do with risks.

• risks can be mitigated (seatbealts mitigate the risk of a crash)
• risks can be avoided (staying at home avoids the risk of a car crash)
• risks can be compensated (first aid at the scene of a crash compensates –a little bit– for the risk of the crash)
• risks can be reduced (distance sensors and assisted driving reduce the risk of a crash. So do speed limits)

Obviously (?) the option that avoids the risk is also the option that takes away the possibilities, the upside potential. You'd basically be going nowhere.

So when you look at your risk list and try to “eliminate them all” you might want think about other ways of addressing risk than just eliminating them altogether.

till next time
  Michael Mahlberg

Does PDCA equal “Plan the work, work the plan (and control that)?" – I don't think so!

I don't know how this came about, but a little while ago a friend of mine (whom I highly regard, both personally as well as as a project manager) came up with the notion that PDCA implies planning, having the plan executed (do), checking the results and (re)acting if they are not up to standard.

Maybe I am mistaken and that is, what Deming really means, but the way I understand his text and for example this talk by deming himself it is quite the opposite.

The way I understand it, it is an almost direct implementation of the scientific method:

• Plan: Formulate a hypothesis and design an experiment for its verification (on a controllable scale, including the definition of an expected outcome)
• Do: Execute the experiment (in a more or less controlled environment)
• Check: Verify the results from the experiment with the expected outcome
• Act: Either implement the changes from the hypothesis or don't! – Depending on the outcome of the experiment.

Am I wrong in my interpretation?

Cheers Michael

Scrum-But or Inspect and Adapt?

For a couple of years now I have heard people condemning projects as “Scrum-But”, mostly without even looking at the projects. And sometimes even without any reference to what they consider to be a scrum-but.

“but” what?

As you probably can imagine after my last two posts, I am especially suspicious if people do that without looking into the scrum guide. I keep experiencing people proclaiming something is a scrum-but because of all kinds of misconceptions. Sometimes “they don't have 2 week iterations” (the scrum guide calls for “a time-box of one month or less”) or because “they don't use Unit-Tests” (the scrum-guide states that “Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.”)

While it might be preferable to have shorter timeboxes (as the agile manifesto clearly states: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” [emphasis added] ) and that it is much easier to have a thoroughly tested product if one does have automated tests including unit tests, this is more about common sense (or agile experience) – but definitely not part of scrum.

Apart from the fact that more often than not, the same people carry the battle cry of the agile credo inspect and adapt as a default answer to most everything, there is a certain irony in the fact that nowadays we seem to have a kind of method police around scrum while the first value pair of the preamble to the agile manifesto reads “Individuals and interactions over processes and tools.”

If you do it, do it right

Oh, and don’t get me wrong. If you want to call it scrum: go by the book. But by the right one!
And remember that “Scrum is a framework for developing and sustaining complex products.“). And while on a programming level the “Instantiation of such a [software] framework consists of composing and subclassing the existing classes.”) the fact of the matter is that the same is true for a process framework – you have to define the specifics for your environment to be able to use it!

So – how do you shape your process?

till next time
  Michael Mahlberg

There are some situations where “agile” is the default mode...

Of course there are a lot of situations and places where agile approaches have become the default mode, and looking back at the history of software development with regard to iteratively-incemental approaches that is only a re-discovery anyway.

But in the big – a.k.a. Enterprise-Level – companies it’s mostly not the case. Or only in name but not in action.

Sometimes even “The Enterprise” goes into “agile”-mode

There is a situation when even Enterprise-Level software projects switch to an agile mindset. At least in most things but the name.

All of a sudden certain things start to happen:

• Business people re-prioritize on a regular basis (in short intervals even)
• Business people take the time to describe and verify the requirements
• Rollouts are allowed with very little overhead (sometomes called ‘hot-fixes’ in this context)
• Developers ask the people from whom the requirements actually came, what they want now
• etc.

Crisis-mode?

The situation I’m referring to is especially common for in-house-software that is developed for (and often in) large comapnies. Not all – only those projects that come into a crisis-mode phase at the end of the development phase.

I mean the time between the official end of the project and the time the software is actually in use. After the project has been declared finished, but before it is adopted for company wide use. When the last glitches are eliminated – which often takes up way more time than ‘planned’.
This crisis-mode is actually when everybody switches to things that work. And surprisingly these things are an interesting subset of what the agile manifesto mandates. (Of course I’m referring to the second page here)

Unfortunately some practices are not so important in crisis mode. Things like “sustainable pace” and “regular reflections” sometimes don’t seem so important in crisis-mode, but even the “continuous attention to technical excellence” is often more prevalent in crises-mode than in the day-to-day business during the run-time of the project.

So, here‘s an idea: If your enterprise shows the same crisis-mode behaviours, why not use this as a wedge to introduce more agile approaches?

’till next time
  Michael Mahlberg

Timeboxing and Zeno's paradox

Every now and again I run into arguments about the rigidity of time-box boundaries. Basically it goes like "But perhaps we could have finished what we wanted to do in 2 hours if we just gave it 5 minutes more. _Do we really want to discard 120 minutes worth of work just to save 5 minutes?"

You never have enough time

According to the best known of Zeno’s paradoxes Achilles (who was regarded to be the fastest runner of his time) will never be able to overtake a tortoise with a hundred step head start.
That is exactly the problem with the extension of time-boxes. Even if one would allow a maximum extension of 10% of the original time box to try to “finish it” it would likely still be unsatisfactory in the end.
Like the tortoise in the paradox (give wikipedia a short glance if you haven't already) the time “needed” for completion of the task would be extended an infinite number of times. However, after a couple of extensions, by infinitely small amounts. So in reality and for all practical purposes the timebox would last for 1,11111... times the time that was originally allotted. Which of course is a very specific time. 2 hours and 13 ⅓ Minutes if I am not mistaken.

So the point is definitely not to extend the timebox. It's got to be something diferent.

Parkinsons Law to the rescue?

As Cyril Northcote Parkinson stated in his famous law:

“work expands so as to fill the time available for its completion”

The funny thing is, that the opposite seems to be true as well: if there only is a fixed amount of time, as soon as people realize that it is really fixed, they tend to come up with something usable in that time, effectively applying “design to budget” approaches to things like meetings as well.

And – after people get accustomed to working in timeboxes – the results usually show up shortly before the time is up.

And if they don't sticking to the timebox will help you to plan more realistically the next time around. Just don't fool yourself with 2h timeboxes that tend to last for 2:15 ... ish ...

So – just stick to the timeboxes – use them to your advantage instead of fighting them! (And remember to size them realistically!)

till next time
  Michael Mahlberg

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

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"

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.

Note to self 13 - you can't assign responsibility, it has to be assumed

Michael, you might be able to say - or even order - that somebody is responsible for something but that doesn't really make them feel responsible for it. If he is assigned that responsibility without assuming  the responsibility he will most likely find ways to delegate this responsibility and to redefine the borders of the responsibility. 

An example for assumed responsibility would be this guy I know who develops his own software for a living - they lengths he goes to circumvent the glitches of the operating systems are impressive. For example even if the java installations on the client machine are completely effed his software will still try to figure out the best match for his needs and will 'just work' - Although he could just lay back and take a position of "Well, if the user can't correctly install java it's his problem" he doesn't. He feels not only responsible for implementing his software. He feels responsible for the users experience with his software. (And given the fact that he is able to make a living from a $30 software package his commitment seems to pay off)

It's unrealistic to expect this kind of behavior from people who are assigned responsibilities - especially if they don't believe in the goals or the underlying beliefs of the people who try to assign the responsibilities.