Don't get hung up on ‘Business Agility’ too much

To quote a currently very popular insight:

“As long as you don’t have your Business Layer under control, it doesn’t matter how agile your teams are.”

And YES, there is some truth in that. But it can turn out to be a logical fallacy.

And that is where I have my beef with the lure of ‘Business Agility’, because a lot of people think, that it is enough to focus on that level now. Not in my experience.

Having the awareness is –as the mathematicians would probably say– necessary but not sufficient.

An organisation is a system of interconnected systems (or services to use the terminology from the Kanban method) and if these underlying systems don’t work then all the ‘business level coordination awareness’ in the world won’t change much about the delivery capability of your organisation.

You can invest as much as you want into power steering (Servolenkung in German) and slip control – as long as your car is sliding sideways on an ice slope with slicks for tyres it actually pays to invest into better tyres before you start fiddling with the higher level elements.

As long as your business analysts don’t know how to quantify a business value, your engineers don’t know how to reliably ship the product, your sales people don’t know about the capabilities of your delivery services (sometimes a.k.a. development teams), or –in short– your teams are still at a low ‘agile’ maturity you won’t be able to steer the business.

The bottom line is:

As long, as your team level maturity is too low, you can improve the business level as much as you want – it won’t make a difference.

Therefore:

The maturity of an organization has to be evolved as a whole. The evolution at team-level, business level and strategic level has to go hand in hand

till next time
  Michael Mahlberg

P.S.: But if you focus on Business Agility alone at least some people in the organization will feel good. For about six to twelve release-cycles. Because –in my experience– that’s how long it usually takes the organization to come to this realization. [That can be up to three years btw...]

Let MoSCoW help you with facilitation and workshop design ;-)

Interactivity vs. Schedule

When designing a workshop –or any session– you facilitate one crucial aspect is timing. But timing gets complicated when you have lots of interactive parts in the session in question. And we know from research about training and oftentimes also from personal experience, that interactive elements are essential to successful sessions, so there is a serious incentive to include interactive stuff. The same holds true for other kinds of meetings as well – from design sessions to board meetings.

Balancing being on time an interactivity with MoSCoW

There is an old idea, made popular in the early days of agile by its extensive use in DSDM called MoSCoW. The capital letters in MoSCoW stand for Must Should Could Won’t and the «o»s are just there to make it sound nice. Without looking into the original priotization method too deeply, thinking about the design of a session in therm of MoSCoW categories helps a lot in balancing timeliness and interactivity. Especially if you combine the MoSCoW thinking with the concept of Heijunka or work (load) leveling.

Designing the session

In most sessions, especially in teaching, it is not a good idea to have all the musts at the beginning – because of the way people learn a schedule should not be a backlog where you put all the important stuff up front and the rest at the end anyway. The approach that I have seen to be usefull to a lot of facilitators, is to make shure that your schedule consists of a well balanced mix of must, should and could elements. What ‘well balanced’ means depends on the circumstances of course. Assuming we’re in a training situation and we know only very little about your audience, we might want to include more ‘could’ elements than we do when we’re working in a well known setting. This is the Heijunka part – heijunka literally means ‘leveling’, but in the context of lean the meaning is extended to something like ‘smart leveling.’

BTW: In meetings that need to have decisions at the end, one of the must items –come to decisions– needs to be at the end. So it’s a very good idea to have discardable parts in the schedule even if the sessions you’re facilitating is not a training.

Applying triage as you go

Now while we run the session we don‘t want to constantly check the clock to see if we’re either too fast or too slow. Quite to the contrary. We do look at the time often, but we use our projected agenda (including the MoSCoW classifications) to adjust as we go. When we’re ahead of the time (e.g. because the audience is faster than expeted) we can transport a bit more information and include the could element that we put in our internal agenda. Should we be slower than planned we cut one of the should elements. By using this approach it is way easier to keep the value for the participants high for the whole session. (As opposed to lumping all the unimportant stuff at the end, so that we also could skip it – as we would do it in a prioritized backlog apporach.]

Just give it a try...

till next time
  Michael Mahlberg

Is that “start with what you do now”-principle from kanban still ‘true’?

One of the pillars of the Kanban method is the principle “Start with what you do now.”

Looking at it historically, this was especially related to the fact that there is no need for any additional roles, meetings, or titles when introducing the Kanban method. In the early days that was such a stark contrast to other process improvement approaches that you still can find the foundational principle “Initially, respect current roles, responsibilities & job titles” on some Kanban method websites. Today this message has become part of the “Start with what you do now”-principle (as the second bullet point).

Over the years the body of knowledge in the realm of Kanban has grown and with some of the “newer” ideas there are a number of aspects that seem to contradict this very notion.

One of the more prominent ideas in this respect is the whole landscape of “Discovery Kanban”, “Customer Kanban”, and “Upstream Kanban.” Basically this is the idea to not only manage the delivery of work through a Kanban system, but also manage and organize the discovery of options with a Kanban system. Conceptually this has been described by Patrick Steyaert and it has been incorporated in the Kanban method as can be found e.g. in the related book Essential Upstream Kanban.

Yet, many companies don’t actually have a managed options discovery process – so where does this leave us with regards to the "start with what you do now"-principle? One possible starting point is David Anderson’s example for combining discovery and delivery kanban. This is a little different from the approach Patrick is describing, and most probably not exactly how the items “on the left“ of your delivery Kanban system flow now. (That is of course regardless of whether you call them “ideas“, “options”, “feature requests”, “demands”, or anything else.) But in my experience it is a very feasible way to get to “(finding out and) starting with what you do now.” As in so many cases, even though there might not be any formal discovery process, once you start looking into the details of the existing items and their history you might find that there is an informal process to be uncovered. It might more or less conform to the concepts lined out in the system descibed by David J Anderson, or not. Even if it doesn’t, just by having a board conforming to those concepts, trying to fit the (existing or assumed) items on it and facilitating the discussions around it, there is a good chance that you either uncover the real process or already evolve the process to something a little bit more fit for purpose.

Still, you actually started with what you did then – no new roles, no new processes. Not initially at least. Probably some processes evolved from having the discussions about the relative position of items on the board and how to get them there. And that is already the Kanban method at work as a change-management approach.

till next time
  Michael Mahlberg

P.S.: Thanks to Tim for bringing up this issue about “start with what you do now.” Nice catch.

Which change-management approach is required to implement Kanban?

Well, there's the thing: the way I understand it, the Kanban method is not an end in itself – it is quite the other way round. Kanban is the change-management approach.

As lined out in the book that defined the method «I [David] subtitled this book, “Successful Evolutionary Change for Your Technology Business.” I did this to underscore the point that the main reason for adopting Kanban is change management. Everything else is secondary.» (emphasis added)

Over time the Kanban Method has evolved, and with the current material there are quite a few additional actionable tools available which hugely extend the original book. But for me, the core is still the same. You use the Kanban method to enable change – simultaneously giving people control over the processes (the process control or service delivery part) and enabling evolutionary change by making formerly intangible things visible and negotiable (the –evolutionary– change management part)

Of course, there is STATIK, the Systems Thinking Approach To Introducing Kanban, but once again, this is not an end in itself. And it only is an approach to introduce the Kanban method. All the organizational change that comes after that is not driven by STATIK, but by the Kanban method itself.

So, I guess what I'm trying to say is "Don't ask what you have to do for the Kanban method, ask what the Kanban method can do for you."

till next time
  Michael Mahlberg

Why are there no product owners in Kanban?

Or perhaps the better question would be: Are there no product owners in the Kanban method?

It is actually a question I hear more often lately – especially since I started to publicly rant against the misnomer that “product owner” has become.

The question doesn’t make too much sense

As I mentioned earlier it does not make too much sense to directly compare the Kanban method and Scrum because they exist on different levels. Same is true for their lingo.

The Kanban method neither promotes or prescribes roles

There is no formal definition of any role. (cf. Essential Kanban Condensed, p. 33) The aim of the Kanban method is to help create systems that can evolve, following an agreed upon –and in itself evolving– set of explicit policies. That being said, there are roles that the Kanban community has observed as emerging in many Kanban scenarios, but those are not prescriptive. (And of course, there’s more to the Kanban method than explicit policies – bear with me for the sake of the role argument with regard to the product owner)

Are there any product owners? Anywhere?

The first principle I ever heard when I learned about the Kanban Method was “Start with what you are doing now.” I'm personally quite fond of the statement “Accept reality.”

Accept reality

However you put it – the role that is described as a product owner in the original scrum literature (imho that would be Schwaber, 1995 or Schwaber, 2003) is very hard to find out in the fields. As a story goes which makes its round in Germany right now, some famous product development guru (if someone could point me to the source I would be happy to quote the original source) asked a room full of conference attendees how many of them were “product owners.” Almost everyone raised a hand. The next question was “Who could end their product tomorrow?” No one lifted a hand. Thus the stated conclusion was “So – we don’t have any product owners in the room.”
This might sound a bit harsh, but it points to a quite valid aspect of working together IMHO: the question of our understanding of that role.

What is a product owner?

In today’s reality, there are many people who are called product owners, but who aren’t really product owners in the original sense. That’s not as bad as it sounds. At least many people have a rough idea of what a product owner could be. The trouble is that there are many different interpretations of the role. Unfortunately only very few of them are coherent with the original definition. Given that the process descriptions out there use the term as it is interpreted in their context, problems arise when business analysts, subject matter experts, product managers, requirements engineers and other people working on the conceptual development of products are all collated into the umbrella term “product owner.” If you hold people accountable for ordering work items who are specialized in requirements analysis or if you try to get the conceptual sign-off for a new decision table implementation from someone who’s area of competence is customer management it is highly probable that you will be disappointed. “You” in this case can be anyone – from the CEO to the customer to yourself. I have witnessed huge disaggreements about the competencies of the different product owners (note the plural) that work together with a team. A lot of these arguments vanished when we dropped the name “product owner” and used terms appropriate for the real expectations and competencies. But then the process models had to be adapted to these new names. Which, in itself, is not necessarily a catastrophe, but –more often than not– only the end of an illusion. Those descriptions had to be adapted because they didn’t fit “anymore.“ Actually, they never had, but with the new wording, the discrepancies became visible. And all of a sudden, a model of the real –living– workflow became visible.

The Kanban method makes these things explicit by default

Amongst other things the Kanban method encompasses 6 practices –Visualize [work and workflow], Limit work in progress, Manage flow, Make policies explicit, Implement feedback loops and Improve Collaboratively, Evolve Experimentally.
By applying only two of them – “Visualizing” the real workflow and “making [the real ] policies explicit” – you already can find out if there are product owners in your actual workflow. And by applying the other practices and policies you can evolve (step by step) your technology business to an organization that is fitter for purpose than it is today. But that would fill a whole book. Or several. :-)

till next time
  Michael Mahlberg

We need more "Wax on - wax off"

(Thanks to Falk for brining up Mr. Miyagi here)

If you have never seen – or heard of – the 80ies movie “The Karate Kid“ the phrase “Wax on - wax off” probably won't mean much to you. Fair warning: spoilers ahead!

Amongst other things that happen in the movie, the relevant part here is that Daniel learns karate from Mr. Miyagi, the handyman for the family's apartment. Without delving too deep into the story, in the beginning, Daniel is demanding from Mr. Miyagi that he wants to learn kicking and punching, but Mr. Miyagi stalls him for quite a while giving him seemingly unrelated tasks to do in very specific manners. For example, Daniel has to shine a considerable amount of classic cars following a very explicit process, using one hand to apply the wax (wax on) and the other to polish (wax off) in precise circles. After a number of chores Daniel gets unhappy with being Mr. Miyagi's “slave” and Mr. Miyagi demonstrates that all those “chores” actually built capabilities which Daniel didn't have before and all the “techniques” he learned, like “paint the fence”, “sand the floor” or “wax on – wax off” could actually – once they where mastered – be quite powerful and effective tools (e.g. defensive karate techniques and blocks) that Daniel would use throughout his further Karate training and his tournaments.

Side Note: Of course there are clips on youtube depicting the "building the muscle memory" part of the story as well as for the part where “the learnings are applied.”

How does this relate to agile?

To me, it seems we have a lot of focus on advanced agile topics and managing agile teams (and I‘m not even talking about scaling agile) and less and less on the basics of working in an agile manner. But from my experience, it is paramount to have the basics at your disposal all the time. Even with all the “Agile Mindset” in the world a racing car team (like Wikispeed, who actually apply lean and agile approaches to building race cars) would not have much success if their team members weren’t highly skilled in their respective crafts. You can’t pick a random person from the street and just expect them to be proficient with a Torque wrench or a Gas metal arc welder.

IMHO honing the basic skills would do many agile initiatives good. Speaking from my personal experience, even if it seems tedious and even if it is not the sexy “punching and kicking” - every now and then it does help a lot to focus more on “wax on – wax off.”

till next time
  Michael Mahlberg

Scaling ≠ at scale – Remember: «at scale» means something different than «scaled»!

It might be because I'm not a native speaker, but there is something about "scaling agile" or "scaled agile" that really has been bothering me these last couple of years.

As I wrote before in my recollection of events agile was described as something that works well for small teams.
IMHO at least two of the principles, namely "face-to-face communication" and "architectures, requirements and designs from self-organizion" are extremely hard to do in larger groups – unless you add additional constraints like structures (aka hierarchy) or special roles outside each individual group of people or team (aka specialists).

So what are we talking about, when we talk about Agile at scale? At scale means (according to YourDictonary.com) to have something that is "at the required size to solve the problem." Scaling on the other hand means "a linear transformation that enlarges or diminishes objects."

What does that mean for scaling agile approaches?

Do we really want to scale e.g. the number of people involved in solving one specific problem? Because, actually the communication overhead does not scale linearly – it 'scales' according to Metcalfe's law and thus communication quickly becomes inefficient. (With 5 people there are only 10 unique ways of communication, with 12 people the number is already 66)

Therefore: Why do we keep talking about "scaling agile?"

I think we should talk about "appropriate solutions at scale" and strive for them. That might include approaches from the lean and agile communities, some implementation of the Kanban Method to facilitate the change and many other ideas that are appropriate for the actual challenges at hand. When we truly live in a volatile, uncertain, complex and ambiguous world, than maybe the solutions for big and complex organizations can also only evolve over time according to each specific organization.

till next time
  Michael Mahlberg

When implementing Kanban, don't underestimate step 8 of STATIK

When you first start of with Kanban, you might hear that there is a very clear cut way to introduce it – it is called STATIK, the Systems Thinking Approach To Introducing Kanban.

For me this is not always the way to go, but it definitely is a way you should know. As long as you don't think that you can introduce the Kanban method with a half day (or one day) STATIK-Workshop.

Let's look at STATIK briefly: The way David Anderson describes it on his linked-in post STATIK consists of 9 steps. (There are other descriptions as well, most notably Mike Burrows' version from the Book "Kanban from the inside")

• Step 0: Identify Services
  [For each service]
  • Step 1: Understand what makes the service fit for purpose for the customer
  • Step 2: Understand sources of dissatisfaction with the current system
  • Step 3: Analyze demand
  • Step 4: Analyze capability
  • Step 5: Model workflow
  • Step 6: Discover classes of service
  • Step 7: Design the kanban system
  • Step 8: Socialize the design and negotiate implementation

(I just quoted the summary, the full description is available in David's above mentioned post on LinkedIn )

Starting with step 1 through 7

While it is true that you could hold a STATIK Workshop for the steps one to seven in a really short amount of time, I have never seen the Kanban method implemented this way. I have seen quite a lot of Kanban systems implemented this way. But that's not quite the same – defining a system that reflects a certain point in time is different from embodying a method that fosters ongoing change.

Why I think step 8 is the most important one

Remember – as the titel of the defining book says - it is an approach to change: "Successful Evolutionary Change for Your Technology Business". And I have yet to see a system with human actors that can be changed in a day. Especially because the goal is not to change it only once, but to enable it to continue to do so in an evolutionary manner.
Therefore I think that step 8 is the most underrated Step of STATIK and would strongly suggest to use the result of steps 1 to 7 (a hypothesis the current system) only as a starting point for the work that starts with step 8 – implementing an approach to collaboratively strive for improvement through evolutionary change.

till next time
  Michael Mahlberg

P.S.: For some inspiration on steps 1 to 7 you might also want to look intoAlexei Zheglov's Posts on the approach and the Canvas/A3.

How to visualize the (IMHO) most important metric of the Kanban method

In my humble opinion the Lead Time Distribution is the most important metric in the context of the Kanban method.

Your mileage may vary, but that would be the topic for another post.

A brief mailing list discussion about ways to get this in Excel triggered me to make a list of some of the approaches I use to get to that metric. (Only some of them with Excel)

Content:

• Google Spreadsheet approach
• Hand-rolled Excel
  • Percentiles for given durations
  • Dates for given percentiles
• More versatile hand-rolled approach w/o Excel
• Closing thoughts

Plot and percentiles in Google Spread-Sheet

I would feel remiss not to mention the works of Emily Webber: https://emilywebber.co.uk/a-tool-for-tracking-kanban-projects-that-you-can-cut-out-and-keep/

This gives most of one could want for the evaluation of a physical board.

Unfortunately, it isn't Excel yet, but "only" google-docs. Exporting to Excel "kind of" works, but the most important formatting is rather distorted, so I wouldn't exactly recommend that route to get to Excel.

Maybe it is right for you, maybe not. Give it a shot.

Percentiles per given durations in Excel

I used Excel quite often to generate percentages (not yet percentiles), usually inversely by pointing out the percentile that a given duration falls into.

This leads to heat-maps like the one on the right (from my talk at the 2018 LKCE ) but you don't necessarily get the exact numbers for the percentiles – and it is achieved by a concatenation of manual bin sorting, Summing up the results for each bin and comparing that to the maximum number of occurrences for this type of work.

You can find a simplified example (for only on type of work) in [this Excel-Sheet.](http://www.consulting-guild.de/files/ExampleHeatMap-GeneratedData.xlsx) The raw data is in the first tab, the bin definition in the second and the evaluation in the third. All tabs are named accordingly.

Durations for given percentiles in Excel

Excel already has a built in function called PERCENTILE which yields the mathematically correct percentile over an array of numbers (e.g. lead-times)

For the Emily Webber Data this looks like this: (In the German Version of Excel they translated the names of the functions and hence PERCENTILE is called QUANTIL)

The more flexible approach (without Excel)

Still, sometimes this is not quite what you need and the whole structure of the "chains of Excel spreadsheets" which tends to arise from the Excel-based approach tends to become too brittle (or too solid) after the first two or three improvements-loops.

Nowadays I recommend evaluating Jupyter Notebooks for this kind of scenario. It seems to require programmings skills, since the statistics approach is based on (amongst others) Python, but actually it is quite approachable and most people who are comfortable with complex Excel sheets tend to fall in love with it quickly.

My colleague Martin for example is using this approach for a very flexible evaluation of data collected from physical boards.

It can look like this, but can be easily extended if you need more complex statistics or shapes.

Closing thoughts

IMHO – provided the work-items are coarse grained and the time you want to inspect is not too long – oftentimes it pays to ditch electronic tools in favor of more mechanical approaches as outlined in the talk I mentioned above. (Unfortunately in German)

And for more elaborate mathematical elaborations while still working in Excel I find Troy Magennis Excel-Sheets an extremely helpful ressource.

till next time
  Michael Mahlberg

Attention bias or Dunning-Kruger?

There is a lot of talk these days about the Dunning Kruger effect and cognitive biases in general like the fundamental attribution error or attention bias. While the Dunning-Kruger effect essentially describes the learners misinterpretation (notably: overestimation) of their level of competence after they have acquired the basics of a topic, it is often used for bashing people who seem to be over-confident without really knowing much about subject they are talking about. But does it always have to be just Dunning-Kruger? I don't think so.

A while ago, someone made a nice – or rather not so nice, but unfortunately very on point – joke about the incompetence of a company that wanted to hire a developer with "8+ Years of Swift experience" in 2018, pointing out that the programming language Swift came into life only three or four years before that.

Being annoyed with a lot of enterprise recruiting myself I answered with a picture of the Suzuki Swift car that was in production from 1983 onwards...

After some laughter we realized that we had fallen prey to some kind of bias, because actually Swift as a programming language is way older than Apple’s incarnation of it. There is a scripting language called Swift, targeted towards parallel processing in the high performance computing area) ... from 2007.

We obviously fell prey to cognitive bias, but I'm still struggling to find out which one.

But that was a good cue to pull out my favorite visualization cognitive biases that used to be part of the wikipedia article on cognitive biases, but now they have a really stunning list of cognitive biases.

The fascinating take away from this whole story for me was, that for days after I had toyed around with the infografic and the list, I caught myself repeatedly being more aware of potential cognitive bias pitfalls. It might not help against the Dunning-Kruger effect (or does it? I don't know, I'm not an expert in that area ;-) ), but it surely helped me with looking twice.

Or –as Alan Lokos might have said once– "Don't believe everything you think!" :-)

Cheers
  Michael Mahlberg

What change initiatives can learn from steam engines

[I once saw this on a slide at a conference – I'd love to give due cerdit,
but I can't find the original source. The conference was “Tools 4 Agile
Teams” 2017, but I can't identify the session in this picture]

Structure > Culture > Strategy

or

Structure trumps Culture trumps Strategy

That sounds catchy, but actually there also is quite a bit of a story behind it.

The second part originates from the almost famous quote “Culture eats strategy for breakfast" that is often used to explain why so many strategically motivated changes just dry up at the department or team level.

The first part comes from what Craig Largman calls “Larman's Laws of Organizational Behavior” in which #5 reads "Culture follows structure" and implies that culture itself can not be changed directly but only by changing the structure.

Whether these statements are true is hard to decide – neither of them claims to have any hard scientific evidence. I, for one, certainly have seen more than one case where these observations not only held true, but were also helpful to keep in mind.

A great example on the domination of structure over the other aspects comes from a blog-post on the time when steam engines started to be replaced by electric motors. At that point in time, steam-engine powered factories had widely replaced individual workshops and the usual layout of the shop floor was optimized to make the best possible use of the power provided –via mechanical shafts– by the steam-engine.
Along came electric motors, which –theoretically– offered a huge benefit in efficiency and effectivity. But when factories shifted to electric motors nothing much changed initially. Simply replacing the gears, shafts and belts of the steam engine didn't really enable more efficiency or effectivity.
Only when the factories started to change the fundamental way they worked did the electrification make a difference. Once the newfound flexibility was leveraged and the shop floor layouts were rearranged to follow the flow of production work, a steep increase in both effectivity and efficiency became apparent.

Kind of how agile approaches to product development enable business agility, but need to be leveraged to really make a difference.

till next time
  Michael Mahlberg

P.S.: I haven't yet read the book on “Building the Agile Business“ that Peter Abraham and Neil Perkin wrote (simply because I didn't find the time to read it yet) but I do love at least one of the points they make in their above mentioned blog post. So by now the book is definitely on my "to read" list.

Know thy commitment! (In Scrum or in Flow)

I wrote about commitments and commitment points earlier – this is a condensed version focusing on the distinction.

Commitment in Scrum (as part of the planning) was about the promise of a group of people.
(Caveat: The term is not in the Scrum guide in this way anymore)

Commitment in Flow is about the status of a work item.

In flow-based systems, “committed” for a work item means that this work item is being worked on now.

The work item is meant to be neither idling nor pulled back from the workflow until it is released (to the customer to whom it is meant to be of value).

In Scrum, “committed” for a team meant that the team strives to achieve a goal by all means necessary.

The team was meant to work towards this goal and deliver something that enabled the negotiated customer capability.

“Just” a distinction to be aware of in discussions about commitment...

till next time
  Michael Mahlberg

Why all the boards for your lean and agile teams should be visible all the time

A simple answer would be: spatial memory.

A slightly longer answer could be: spatial memory and confirmation bias.

(Oh, and by the way: They should be visible all the time only for the people who need to see the information on them)

But let's put that into context. Why are spatial memory and confirmation bias important for the way we use boards in Agile teams?

As many people have pointed out in the past Agile doesn't fix any problems, it just makes them visible, so that it is easier to do something about them. One of the tools agile teams started to use early on to facilitate this is visualization. A team, working towards a goal, visualizes the information they need to know about. This can be all kind of information –which might be a topic for another blog-post–, but one of the most prominent visualization techniques is the taskboard. Taskboards are especially helpful for knowledge workers because the very nature of our work makes it impossible to directly perceive the status of the work – let alone knowing how much work is currently in progress. The Kanban method went so far as to have the notion of ‘making invisible work visible’ at its very heart, albeit many so-called Kanban-boards are merely task-boards.

To really make use of this visualization we need to leverage spatial memory and counter confirmation bias.

Why spatial memory?

If the great benefit of (Task-)boards is, that they make work tangible and agile only makes problems visible, then it is important, that we help our brain to make use of this information. With a visible board, it is plausible that the amount of information displayed is still manageable. With electronic boards on the other hand: not so much.

Physical work (what David Allen –of getting-things-done fame– calls "cranking widgets") takes up a defined amount of space and most of the time also a defined location. So, for example, when working on some home-made stuff, during sanding it is easy to remember that “the blocks on the left side of the table still need work, and those in the upper row need some special treatment because they felt ’strange’.“ In this case, ‘left-hand side’ would be associated with unfinished and ‘top row’ with special treatment needed.

Likewise, if we have a number of boards physically placed throughout the workspace, location gets mapped to meaning. After a while, we just ’know’ that we have to look at the board on the wall behind Jenny to see the current status of Portfolio initiatives. Or at the board in the hallway to see the state of affairs with regard to the committed user-related features.

One could argue that having electronic boards for the same information works almost the same, because with electronic boards we just ‘know’ that we have to go to «boards»->«companywide»->«MyDepartment»->«Initiatives» to find the portfolio information and we have to go to «boards»->«MyDepartment»->«Stories» to see the committed user-related features. But this draws on a different kind of memory, which is accessed a lot slower. And takes more energy to activate. At least that's one of the learnings I took away from Sharon Bowman’s “Training from the Back of the Room”.

Even our figures of speech are quite informative here. Getting a ‘picture or the situation’ or having the ‘big picture’ are good examples of this.

And glancing at the walls just takes somewhere between a fraction of a second and a couple of seconds, depending on how much information you want to absorb. It even happens without conscious effort. Just walking by the feature-board in the hallway and the portfolio-board behind Jenny's desk gives you a certain amount of situational awareness - whether you want it or not.

What about confirmation bias?

Unfortunately, even though one of the original ideas behind Agile approaches was to make problems visible most humans are influenced by confirmation bias. We tend to look for helpful clues to help us to confirm whether a course of action is feasible. In earlier times that was helpful – and it even is helpful today as Jeffry Levine explains convincingly on quora. We wouldn’t be able to act in the world if we didn’t apply filters to the huge amount of information that comes at us all the time. And re-thinking topics we already thought about would –most of the time– be a waste of the rare resource mental power.

One of the implications of this is that we –in general– don’t go out there and look for things that are not as expected. We probably won’t open the portfolio board every day to check whether the portfolio item that our current feature relates to just got flagged ‘canceled.’ And neither is it likely that all portfolio managers look at the detail boards all the time. But, in my personal experience, they develop quite a keen eye for an agglomeration of blockers on features if they pass that wall several times a day.

To help people tackle problems and issues they care about it does help to make this information visible. Especially in those cases where nobody would actively look for the unwelcome information.

It's called visual management for a reason

Even if Agile and the Kanban method have both somewhat evolved from their roots in Lean, the whole board idea is based on visual control and the enormous lever for self-management it provides.

So, if you use boards, make sure the important ones are visible all the time to the right people.

till next time
  Michael Mahlberg

The Anti-Pattern of Jira-(Mail)-Notifications

When you use Jira the way it was meant to be used – as a bug tracker with customer facing interfaces – it might be quite okay to use mail notifications. after all, in this scenario it is quite possible, if not even intended, that issues enter the system without any interaction from the people working with the system.

If you use Jira as a replacement for a physical (agile) board things are different.

One of my favorite tweets reads something like “Individuals and interactions over assigning someone a jira ticket without even talking to them.” This not-so-subtle reference to the first value-pair of the Manifesto for Agile Software Development summarizes nicely what’s wrong with many so-called(2) agile projects these days. There are other things as well –lots of them actually- but for now let’s track focus on this issue.

The original statement "[…we have come to value] Individuals and interactions over processes and tools“ puts a very strong focus on people and their interactions. And in the early agile projects I experienced (around the turn of the century) that was a big part of what it was about. Visualization (index cards pinned on boards) was mostly used to enable self organization and document thing that the people already had talked about. As a friend of mine pointed out much later, when asked about using a physical boards: “The intelligence congregates in front of the board.“

When working in an agile team (e.g. a team really using XP) and if that team decided to use a (physical) board, everyone sitting in the vicinity of the board notices when something the team is working on changes its status. Because each time something enters a new state –a state for which the members of the team themselves have decided that it is relevant for their work–, a person walks up to the board and moves a card. Whether or not that is of interest right now is everyones own decision. But –since the whole team sits together and works on a common goal, without several other project interfering from the side– it is very probable that people will come and have a look rather soon. Even though they would all be informed at the next standup anyway.

This approach is quite powerful, when the cards represent things the people who work with them actually know.

Appearance: Real Life Jira Notifications
“Jira mail notifications do exactly the same” - yes, sometimes they can... “and you don‘t even have to be in the same room” – yes, that is where the trouble starts (because for all Jira knows, you could be in several rooms at once) “and you can even have them for lots of projects” – yes, and this is where it really starts to become a problem. (Because in real live we have those boards in different rooms and we only notice thing that happen where we are. When we get information for things that are not relevant for us now we tend to go numb for that input channel to avoid information overload.)

I saw many organizations where people configured their mail-program in such a way, that Jira notifications got sorted away without ever distracting them from important work. (There words, not mine. Seems to me like those notifications where not important for what they did most of the time.) For me this is the final indicator that the organization has started to value tools and processes over individuals and interactions. In an Environment where the board has the same importance that the physical boards had in the early days, it would probably be visible all the time and everything that happened on the board would be of at least some relevance to everyone in the team. Because –as mentioned earlier– they all work on the same goal. Of course that is not feasible for all environments, but then maybe other approaches would be more useful. But that would be another story.

If you try to work in an agile manner and think you need Jira mail notifications something might be wrong. If you work in a lean manner things might be slightly different but only to a point. And once you “need” mail rules and filters to manage your jira mail notifications, something definitely is wrong from a lean and agile point of view.

Give switching of those notifications a try – after all, you can always look at the board to find out what’s up - can’t you? (If you can’t you've got yet another problem)
Try to find out what you loose if you switch them of altogether and devise ways to address those needs. (Mail-Notifiations might be helpful in a distributed setting, but then again an IP-connected Lava-Lamp might be helpful for more than just the build status...)

till next time
  Michael Mahlberg

What's wrong with collective code ownership?

The Consultant’s answer of course would be “it depends.”

For now I just would like to focus on one important issues: In today's world ‘code’ is something quite different from what ‘code’ was in the nineties where we had things like a smalltalk image in which all the code of the project resides. Today we have things like infrastructure as code, configurations that are in some cases more complex that the software itself, pipeline-code, glue-code and many more things that affect the usability and usefulness of the system under discussion.

Therefore I propose to extend the concept. Let’s move on. Or –from my point of view– let’s get back to the original idea.

IMHO today what’s needed is an interpretation of collective ownership that engulfs the whole system. Collective ownership in this idea is not so much the idea that anyone is allowed fiddle with any item of the system.

To me today's idea of collective ownership means that anyone is expected to make all the changes that are necessary to keep the integrity of the system as a whole after some change or addition. This especially includes involving potentially affected parties and is much more about everyone’s responsibility for the whole system. And in today’s reality there are only very few people who can change all the kinds of code. Therefore, form my point of view, shared ownership also includes the responsibility to collaborate.

till next time
  Michael Mahlberg