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

Sunday, April 16, 2017

Do we have a Definition of Ready (DoR) and Defintion of Done in Kanban?

Funny you should ask – this ties in nicely with the topic of explicit policies.

Here is a short answer regarding DoR and DoD

Conceptually speaking, every station in a workflow has either implicit or explicit entry and exit criteria. The notion of a DoR and a DoD (as they have become widespread in the Scrum community) is modeling exactly this: having explicit entry and exit criteria for a system with one station.

When modeling a system with Kanban, those definitions for ready and done really need to become part of the often mentioned explicit process policies.

An Example

Let’s take a look at a simple example.
Assuming we have two stations A and B –where work flows from A to B– we look at B first, honoring the principle that we work on Kanban boards starting at the point closest to the value generation: the customer facing side.

|    station A   |    station B     |
|  doing | done  |  doing  |  done  |
|        |       |         |        |
|       / \      |        / \       |
|      /   \     |       /   \      |
|     /DoR B\    |      /     \     |
|    (   ⊆   )   |     ( DoD B )    |
|     \DoD A/    |      \     /     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

In this scenario the “Definition of Ready” (the entry criteria) for station B has to be part of the “Definition of Done” for station A. Why? Well, the “Definition of Done” for station A is the DoD for the Doing column of station A. Once a work-item leaves the “Doing” column nothing should be done with it – after all it has left one Doing column and not yet entered another Doing column.

Therefore when B pulls an item it will – or at least should – be exactly in the state it was when it left the Doing column of station A. That being said, there may of course be additional rules governing the entrance to station B (e.g. if the item is part of a multi-part workflow).

For the topic under consideration “Do we have a DoR and DoD in Kanban?” the short answer would be “yes”.

Scaling up

In any life-size system, where we have more that two stations, multiple sets of entry and exit criteria make sense – one set per station (column). Whether we focus on the DoR or on the DoD first, is a matter of focus. Both approaches might be appropriate.

Taking this further, beyond A and B we get something like:

|    station A   |    station B     |   Station C    |…
|  doing | done  |  doing  |  done  |                |
|        |       |         |        |                |
|       / \      |        / \       |                |
|      /   \     |       /   \      |                |
|     /DoR B\    |      /DoR C\     |
|    (   ⊆   )   |     (   ⊆   )    |     . . .
|     \DoD A/    |      \DoD B/     |
|      \   /     |       \   /      |
|       \ /      |        \ /       |
|        |       |         |        |
|        |       |         |        |

From my experience, it is helpful to start thinking this through from the right hand side and consider the DoRs first. But then again life is complex and depending on your actual situation there may be other approaches that make sense.

Ceterum censeo: Of course we can model everything we have in a Scrum process with a Kanban system. Both operate at different levels and Kanban is meant to be able to model existing processes. The question whether you should move from one to the other is non-sensical by definition but conversely adding Kanban to Scrum actually makes a lot of sense.

Cheers
Michael

Sunday, April 02, 2017

Todo – doing – done is not “Starting with what you do now”

A couple of weeks ago I had this discussion about the Kanban principle “Start with what you do now” and whether or not that is the same as the “todo - doing - done”-value stream we know from personal Kanban.

Thinking that the two are the same is actually a very common misunderstanding.
”Start with what you do” now has nothing to do with “todo - doing – done” and actually predates personal Kanban by a couple of years. Todo-doing-done is a simplified concept that Jim Benson introduced to use the Kanban Method on a personal level. In Kanban terminology those boards are referred to as "proto kanban" – systems that might evolve into kanban systems.

"Start with what you do now" refers to the big difference in the approach. While in approaches like XP, FDD, DSDM or Scrum, you implement a whole new process, the Kanban Method’s approach is to model what you do now. In the Kanban system.

By simply stating todo-doing-done one does not yet model the way the actual team works.
Since the general workflow "todo – doing – done" is always true, there is not yet the connection to the way your team has agreed to work and no way to discuss specific process policies.

Facilitating the evolution of this very general approach to a system that captures how your team wants to work, and building the peer-accountability that is necessary, is one of the challenges for everyone guiding or coaching evolutionary improvement processes.

till next time
  Michael Mahlberg

Sunday, March 19, 2017

Going fast without a fast-lane or an expedite lane

Does an expedite lane make you faster? And if so, why not put everything in the expedite lane?
Well, for an expedite lane to work several things have come together – Work In Progress Limits (WIP-Limits) and explicit policies, just to name the two most important ones.

When should we implement a "fast-lane" and what does "fast-lane" or "expedite-lane" really mean?

People have started to use expedite lanes in Kanban-Systems quite a while ago to handle the fact that no rule is ever without exception. If a Kanban system’s WIP-Limits do not allow for any more work to be started, there occasionally can be exceptions to the rule – production issues, "boss-tickets" and the like. To avoid having individually negotiated policies per ticket (which would rather invalidate the whole "make process policies explicit" idea) one way is to have an open discussion about handling exceptions and the rules governing those exceptions. For example: an exception like "We allow one ticket at a time to exceed the WIP-Limit of the system, but it still counts as WIP for other tickets" would be expressed by having a separate lane for exactly this ticket. Obviously this only makes sense, once we have WIP-Limits (that’s what the word kanban in the term “Kanban System” refers to) in place.
("In place" means that the limits are not only written down, but actually honored.)

What should we do if there are no WIP limits (yet)?

So what to do if you don't have WIP-limits in place and still want to negotiate some kind of special treatment for some tickets? Let's assume we want to make tickets visible that are of a higher priority than others or that are in a volatile state because of environmental issues? (As it was in the case in question: Developers already started while the ticket is still in the discovery Kanban)

Clearly in this case an "expedite" lane would not really give the same leverage it would do on a Kanban board with WIP-limits. Still I would consider those tickets to be of a different class of service which could – depending on the maturity level of the system – call for a separate swim lane or just for a different color coding of those tickets.

The other idea that might be spurred is to use a special work item type to achieve the same result. From a practical point of view this would taint statistics and metrics since there is no different way of handling those tickets. Therefore it might actually harm the system and make its future evolution more difficult.

Most importantly I would explicitly mark those tickets blocked – with a dedicated blocker type – that have to wait while these high-priority tickets are handled. And I would run statistics on those blockers afterwards. And publish those statistics!

Without giving the false pretense of having a high maturity Kanban system with an expedite lane this approach allows for explicit negotiation of the policies for this class of service that can be changed and re-negotiated over time.

And you can always move forward to a real Kanban system (one that has WIP-Limits) later.

So, how are you going to speed up

Sunday, March 05, 2017

The "definition of done" for life...

...would be a scary thing, wouldn’t it?

Yet people often ask me “When will we be done with the change?” or “When will our working agreements (sometimes also called processes) be finished?”

But that’s just the thing. In an ever changing world neither working agreements nor processes nor environments can ever be finished. In our lives we don’t try to get to the finish – I, for one, actively try to avoid that for as long as possible. Most of us just have a life. One that is well suited to whatever the environment throws at us.

For me the question is not “When will the change be over?” but “which change do we need right now?”.

till next time
  Michael Mahlberg

P.S. It’s not the finish it’s the journey. Or, to quote somebody else:

Life is not a journey to the grave with the intention of arriving safely in one pretty and well preserved piece, but to skid across the line broadside, thoroughly used up, worn out and loudly proclaiming -- WOW-- What a Ride!
~ Paraphrased after Bill McKenna, professional motorcycle racer

Sunday, February 19, 2017

If you talk about "Moving from Scrum to Kanban" you have misunderstood at least one of them!

Scrum is defined by a specific set of roles, events, artifacts and rules that can make up a software development process when the specifics for your given context are resolved and defined.

Kanban on the other hand, provides mechanisms for controlling your work and improving the way you work together with a set of principles and practices like visualization, limiting work in progress, managing flow making policies explicit and a couple more.

Kanban does not provide counterparts to the things Scrum provides – rather, it is a complementary approach to any product development approach.

You can easily build a Kanban system for any given Scrum implementation - most of the time you just have to model four or five states, identify one to three capacities and define the cadence for the input queue and the output queue. A very simple approach here is to define the

  • Stations as "Backlog", "Selected", "Implementation", "Review" and "in production" (and make them visible)
  • (bracket) capacity of "Selected" through "Review" := throughput of last iteration
  • input cadence := output cadence := iteration size
  • iteration size := your sprint size

Of course the real power of the Kanban approach only begins after this stage, when you start to improve the way you work together collaboratively. But that would be another post...

Most of the time the processes inspired by the Kanban approach end up with a much more flow-based solution than typical scrum processes, and that is what a lot of people seem to mean when they talk about their evolution.

But please don't talk about "moving from Scrum to Kanban" – that would be like saying "I don't use a car anymore, I now use a GPS" – and you wouldn't say that, would you?

till next time
  Michael Mahlberg

Sunday, February 05, 2017

We don't need a “process” we have working agreements...

“Yeah, well, I had to work around the process to get this stuff done for the customer.”
Doesn't that sound familiar? And more often than not people on the same team nod in agreement and work on like nothing happened. And soon somebody else says “Yeah, well, I had to work around the process ...”

But how about “Yeah, well, I had to violate what I agreed to upon how we work together to get the stuff done for the customer?”
In my experience people tend to be more easily annoyed or even upset by this latter violation of trust. But even more importantly the likelihood that people will re-negotiate their working agreements is also significantly higher.

That's why I try to convince my clients not to talk about “the process” but rather about working agreements.

Enter Scrum and Kanban

Now this is where approaches like Scrum, XP, FDD, SDSM or Kanban, to name a few, can hugely differ. Take Kanban and Scrum for example.
While Scrum is a Process Framework with very strict roles (at least for the Product Owner and the Scrum Master) Kanban is an approach for process control and process improvement. In many Scrum implementations I have seen, people have to “work around” things from the book. When –to name an example– was the last time you saw a person acting as Product Owner really having the final say on priorities?

Kanban on the other hand explicitly requires that we “Make process policies explicit” (4th General Practice of Kanban) – I like to restate that as “make our working agreements explicit.”

And once we start negotiating these agreements we actually start to “Improve collaboratively, [and] evolve experimentally,” as the 6th General Practice of Kanban describes.

I suggest dropping the chase for the perfect process in favor of finding the best working agreements (aka process policies) for the current situation.

till next time
  Michael Mahlberg

P.S.: The "General Practices" used to be called "Core Properties", but since the Kanban Condensed Guide, "General Practices" seems to be canonical.

Sunday, January 22, 2017

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

Sunday, January 08, 2017

The “Pay to Learn” phase of projects

We should try to avoid waste. (Really?)

Nobody wants to create something just so it can be thrown away. (Really?)

Since “all universal quantifiers are always wrong”, those statements are probably not the whole story.

Even in lean eliminating waste is not as high a priority as one might think

In new product development – and re-implementing things in a different environment is new product development as well – a lot of effort goes into determining what the product actually is. And how to best build it.

Therefore some efforts are not waste at all, even if their results never go into production. In manufacturing and construction this is obvious for things like molds or scaffolding, but the same is true in knowledge-work as well.

Sometimes it makes a lot of sense to build something that will be thrown away, just to learn the right way to do it. Or at least a good way to do it.

Let’s have a look at Twitter for example. Twitter initially was build in Ruby (Ruby on rails to be exact). After a while it was rebuilt using different tools and techniques. So “obviously” the original implementation had to be “thrown away” at that time.
Does that mean that they shouldn‘t have started with Ruby? On the contrary – they ran with it for a couple of years. And they learned what they wanted to do with it.

But there are other things that you might not need in the later stages of product development – like dummy implementations of surrounding systems, paper mock-ups of user interaction, simulated server-roundtrips and a gazzilion more – but all of those help you learn.

And this "pay-to-learn" phase (with the willingness to throw away stuff that no longer is needed) is what often differentiates a really good product from a mediocre one.

till next time
  Michael Mahlberg

Sunday, December 25, 2016

It's a Task-Board, not a Kanban-Board (and oftentimes that is fine)

In years gone by – in the high times of eXtreme Programming for example – people used to have task boards.

Along came Scrum and for a while we used to see Scrum boards all around.

Nowadays we see Kanban-Boards all around.

Or don't we?

Without the Kanban it's not a Kanban-Board

In virtual Kanban systems (and that is what we're talking about here) the “Kanban” is the difference between the capacity of a column (the WIP-Limit of the station) and the actual work in progress.
Even though the first step of the Kanban Method is simply to “visualize work” the very thing that gives the method it's name – the Kanban – can not be present in boards that don't have a WIP-Limit.

Kanban focuses on value to the user - not on tasks

It's fine if you conclude that you have to complete a couple of tasks to create a thing that is of value to the customer, but not necessarily the most “Kanban-like” way to approach the situation. If you take the approach to it's extremes you end up with all tasks being just columns on your board
And no I don't recommend building db-, ui-, and logic-silos. But if you have them, be honest and acknowledge the fact. Change it afterwards. Start with what you do now as they say in Kanban.

So while on a task-board cards typically contain things like "Implement the FizzBuz", "Install the FizzBuzz" or "Deploy the FizzBuzz to production" on a Kanban board you would just have a card (representing a system capability) "FizzBuzz functionality" that flows through the value stream.

Sometimes a Task-Board is enough

Implementing a Kanban system is a great thing (IMHO) - especially if you want to improve the way you work together (formerly called “the process”) in a scientific way, manage flow etc. But just omitting Sprint-Plannings reviews and retrospectives and putting cards in todo-doing-done columns doesn't mean your board has become a Kanban board. But it's still a good start.

Often Task-Boards evolve to Kanban-Boards

When you start with todo-doing-done you might find that your discussions around the ‘real’ status of the tasks help you finding out how you really work together. Don't be afraid to adjust your Board accordingly. And perhaps after a while you'll be able to switch from tasks that get pushed over the board to system capabilities that get pulled.

Be honest about where you are so that you can improve to where you want to be.

till next time
  Michael Mahlberg

Sunday, December 11, 2016

Agile Documentation – a Reality Check

Working software over comprehensive documentation.

That's one of the value pairs a lot of people see (in the sense of really recognizing it) when they think about agile software development.

I don't want to re-iterate the simple fact that the manifesto just talks about valuing software over documentation and not instead. I also don't want to stress the old "While there is value in documentation we value working software more".
I don't even want to point out that the manifesto doesn't speak about all documentation, but only about comprehensive documentation.

Nowadays – where almost every software development effort is said to be "agile" – so many more questions arise.

"The code is the documentation" is sometimes true. Not so much if – for example – corporate standards enforce a development style that is far from SOLID. (You have heard about “corporate agile”, haven't you?)

"The tests are the documentation" is also sometimes true – but what part of the system do they describe?

Where is the business side?

To me, the currently worst idea in this context is the notion that user stories alone can describe the whole system. While there are many good approaches that contradict this notion (like user story mapping, impact mapping, product discovery etc.) there still is a lot of this mindset present in the wild. Especially when people use Jira and think that merely putting user stories in Jira tickets will leave the party who actually owns the product with a documentation that helps them in a year from now.

It does not. For one thing, often the level of abstraction is not suitable for everyone (how could it be – people work on different levels of abstraction). Another thing is that you can't describe a system by only listing the user stories without documenting the resulting decisions in some way. In this sense, having the user stories is necessary but not sufficient.

Think about creating a documentation around the other artifacts of your product as well. In an agile manner. When you create them. In a way that is lightweight, but strong.

And remember to refactor your documentation as well.

till next time
  Michael Mahlberg

Sunday, November 27, 2016

Let’s be Pirates... or Privateers

I've written a lot about self-organization lately and how difficult it is to garner the right ‘amount’ of self organization.

An interesting side-note was brought to me at a dinner conversation in a dark and shady tavern by sea, illuminated by the flickering light of the candles while the sea roared on the cliffs and a chilly wind... oops ... sorry... I got carried away.

The side-note has to with pirates though. Or, more to the point, with privateers and how self-motivation and extrinsic motivation can go hand in hand.

It has often be quoted that the real pirates of the Caribbean where amongst the first in modern times to have democratic organizations. For example the captain - although master over life and death during his tenure – was actually elected and the loot – pardon me, the prize) – was divided fairly (not evenly!) amongs those who participated in the venture.

But there is another aspect that I failed to see earlier. From what my friend told me, one of the reasons for the demise of the once great armada was the utilization of small independent, autonomously acting, self-motivated units. Privateers. Though historically this was certainly not the only reason the idea has a strong resonance with me and it nicely ties in with a lot of modern management approaches.

  • The privateers did what they loved to do. (The love for the seas amongst sailors is proverbial. And privateers – unlike the official Navy – were not in the habit of pressing people to service) => Purpose
  • The better they were, the more rewarding hires were available and the higher the compensations were => Mastery
  • If the results of their actions fitted within the Letter of marque the privateers were at liberty to do whatever they deemed necessary or helpful. (No dress-code, no imposed rules on how to change the guard etc.) => Autonomy

When I look at Privateers this way, they really have a lot in common with modern teams – although they usually had a way more grim work than our teams have nowadays.

Nonetheless the autonomous teams overthrew their centrally organized counterpart by a huge margin. Despite the fact that they were heavily outnumbered. I see some similarities with modern organizations.

till next time
  Michael Mahlberg

Sunday, November 13, 2016

Why self-organization is not like ’60 paces’ ::spoiler alert::

There is this game that people play during agile trainings called ‘60 paces’.

It is well known and shows how much more efficient self-organization is compared to a command and control environment.

I'll leave out the details of the game here. You can look them up on tastycupcakes.org via the link above, but if you haven't played the game yet, you would be depriving yourself of a great learning opportunity by looking it up. Allow yourself to be surprised, I think you will get much more out of it that way.

So this is more like an inside blogpost for people who have either played or conducted the game in the past.

In my opinion there is one thing missing in the game – a round zero. Where you just let people do whatever they want for two minutes. And ask the control questions (see game description) afterwards.

Then continue playing as described in the original description.

From my point of view this approach illustrates one aspect that is not addressed by the original simulation and which is also very often forgotten in naive lean and agile implementations:

Without a known and clear unifying goal there will be no progress towards any goal.

till next time
  Michael Mahlberg

Sunday, October 30, 2016

Self-organization does mean anarchy

From the “I don’t think that word means what you think it does” department.

<rant>
Ever so often I hear people argue that self organization does not mean anarchy. (Especially if the team wants to use non-corporate software, hardware, tool, etc.)

To me this seems quite strange because the opposite is clearly true.

Anarchy does mean without (an) rulers (archos) - or so wikipedia and my history books tell me.

Of course Anarchy (with a capital A) has so many connotations nowadays that most of them are not appropriate for self-organizing teams and I would strongly advise all self organizing teams not to take on the negative traits that have nowadays become associated with anarchy.

But stretch the boundaries – if the team is self organized, who is to tell that they have to work from their assigned workstations? Why shouldn't they put graffiti – sorry, architectural diagrams – on the walls?

We all live in a social system where we can only flourish to our fullest potential if we do not harm other people, but we have to question our rules relentlessly.

In my opinion it is a contradictio in adjecto if you tell a team to “... be self organized, but follow corporate policy to the letter ...”.

</rant>

till next time
  Michael Mahlberg