Sunday, April 08, 2018

Do I really have to? On Options and Commitments

Aside from the whole sprint-commitment thing, there is another commitment-issue I tend to have.

People often misunderstand options for commitments

And it can be very liberating to get rid of that confusion.

“I can’t go to that lecture, I already have a ticket for the cinema.” Is the cinema ticket an option or a commitment?

“I can’t go to that conference I’ve already booked flights for those dates.” Are those plane tickets options or commitments?

In their excellent book “Commitment“ Chris Matts and Olav Maassen look into this question in depth, but for now let’s just look at one very important take away from pondering the above questions.

#1: If something is an option or an obligation (a commitment) depends on whether you're buying or selling. The tickets in both cases are options for the person who bought them but commitments for the sellers. The cinema is obliged to show the movie, but I as a buyer have merely bought an option. I can exercise it or i can choose to let it expire. I am not obliged to go to the cinema, I have only bought an option to go there.

#2: Options have a value (and a price) (Almost straight from the book) Different options have different prices. Depending on my perceived value of the option I might be willing to pay the price or not. The option to fly somewhere might be more expensive that option for the movie, but still the question is what I am willing to pay. I am not obliged to take the plane. Thinking about it in that manner means that I did not pay for the flight (if I did I probably would pay when I enter or leave the plane, like with a bus ticket) I paid for the option to take that plane.

To me this way of thinking is quite liberating. Just make sure you know on which side of an option you are. People tend to loose a lot of faith if they were sold options and the other side doesn’t keep their commitment.

till next time
  Michael Mahlberg

P.S.: You can find a draft version of my take on real options on this blog including pointers to the whole background in Chris Matts’ and Olav Maassens’ excellent book and some online resources.

Monday, March 26, 2018

What is a commitment anyway?

Or: The difference between “having committed to something” and “being committed to something.”

This is not about the old story of the chicken and the pig who want to open a restaurant. Even though Ken Schwaber used this adage to illustrate the difference between commitment and involvement in the early days of Scrum, it is no longer part of the canon.

The version history of the scrum guide makes that quite explicit:

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.”

Still I see the term “commitment of the team” quite often. In publications and in ‘real life.’

I have to confess, I am even guilty of using it myself from time to time.

Like with many things in the world, the question is how we use them. In this case it is the question of how we use the term – and the concept – commitment?

There is a fine line, but a very important distinction in who does the committing. A while back I heard some General in a movie say that he “committed 20 troops” to some task. In yet another movie a team member explained the success of his team with the fact that “the whole team was committed to the cause.” So does that mean that the 20 people the General committed to the task will feel commitment to the task and thus succeed? Probably not.

And yet the statement “The team is committed to the sprint goal” is syntactically the same wether the team has committed to the sprint goal (e.g. each team member bought into it) or has been committed to the sprint goal (e.g. some higher authority spoke on behalf of the team without their consent).

till next time
  Michael Mahlberg

P.S.: But then again you might want to consider exchanging iteration based approaches with a flow-based concept and cadences and then you might consider “Department Y will be able to sell product X via channel C” as an idea for a MMF (Minimum Marketable Feature(set))

Monday, March 12, 2018

This is not an Epic

This is a rant...

In a “recent” post Mike Cohn outlines some of the misunderstandings around the the terms «epic», «user story» and «theme».

This article is actually only “kind of” brand new - it is from 2011.

But thanks to the prevalence of Tools and Process over Individuals and Interactions that has been brought to us by tools like Jira for more than ten years now, it seems to me that it is a good idea to look at a few key points again.

For example Mike says:

There's no magic threshold at which we call a particular story an epic. It just means "big user story."

So, sorry folks: an epic does not group a bunch of requirements that do not deliver value on their own together. According to Mike’s old post an epic simply is a story that “[one] didn't get the chance to break […] down into stories that are […] small enough […].”

That’s why it is such a good idea (at least IMHO) to do whatever you like with that “Epic” thingy in Jira – use it to mark other stories, use it as a theme (see Mike’s post for a short explanation of that) use it to signal states if you don’t have a Jira admin in your team etc.

But whatever you choose to do, don’t do functional decomposition by making your epic an enumeration of sub-functions that only deliver value if they are all implemented together.

...end of rant.

till next time
  Michael Mahlberg

Sunday, February 25, 2018

What happens left of the Scrum-board?

In the early days of Agile, Agile was very much about customer collaboration and concepts like the on-site customer were at the core of Agile. Nowadays, most on-site customers (actually a term from eXtreme Programming) are some derivative of Scrum’s Product Owners and most instances I have seen are far from the role Ken Schwaber and Mike Beedle described in their seminal work on Scrum in 2002.

Things have changed over the years, and nowadays a product owner (PO) in many places, especially at enterprise scale, is someone who devotes ‘a couple of hours’ each week to support ‘some team’. And even though this is definitely an anti-pattern from my point of view, it still is a reality we have to deal with.

The Agile Manifesto states quite clearly that “Business people and developers must work together daily throughout the project.” (4th principle) and one the biggest benefits of agile approaches in my experience is that they enable projects to start developing (and delivering!) before “all” the requirements are discovered. A huge part of this approach has to do with the fact that the whole team works on requirement discovery and the honing of the product vision.

But those teams are rare.

And while process-frameworks like Scrum – and the secondary literature around it – provide a lot of helpful guidance on how to deliver the solution there is very little said about the process of requirements discovery.

So I would like to challenge you to a little experiment.

  • Have a board “left of the board”
    • Instead of just having a backlog and backlog refinement meetings where requirements magically appear try to build a board for this part of your process as well!
    • Have just a few columns like “idea”, “described”, “accepted”, and “ready for planning” – whatever fits the real way of work at your place.
    • And here is another idea: Unlike on the Scrum board, perhaps here it is not necessary for all items to reach the stage - perhaps it is good if some ‘die’ on their way to the iteration planning.
    • And then observe... What happens on this board?
      • Do items ‘starve’ in some states?
      • Are there items with different speeds?
      • how many items ’make it’ to the next stage?

Who knows - you might learn a thing or two...

till next time
  Michael Mahlberg

P.S.: Inspired by Discovery Kanban of course... ;-)

Sunday, February 11, 2018

Why I hate "Inspect and Adapt"

Because more often than not, people don’t.

They way I grew up with agile, one of the basic tenets of all agile approaches was the notion that there is no prescribed ‘right’ process, but you have to do what it right at this point in time. There even was a lengthy discussion whether the approach should be called ‘agile’ or ‘adaptive’ when the agile manifesto was created.

Now I see people ‘doing agile’ all around in manners I sometimes fail to understand. And I hear complaints that the agile stuff doesn’t really work. And more often than not, the explanation I get is along the lines of “But agile says ‘inspect and adapt’ and we adapted.”

IMHO one of the best answers to that was written by Ron Jeffries and is called We tried baseball and it Didn’t work.

And what I see quite often when I hear that teams ‘adapted’ the approach they try to use, is exactly that – they adapt without doing the inspection of the real thing first. Go ahead - read it! :)

So if you want to use the inspect and adapt approach, please make sure that you have something to inspect before you adapt it.

till next time
  Michael Mahlberg

Sunday, January 28, 2018

How to single-handedly run a change initiative

That’s actually quite simple - you don’t!

A common way to facilitate change is by having change agents, and that actually seems to be exactly what is needed to make change happen. Yet the role of these change agents can vary tremendously – from someone requoting the initiative’s vision statement to everyone who wants to listen, to an agent of the workforce to seek out the best possible solution for the future.

Don’t get me wrong, I do love the idea of the “change agent” per se. I just found out that the name has so many meanings that it becomes either meaningless or extremely context-dependent. For my work – helping organizations adapting new ideas – I found that a change approach with a clear direction is quite helpful and very of a very small number (sometimes 1) of external consultants or coaches is brought in to facilitate this change.

Even though we would like as many people as possible to take an active part in the formulation of the new direction, most of the time that change needs some external insights that are not available from inside the system. As Jerry Weinberg would say: “The Fish is always the last one to see the water.”

So the kind of change agent we need in this case would be one who is amplifing the external influence and is the kernel of the internal change. Still not someone left to his own devices, but rather someone who acts in both directions as a focal point for the change. Multiplying the view from the outside and channeling the (numerous) questions that will arise from the inside. And while they will need to question the outside source often in the beginning, as time passes they will gain more and more knowledge – as will the whole organization – and will be able to drive more and more of the change from the inside.

There is a word in German that we use to call people who amplify the impact of others, we call them "Multiplikatoren" which would roughly translate to “Multipliers” in English. Due to an unexpected chain of event we ended up with the old English word “Multiplicator” to describe the role in a recent project.

I kind of like the word by now - the use of uncontemporary language makes it obvious that we don’t really mean “multiplier” in a mathematical sense and it still conveys the basic idea.

And IMHO having this kind of change agent is one of the key success factors for change inititives - lean, agile or else.

till next time
  Michael Mahlberg

Sunday, January 14, 2018

Getting to higher performing teams – controlling circumstances or training people?

Do you make jobs easier to do, or do you help people to become more capable?

Effectiveness and efficiency often come in conflict when a goal has to be reached and deciders start to feel pressure. But as Peter Drucker famously said:

“It is fundamentally the confusion between effectiveness and efficiency that stands between doing the right things and doing things right. There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”

But even if we are able to look at obstacles through this lens, and focus on the effective things, there is still the question of how to best do the really necessary things.
In today’s fast paced VUCA-World (Volatile, Uncertain, Complex, Ambiguous) most of the things we try to accomplish imply some kind of “gaining knowledge”. And that is where we can see a huge difference between players who are in the game for the long run, and those who are more focused on quick gains.

Let’s assume we have a new complex piece of equipment - be it software, hardware or something else. Learning to work with this new asset requires learning and education. And this is where we come back to the original question - “Do you make jobs easier to do, or do you help people to become more capable?”

The more efficient approach – and probably even the more effective approach – would be to train a few people to operate the equipment, and let them create procedures for the rest of the staff on how to use it. (Think e.g. “creating build scripts for others” in a software engineering context)

But here comes the kicker: as Jerry Weinberg once said “The more adapted we are, the less adaptable we are.” Being less adaptable means being less capable of responding to change.

So having these highly optimized processes makes the jobs of the other people easier (sometimes much easier) – but it takes away from the capability of the organization as a whole. A different approach would be to teach all the people affected how to operate the new equipment, and just have the specialist handle the initial (and perhaps subsequently necessary) research and education. The latter approach would result in a much more capable organization. Of course, after the organization has learned how to best use the new equipment it can still be – and often is – a smart decision to have specialists who know the equipment even better than the rest.

‘till next time
  Michael Mahlberg

P.S.: To give credit where credit is due: David Anderson mentioned the concept of “controlling circumstances vs training people” while we were working on the KMM (Kanban Maturity Model) – I just picked it up and tried to translate it to my own working environment

Sunday, December 31, 2017

Think “executable process visualization” instead of “task-board”

A lot of the boards I see in offices nowadays are called Kanban-boards, even though they are actually more task-boards. And while often that is okay there are some advantages that we’re missing out on when we settle for task-boards.

Why exactly do we do Kanban boards?

There is a multitude of reasons to introduce Kanban boards, but one of the main goals might still be to visualize the workflow. On the other hand visualizing the workflow can hardly be a means in itself. One of the ends the visualization can help to achieve is clarity. Clarity about what we’re really doing. Clarity about the state we’re in. Clarity about the state the work is in. The ‘last workflow you’ll ever need’ (todo-doing-done) doesn’t really provide much help towards this end.

Accept reality

Modeling the real workflow does help. While preparing a talk, a friend and colleague of mine, came up with what I think is a great metaphor. He called the Kanban board an ”executable process visualisation.”

And once we start to think about the board as an “executable process visualisation” this metaphor turns out to be quite helpful in detecting differences between our model and reality. Let’s assume we have some kind of daily standup and talk about the work items on the board. Now, as soon as we find we have to explain that the ticket (the work item’s representation) is still in the same place, but work has progressed to a different state, this is a strong indication that our model does not quite reflect reality. On the other hand, if we move our ticket, but the work item actually still is in the same state, this might indicate an overly complex model that needs to be simplified to reflect reality.

Talk about the way you work

The great thing about having an “executable process visualization” is that talking about the model becomes much closer to talking about the work and vice versa. “But I thought that would be the first thing to do” becomes a question of “In which column does it happen? Can we make that explicit?”

This way the visualization becomes a powerful tool to enable substantial discussions and continue evolving the way you work from there.

till next time
  Michael Mahlberg

Sunday, December 17, 2017

It’s a pull system – not “work on whatever you like”

In some circles, the term “Pull-System” has become a synonym for “My boss doesn’t tell me what to do, I can decide myself.” For me this completely ignores the fact that the term refers to a system and it’s properties, not to the way people in that system can behave.

Let’s assume a simple workflow consisting of four states:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |

When we push items into the system they will pile up in the state before the bottleneck in the system. This might look like this:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |        |  [ ] |
|         |  [ ]   |        |  [ ] |
|         |  [ ]   |        |  [ ] |
|         |  [ ]   |        |      |
|         |  [ ]   |        |      |

In this case “Accept” seems to be the bottleneck. So whatever you do the system will not be faster than the speed of the “Accept” column. No amount of “pushing” work into the system will make it faster. On the contrary - the more work piles up in the “Design” column, the longer it will take for new items to get through the system.

We don’t know yet how much work is completed, so lets make that visible by putting an “x” on completed items

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|         |  [x]   |        |  [ ] |
|         |  [x]   |        |  [ ] |
|         |  [x]   |        |      |
|         |  [x]   |        |      |

Looks like 5 items in the “Design” column are just waiting to be processed. (Items in the “Ordered” column are always done, in the example there is no doing in the “Ordered” column). Pushing another Item into this system will only increase the amount of work not done - like this:

| Ordered | Design | Accept | Done |
|         |        |        |      |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [ ]   |  [ ]   |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |  [ ] |
|  [x]    |  [x]   |        |      |
|         |  [x]   |        |      |

One simple way to convert this system to a pull system would be to limit the number of items per column - for example like this. (We’ll ignore how to come up with these numbers for the moment that would be the topic for another post)

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |
|         |        |        |      |
|         |        |        |      |

Having these limits on the columns, the system could never exceed the following situation – Non-withstanding the question whether the work items are done or not:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |  [ ]   |  [ ] |
|  [ ]    |  [ ]   |        |  [ ] |
|         |        |        |  [ ] |
|         |        |        |  [ ] |
|         |        |        |  [ ] |

Filling this system with done work and moving excepted work into the next done column we might find the following situation

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

And even though it is not yet visible to the naked eye this system already is a pull system if we add the simple rule that as soon as there is less work in a column than allowed by the limit we fill the column up to that limit.

Step one:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [x] ---> [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step two:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x] ---> Pull  |  [x] |
|  [x]    |  [x]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step three:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x] --->  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  [x]    |  Pull  |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

Step four:

| Ordered | Design | Accept | Done |
|   (3)   |  (3)   |   (2)  |      |
|         |        |        |      |   
|  [x]    |  [ ]   |  [ ]   |  [x] |
|  [x]    |  [x]   |  [ ]   |  [x] |
|  Pull   |  [ ]   |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |
|         |        |        |  [x] |

which leaves the system in the state where there is an open pull request to pull more orders from outside the system.

Looking at pull systems this way shows that the term "pull" does not imply that in each pull system individuals can randomly choose what they want to do next, but describes one of the properties of the system itself. The level of autonomy –and how much each person is able to work on the stuff they would like to work on– can also be a property of the system, but it is a different property.

Having "pull" brings numerous advantages: better predictability, a better balance between throughput and utilization, and a more sustainable workload.

till next time
  Michael Mahlberg

P.S.: Of course this topic is way more complicated than outlined here and the relationship between limiting WIP and pull is not quite as one-dimensional as pointed out by Donald Reinertsen himself on Twitter. There is also a nice write-up on the topic from FactoryPhysics when it comes to the more intricate details of this matter.

Sunday, December 03, 2017

Nowadays it’s Backlog Management

Back when Agile started out, the focus of many people was on getting things done. Getting things done the right way: with test driven development, continuous integration, merciless refactoring etc., and getting the right things done (with things like the planning game, the system metaphor, user stories and more).

And actually, software development became a lot better in a number of instances. Back then it was mostly eXtreme Programming for me, later things moved towards Scrum – at least in Germany, but also in a lot of other places. Still, the focus was on getting things done. Just by looking at the onmipresent "Scrum in «n» Minutes" presentations or even at David Harveys’s old but still excellent discussion of what is missing in those pictures it is easily discernible that most of the effort is put into the part where things get done.

Apart from the slightly disturbing fact that all those "agile processes" are in stark contrast with the first value pair of the agile manifesto ("Individuals and interactions over processes and tools") there is something else that is slightly underrepresented nowadays. Those pictures always start with an existing (product) backlog. Where does it come from? Of course the ScrumGuide includes the practice of backlog refinement (or grooming prior to 2011), but there is very little guidance on how to actually come up with – and refine – the requirements in the first place.

Even though there are many great tools available – Story Mapping, Impact Mapping, Buy a Feature, the Kano Model, to name just a few – they usually don‘t get too much air-time when agile practices are discussed. So let’s change that. Let’s go back to the old ideas – from eXtreme Programming times – of including the customer in the work, or let’s move forward to the Kanban way of managing work and model the whole value stream of the knowledge work and find appropriate tools for each section. Especially for those sections that lie “left of the backlog”

till next time
  Michael Mahlberg

Sunday, June 25, 2017

Can’t I multitask at least a little?

One of the questions that arises almost every time a new Kanban system comes to live is something like “But if I work on tasks in different stations (columns) then my personal WIP-limit has to be bigger than one, right?”

Well...

Let me answer this by a simple calculation:

Given the cold hard truth that multitasking actually means task-switching there is a very simple formula to calculate your effectiveness for the average task you are working on:

If n is the number of concurrent tasks, then each task is idling around (n-1)/n of the time.

If you work on one task at a time this formula yields zero. Because the task is never left neglected and you work on it all the time.

If you work on two tasks at a time, each of them is idling around 1/2 the time. On average.

If you work on three tasks at a time, each of them is idling around 2/3 of the time. On average.

If you work on eight tasks at a time, each of them is idling around 7/8 of the time. On average.

Or to put it in percentages

  • 1 task: 100% active, 0% idle
  • 2 tasks: 50% active, 50% idle
  • 3 tasks: 33% active, 66% idle
  • 8 tasks: 12,5% active, 87,5% idle

This means that a task that would take an hour on average will take 8 hours if you multitask 8 fold. On average. And that’s not even taking any costs into account for context switching!

So, yes can multitask a little, but –like magic– multitasking comes at a price. Be sure you are willing to pay it.

till next time
  Michael Mahlberg

Sunday, June 11, 2017

The round table - or how to make remote meetings (more) fair

Don’t single people out

In my opinion the worst way to have a remote meeting (aka conference call) is to have a bunch of people sitting around a phone while one person is sitting somewhere else alone in front of the phone. Even though the “80% of communication is non-verbal” theory from 1972 is mostly misinterpreted, a large amount of communication is not in the words alone. So this dysfunctional teleconference scenario deprives the single person of all the nodding, pointing, smiling, looking at the mobile, doodling on a notepad etc. of the communication.

Even a singe camera on the side of the many and a display on the side of the one person makes it way more balanced.

Two way video isn’t a bad idea either.

Don’t use huge video conferencing rooms

In theory, it is a nice idea to have two rooms equipped with high quality video gear and really large screens, so that it almost seems as if people sit in only one room.
In the real world this doesn’t work most of the time. Foremost because the two video conferencing rooms very often are reduced to two laptops at the ends of two conference tables.

Level the playing field

Yes, we all know that in person meetings are better than remote meetings, but if we have to do them, why not ornanize them in a truly balanced manner with equal rights to all attendees?

We live in a time where bandwidth doesn’t seem to be a problem anymore in most areas. The average TV nowadays sports a resolution of 4K. Even most office displays are capable of HD or better. So why don’t we go the easy way and instead of congregating in locations where we skew the communication channels, just use state of the art video conferencing software that allows for a gallery view of a dozen or so participants from our workstations so that all the participants have the same environmental conditions?

But I don’t like to be on video

Why not?
What is really worse when you’re on video compared to a real live meeting?
Of course you can’t (or shouldn’t) be in front of the camera in pyjamas and you probably can’t play World of Warcraft while on the call, but then again: would you do that in a live meeting? And if the virtual meeting is not that important, then it’s probably a good idea to say so and find better ways to make use of the time for all parties concerned.

But our company policy doesn’t allow for it

Bummer.
But hey, the upside is that you just identified a really huge cultural problem, that you and your colleagues can work on.

till next time

  Michael Mahlberg

Sunday, May 28, 2017

Planning like in an amusement park

In Kanban one of the most important metric is the lead time - either the local lead time between two stations or the lead time for the whole system, measured from the moment a client demand is accepted until the moment of delivery to the customer.
This latter part is not to be mistaken with a potentially shippable product increment or the comletion of development. Delivery in this case is the delivery of something that fulfills the demand of the customer and is actually usable by the customer.
A more drastic point of view, that could be taken is the time from the acceptance of the demand until the actual usage.

Planning with lead times?

From the question I get it seems that up-front planning with a system controlled by Kanban seems rather difficult to the average outsider - after all there seems to be no upfront planning and the systems only is measured “after the fact”.

You need a stable system

But that is only half of the story. Once you have a decent system in place and collect metrics on the different levels of work you can quite accurately predict the mean time it takes for a certain work item from the beginning of a queue to delivery. Of course this only works if the system is sufficiently stable, having a predictable capacity and a reliable flow management.
Regarding the different levels of work: think e.g. ‘Stories and Tasks’ or ‘Features and Tasks’ or ‘Initiatives, Features and Use Cases’ or other models of different levels of abstraction for work items. Klaus Leopold’s work on the Kanban flight levels is a very good resource with regard to this and details the different aspects from portfolio level to implementations tasks even more.
If you have a stable system with know rates of arrival and throughput you can start to put up virtual “current wait time from here” tableaus. Just like in an amusement park.

Queue Wait Time, Goliath at Six Flags Great America

CC-BY-SA Martin Lewison

How do you plan in an amusement park?

Now – if your tableaus are reliable – planning becomes kind of easy. How do you plan in an amusement-park? You look at the posted waiting time and decide if you really want to wait this long for this ride. If so you join the queue. If not you go somewhere else. You might come back to see if the queue has become shorter. But you can’t join two queues at the same time. At some rides there might be a fast lane for pre-approved tickets, but those are more expensive, slow down the regular queues and are limited in space. You might decide to leave a queue and go somewhere else as long as you have not actually entered the ride, but then you lose your spot.
Like all analogies this analogy is not a perfect match, but this kind of thinking actually helps a lot in planning when working in a flow based system.

till next time

  Michael Mahlberg

Sunday, May 14, 2017

“We need the historical data” is a complete straw man - at least for tickting (e.g. Jira) and version control (e.g. Subversion)

People get attached to tools. That is not a bad thing. It only becomes a problem once we become biased and start to rationalize our attachment with questionable reasoning.

One of the straw man arguments I hear a lot lately is the access to historical data that would be “lost” if we changed the system. Strangely enough this argument is used for at least two very different things – ticketing systems and versioning systems.

People tell me that they would love to change to a system that supports the team in modeling the actual flow of the work, but they have to stick with (a centrally managed installation of) Jira because otherwise “they would loose all the historical data”. In a completely different context other people tell me that they can’t move from the version control system subversion to the much newer version control system git because they would “no longer be able to access the older revisions.”

Event though both discussion are from different contexts, they share some similarities:

  • Read-only access for the historical data was – upon enquiry – absolutely sufficient
  • The relevant data could easily be kept available with very little effort.
  • People had no experience with the proposed “new” tools
  • In both cases a boatload of support processes was dependent on the old tools

The real challenge turned out to be training the people in a proper way and decoupling the support processes from the tools.

So, if there is talk about the necessity to access the historical data as a way to discourage switching to new tools, you might want to reconsider what is keeping you from switching to tools that are more appropriate for todays challenges. Is it really the need for historical data?

This is the 21st century.
Storage has become cheap.
Hardware has become cheap.

If you want to keep your historical data accessible, just buy a box to do so. Way cheaper than any sophisticated migration strategy.

On the other hand new tools require new ways of working – and whether that is quite as easy is something completely different.

I don’t want to say that changing tools is easy, my point here is that keeping the historical data is a straw man reason for not moving forward.

till next time
  Michael Mahlberg

Sunday, April 30, 2017

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