Scaling Agile with Set-Based Design

I wrote a while back about set-based design, and just recently about a way to frame scaling Agile as a mostly technical consideration. In this post I want to continue with those themes, combining them in a model for scaled agile for production and research.

Scale

In the previous post, we found that we can view scale as a function of the possibilities for functional decomposition, facilitated by a strong focus on communication through code (customer tests, developer tests, simple design, etc.)

This will result in a situation where we have different teams working on different feature-areas of a product. In many cases there will be multiple teams working within one feature area, which can again be facilitated through application of well known design principles, and shared code ownership.

None of this is very new, and can be put squarely in the corner of the Feature Team way of working. It’s distinguished mainly by a strong focus on communication at the technical level, and using all the tools we have available for that this can scale quite well.

set_based_design_image_1

Innovation

The whole thing starts getting interesting when we combine this sort of set-up with the ideas from set-based thinking to allow multiple teams to provide separate implementations of a given feature that we’d like to have. One could be working on a minimum viable version of the feature, ensuring we have a version that we can get in production as quickly as possible. Another team could be working on another version, that provides many more advantages but also has more risk due to unknown technologies, necessary outside contact, etc.

set_based_design_image_2

This parallel view on distributing risk and innovation has many advantages over a more serial approach. It allows for an optimal use of a large development organization, with high priority items not just picked up first, but with multiple paths being worked on simultaneously to limit risk and optimize value delivered.

Again, though, this is only possible if the technical design of the system allows it. To effectively work like this we need loosely coupled systems, and agreed upon APIs. We need feature toggles. We need easy, automated deployment to test the different options separately.

Pushing Innovation Down

But even with all this, we still have an obvious bottleneck in communication between the business and the development teams. We are also limiting the potential contributors to innovation by the top-down structure of product owner filling a product backlog.

Even most agile projects have a fairly linear look on features and priorities. Working from a story map is a good first step in getting away from that. But to really start reaping the benefits of your organisation’s capacity for innovation, one has to take a step back and let go of some control.

The way to do that is by making very clear what the goals for the organisation are, and for larger organisations what the goals for the product/project are. Make those goals measurable, and find a way to measure frequently. Then we can get to the situation below, where teams define their own features, work on them, and verify themselves whether those features indeed support the stated goals. (see also ‘Actionable Metrics at Organisational Scale‘, and ‘On Effect Mapping and Pirate Metrics‘)

set_based_design_image_3This requires, on top of all the technical supporting practices already mentioned, that the knowledge of the business and the contact with the user/customer is embedded within the team. For larger audiences, validation of the hypothesis (that this particular, minimum viable, feature indeed serves the stated goals), will need to be A/B tested. That requires a yet more advanced infrastructural setup.

All this ties together into the type of network organisations that we’ve discussed before. And this requires a lot of technical and business discipline. No one ever said it was going to be easy.

The ‘Just Do It’ Approach To Change Management

Last Friday I gave a talk at the Dare 2013 conference in Antwerp. The talk was about the experiences I and my colleague Ciarán ÓNeíll have had in a recent project, in which we found that sometimes a very directive, Just Do It approach will actually be the best way to get people in an agile mindset.

Update: The full video of this talk as given on ‘Agile on the Beach’ is available on youtube.

This was surprising to us, to say the least, and so we’ve tried to find some theory supporting our experiences. And though theory is not the focus of this story, it helps if we set the scene by referencing two bits of theory that we think fits our experience.

Just Do It

A long time ago, in a country far away, there was this psychologist called William James, who wrote:

“If you want a quality, act as if you already have it.” – William James (1842-1910)

We often say that if you want to change your behaviour, you need to change your mind, be disciplined, etc. But this principle tells us that it works the other way around as well: if you change your behaviour this can change your thinking. Or mindset, perhaps?

For more about the ‘As If’ Principle, see the book by Richard Wiseman

Another piece of theory that is related is complexity thinking as embodied by the Cynefin framework. Cynefin talks about taking different actions when managing situations that are in different domains: simple, complicated, complex or chaos.

Cynefin Framework

The project

And in chaos, our story begins.

This particular project was a development project for a large insurance company. The project had already been active for over half a year when we joined. It was a bad case of waterfall, with unclear requirements, lots of silo’s, lots of finger pointing and no progress.

The customer got tired of this, and got in a high-powered project manager who was given far reaching mandate to get the project going. (ie. no guarantees, just get *something* done) This guy decided that he’d heard good things about this ‘Agile’ thing, and that it might be appropriate here as a risk-management tool. Which was where we came in.

And this wasn’t the usual agile transition, with its mix of proponents and reluctants, where you coach and teach, but also have to sell the process to large extend.

Here, everyone was external (to the customer), no-one wanted Agile, or had much experience with it, but the customer was demanding it! And taking full responsibility for delivery, switching the project to a time-and-material basis for the external parties.

A whole new ballgame.

Initial actions

We started out by getting everyone involved local. Up to then, people from four different vendors been in different locations, in different countries even. Roughly 60 people in all, we all worked from the office in Amsterdam. Most of these people had never met or even spoken!

We started with implementing a fairly standard Scrum process.

Step one was requiring multi-functional teams, mixing the vendors. This was tolerated. Mostly, I think, because people thought they could ignore it. Then we explained the other requirements. One week sprints, small stories (<2 / 3 days), grooming, planning, demo, retro. These things were all, in turn, declared completely impossible and certainly in our circumstances unworkable. But the customer demanded it, so they tried. And at the end of the first week, we had our first (weak) demo.

So, we started with basic Scrum. The difference was in the way this was sold to the teams. Or wasn’t.

That is not to say that we didn’t explain the reasons behind the way of working, or had discussions about its merit. It’s just that in the end, there was no option of not doing it.

And… It worked!

The big surprise to us was how well this worked. People adjusted quickly, got to work, and started delivering working software almost immediately. Every new practice we introduced, starting with testing within the sprint, met with some resistance, and within 4 to 6 weeks was considered normal.

After a while we noticed that our retrospectives changed from simply complaining about the process to open discussion about impediments and valuable input for improvements generated by our teams.

And that’s what we do all this for, right? The continuous improvement mindset? Scrum, after all, is supposed to surface the real problems.

Well. It sure did.

Automated testing

One of those problems was one which you will be familiar with. If you’ve been delivering software weekly for a while, testing manually won’t keep up. And so we got more and more quality issues.

We had been expecting this, and we had our answer ready. And since we’d had great success so far in our top-down approach, we didn’t hesitate much, and we started asking for automated testing.

Adoption

Resistance here was very high. Much more so than for other changes. Impossible! But we’d heard all those arguments before, and why would this situation be any different? We set down the rules: every story is tested, tests are automated, all this happens within the sprint.

the-princess-bride-inconceivable

And sure enough, after a couple of sprints, we started seeing automated tests in the sprint, and a hit in velocity recovered to almost the level we had had before.

See. It’s Simple! Just F-ing Do It!

Limitations

Then after another 3-4 sprints, it all fell apart.

Tests were failing frequently, were only built against the UI, had lots of technical shortcomings. And tests were built within the team, but still in isolation: a ‘test automation’ person built them, and even those were decidedly unconvinced they were doing the right thing.

In the end, it took us another 6 months to dig our way out of this hole. This took much coaching, getting extra expertise in, pairing, teaching. Only then did we arrive at the stop-the-line mindset about our tests that we needed.

Even with all of that going on, though we were actually delivering working software.

And we were doing that, much quicker than expected. After the initial delays in the project, the customer hadn’t expected to start using the system until… well, about now, I think. But instead we had a (very) minimal, but viable product in time for calculating the 2012 year-end figures. And while we were at it, since we could roll-out new environments at a whim (well… almost:-) due to our efforts in the area of Continuous Delivery, we could also do a re-calculation of the 2011 figures.

These new calculations enabled the company to free a lot of money, so business wise there’s no doubt this was the right thing to do.

But it also meant that, suddenly, we were in production, and we weren’t really prepared to deliver support for that. Well, we really weren’t prepared!

Kanban

And that brings us to one of the most invasive changes we did during the project. After about 5 months, we moved away from Scrum and switched to Kanban.

Just Do It

At that time I was the scrum master of one of the teams, the one doing all the operations work. And our changes in priority were coming very fast, with many requests for support of production. In our retros, the team were stating that they were at the same time feeling that nothing was getting done (our velocity was 0), and they felt stressed (overtime was happening). Not a good combination. This went on for a few sprints, and then we declared Kanban.

That’s not the way one usually introduces Kanban. Which is carefully, evolutionary, keeping everyone involved, not changing the process but just visualising it. You guys know how that’s supposed to be done right?

This was more along the lines: “Hey, if you can’t keep priorities stable for a week, we can’t plan. So we won’t.”

Of course, we did a little more than that. We carefully looked at the type of issues we had, and the people available to work on them. We based some initial WIP limits on that, as well as a number of classes of service. And we put in some very basic explicit policies. No interruptions, except in case of expedite items. If we start something, we finish it. No breaking of WIP limits. And no days longer than 8 hours.

Adoption

That brought a lot of rest to the team. And immediately showed better production. It also made the work being done much more transparent for the PO.

It worked well enough, that another team that was also experiencing issues with the planning horizon also opted to ‘go Kanban’. Later the rest of the teams followed, including the PO team.

Limitations

That is not to say there was no resistance to this change. The Product Owners in particular felt uncomfortable with it for quite some time. The teams also raised issues. All that generated many of those nice incremental, evolutionary changes. And still does. The mindset of changing your process to improve things has really taken root.

The most remarkable thing, though, about all that initial resistance was the direction. It was all about moving back to the familiar safety of… Scrum!

Wrap-up

I’d like to tell you more but this post is getting long enough already. I don’t have time to talk about our adventures with going from many POs to one, introducing Specification by Example, moving to feature teams, or our kanban ready board.

I do feel I need to leave you with some comforting words, though. Because parts of this story go against the normal grain of Agile values.

Directive leadership, instead of Servant Leadership? Top-Down change, instead of bottom-up support? Certainly more of a dose of Theory X than I can normally stomach!

And to see all of that work, and work quite well, is a little disconcerting. Yes, Cynefin says that decisive action is appropriate in some domains, but not quite in the same way.

And overcoming the familiar ‘That won’t work in our situation’ resistance by making people try it is certainly satisfying, but we’ve also seen that fail quite disastrously where deep skills are required. That needs guidance: Still no silver bullets.

Enlightened Despotism is a perhaps dangerous tool. But what if it is the tool that instills the habits of Agile thinking? The tool that forcibly shakes people out of their old habits? That makes the despot obsolete?

Practice can lead to mindset. The trick is in where to guide closely, and when to let go.

Scaling Agile?

There’s a lot of discussion in the Agile community on the matter of scaling agile. Should we all adopt Dean Leffingwell’s Scaled Agile Framework? Do the Spotify tribe/squad thing? Or just roll our own? Or is Ron Jeffries’ intuition right, and do the terms scaling and agile simply not mix?

Ron’s stance seems to be that many of Agile’s principles simply don’t apply at scale. Or apply in the same way, so why act differently at scale? That might be true, but might also be a little too abstract to be of much use to most people running into questions when they start working with more than one team on a codebase.

Time and relative dimension in space

When Ron and Chet came around to our office last week, Chet mentioned that he was playing around with the analogy of coordination in time (as opposed to cross-team) when thinking about scaling. This immediately brought things into a new perspective for me, and I thought I’d share that here.

If we have a single team that will be working on a product/project for five years, how are they going to ensure that the team working on it now communicates what is important to the team that is working on it three, four or five years from now?

Now that is a question we can easily understand. We know what it takes to write software that is maintainable, changeable, self-documenting. We know how to write requirements that become executable, living documentation. We know how to write tests that run through continuous integration. We even know how to write deployment manifests that control the whole production environment to give us continuous deployment.

So why would this be any different when instead of one team working five years on the same product, we have five teams working for one year?

This break in this post is intentionally left blank to allow you to think that over.

Simple Design

scrum_tardis

Scrum really is bigger on the inside!

This way of looking at the problem simplifies the matter considerably, doesn’t it? I have found repeatedly that there are more technical problems in scaling (and agile adoption in general) than organizational ones. Of course, very often the technical problems are caused by the organizational ones, but putting them central to the question of scaling might actually help re-frame the discussions on a management level in a very positive way.

But getting back to the question: what would be the difference?

Let’s imagine a well constructed Agile project. We have an inception where the purpose of the product is clearly communicated by the customer/PO. We sketch a rough idea of architecture and features together. We make sure we understand enough of the most important features to split off a minimum viable version of it, perhaps using a story map. We start the first sprint with a walking skeleton of the product. We build up the product by starting with the minimal versions of a couple of features. We continue working on the different features later, extending them to more luxurious versions based on customer preference.

As long as the product is still fairly well contained, this would be exactly the same when we are with a few teams. We’d have come to a general agreement on design early on, and would talk when a larger change comes up. Continuous integration will take care of much of the lower level coordination, with our customer tests and unit testing providing context.

One area does become more explicit: dependencies. Where the single team would automatically handle dependencies in time by influencing prioritization, the multiple teams would need to have a commonly agreed (and preferably commonly built) interface in existence before they could be working on some features in parallel. This isn’t really different from the single-team version above, where the walking skeleton/minimal viable feature version would also happen before further work. But it would be felt as something needing some special attention, and cooperation between teams.

If we put these technical considerations central, that resolves a number of issues in scaling.  It could also allow for a much better risk / profit trade-offs by integrating this approach with a set-based approach to projects. But I’ll leave that for a future post.

Spikes, they’re sharp

One of the concepts that came from XP is the Spike. Especially in teams new to agile, there can be confusion on what a Spike is, and how to deal with them.

The best definition of a Spike I’ve found is this one:

“Spike” is an Extreme Programming term meaning “experiment”. We use the word because we think of a spike as a quick, almost brute-force experiment aimed at learning just one thing. Think of driving a big nail through a board.
— Extreme Programming Adventures in C# – Ron Jeffries

Let’s break this down.

Experiment

A Spike is an “… experiment aimed at learning just one thing”. That means that a Spike always starts with a question to be answered. An Hypothesis. At the end of the Spike there is an answer to that question. The hypothesis has been proved, or disproved. And that proof takes the form of a piece of software. A document does not prove anything.

Quick

A Spike is quick. A Spike is usually time-boxed, to as short a period of time we think is feasible to answer our question. That period of time should normally not exceed a day or so.

Brute-force

A Spike will not generate any production code. A spike can be a design session in code, just enough to prove that the design will work. It can be a technology investigation, just enough to see if that library will do the trick. All code from the Spike will be thrown away. It’s about learning, not production.

Rare

I know, that wasn’t in Ron’s definition. Just an additional remark. Spikes are rare. They occur only very infrequently. Once every couple of sprints sounds about right to me. That might decline with the age of the project, as Spikes are particularly useful to remove uncertainty on technical design early in a project.

Spike image

In practice

When an occasion comes up to introduce a Spike into a sprint, you do the following:

  1. Reconsider: Do you really need to investigate, or are you just scared to commit to an actual, value delivering, user story because you don’t know the system very well?
  2. Reconsider again: Do you really need to investigate, or are you just scared to work together with the rest of the team without someone handing you a detailed specification?
  3. Define the question: ‘grooming’ a Spike means that you clearly and unambiguously define the hypothesis that you need to have answered by the spike. This is like the Spike’s Acceptance Criteria. That means clearly defined, and preferably having a boolean (yes / no) answer. Agree what further actions will result from a ‘yes’. And from a ‘no’.
  4. Define the time-box: To answer this question, what size investment are we prepared to do? Keep it short. A day is long. Sometimes long is needed. Sometimes.
  5. Prioritize: The Spike is on your backlog. You prioritize your backlog.
  6. Execute: Code to find your answer. Stop as soon as you have it. Stop if the time-box expires.
  7. Deal with the result: That’s the action agreed upon earlier. A timed-out Spike also is an answer to that question (‘too expensive to find out’), and also has an agreed upon action.

Have you done a Spike recently? How did that turn out? Did you get your answer? Or a time-out?

Not Estimating At Scale

Estimation is a sensitive subject in Agile. Should we estimate? Do we avoid estimation in days or other time-based units? If we use relative estimation like story points, do we standardize across teams? What do we use estimation for? Are we explicit enough in emphasizing the distinction between estimations and commitments? How do we prevent abuse?

I’m not going to provide an answer to these questions.

If you want to get a good treatment on estimation with regards to agile, I suggest you read Ron Jeffries’ excellent articles in the Pragmatic Programmer’s magazine: Estimation is Evil: Overcoming the Estimation Obsession, and Estimation: The Best We Can Do

I’m just going to describe a fairly simple and effective way to not (well, kind of not) estimate with multiple teams. This is based on a recent experiment doing this exercise in a running project.

Not Estimating

In this project we had not been estimating at all, up until this point, which was 9 months into the project. And when I say we did not estimate, then of course I’m lying. But we did not do estimation of individual user stories (or larger items, Epics, Features, whatever you want to call them).

We started this project introducing Scrum, and going into one-week sprints. None of the participants were used to working in an iterative way. And the requirements for the project were completely unclear. So even if we wanted to do estimations, there was very little to estimate! We decided to forgo estimation, and simply asked the teams to split the user stories into small enough slices that a story could be finished in two to three days.

Of course, that means that there was estimation involved. Otherwise they couldn’t know whether the story was small enough. So I wasn’t lying about the lying. But the effort was limited, and only done for stories that were being groomed for the next sprint(s).

Delivery after nine months?

Fast forwarding nine months into this project, we were in a somewhat different state. For one, we were no longer doing Scrum, but have moved to a Kanban approach. We have a two-step Kanban configuration. Stories are prepared through a READY board, of which the process steps’ Explicit Policies reflect the Definition of Ready we had as a Scrum team. One of the policies is the ‘takes less than 2 – 3 days to get Done’ rule. One of three development teams is involved in the grooming process of an individual story and usually (but not necessarily) picks up that story later by moving it to their Build Board.

At nine months, people traditionally get interested in the concept of delivery. Of course, our project was already delivered. Production figures had been produced. But the project was supposed to ramp down around the 12 month mark. That meant that there was interest in finding out what part of the features still on the wishlist could be delivered by that time. So that required some estimations.

What to estimate

At this point, there are a bunch of high level areas of interest that we are interested in. These haven’t been looked at or communicated with the teams yet, and haven’t been prioritized. In fact, one of the main reasons we need the estimations is to help with prioritization. We do not want to spend a lot of time on estimating these things. We should focus on actually delivering software, not talking about things we might never work on.

We also don’t want to give the impression that the estimations that we will come up with are very accurate. A good estimation makes the uncertainty of the estimation explicit. We decide that we’ll be estimating the incoming feature requests in ‘T-Shirt sizes’, each categorized by a certain bandwidth of the number of stories expected to be necessary to implement the feature:

T-Shirt Sizes

  • Small: 1 – 5 Stories
  • Medium: 6-10 Stories
  • Large: 11-15 Stories
  • Parked: Not clear enough to size, or simply too large: requires splitting and clarifying

To make sure we wouldn’t spend a lot of time in detailed discussion, we decided to use Silent Grouping as the method of estimation. To make it work across our teams, we added a little diverge and merge to the mix.

Estimation process

We arranged for a number of sessions, each 90 minutes long. Each session would be dedicated to one main functional area. The Product Owner (or in this case the functional area PO helper) would introduce the functional area, explain the overall goals, and run through the features that had been identified in that area. This introduction would be half an hour, and would allow the teams to ask any questions that came up on the subject discussed.

Then we split into four different corners of our room, each attracting 8-10 people, and performed the silent grouping exercise there. This simply meant that everyone that showed up got a feature token (in this case simply the title of the feature printed on a piece of paper) and was invited to put it onto a board in one of four columns (the categories described above). Then people were allowed to change the position of any paper if they didn’t agree with its placement. And all of this happened in complete (well, we tried…) silence.

After a few minutes, things stopped moving, and we then went for the ‘merge’: on a central board, we called out each feature title, and based on the placement on the four separate boards determined the final position for the story. We did a few iterations of this, but our final set of rules seemed to work quite well:

  • Stories that have the same estimation on all boards, obviously go into that category on the main board
  • Stories that have two different, but adjacent, estimations go into the larger category
  • Stories that have three or more different estimations go into ‘parked’

We found that we regularly had some discussion on whether something was parked because of uncertainty, or size. But when we tried those out as separate categories, most turned out to be uncertain and the added value was limited.

Sizing Board Picture

Results

We had four 90 minutes sessions to estimate what turned out (of course:-) to be quite a bit more than 3 months of work. We found that quite a large part of the features ended up in ‘parked’, simply because they were not clear enough for the development teams to give even this kind of ball-park estimate. To get these features clearer, three amigo grooming sessions were set-up. This brought the number of parked features down considerably, and got us to a fair idea of the total amount of work. Since those sessions did not include the entire team, this did break our intent to have everyone involved in estimation, but we haven’t found a better way of doing this yet.

A second, and maybe even more important effect was that the whole team was instantly up to date on what we had planned for the next time period. A number of additional features and technical improvement were brought up during and after this session as people realized they might be needed, or would fit into the direction the project was going.

And the estimates gave the more distant business owners the required feedback to consider the priorities and decide what they could do without. For now.

Set-based design in software

Last year at the Lean and Kanban Benelux conference I attended a session by Michael KennedySet-Based Decision Making: Taming System Complexity. Watch that video, where he explains the way that Toyota uses set-based design to be innovative without risk to the schedules of their new product development projects. I thought that was a very interesting subject, and left thinking about some of the questions Kennedy posed on the applicability to software.

Michael Kennedy – Set-Based Decision Making: Taming System Complexity from Agileminds on Vimeo.

Skip forward half a year, and you find me having just read Product Development for the Lean Enterprise, Kennedy’s book that describes the advantages of Set-Based Design, but closely links this to the concept of a knowledge driven organisation. The book is in the form of fiction: a ‘Business Novel’, I think the term is. I’m not overly fond of that format, but must admit that it worked well in this case. For this post, I’ll focus on the treatment of set-based thinking. The book talks just as much or more about the knowledge driven organisation and forms of change management that are compatible with it, but that is material for another time.

What is set-based thinking?

Set-based concurrent engineering, as the book calls it, is distinct from concurrent engineering, where different parts of the product are built concurrently based on clear requirements and specified interfaces. The set-based approach doesn’t just create the separate parts of the product concurrently, it ensures that there are multiple options for the separate parts of the product, and combines those options at as late a stage as possible (responsible?) to form the product.

Why is that a good thing? Well, the book gives a great example of building a new bicycle. A bicycle has various components: a frame, a drive, brakes, suspension, wheel seats, etc. If you are free to combine those parts is various ways, you have many different options of building a bike. That also means that if you develop new versions of all those parts, there are high risks of failing with at least some of them. That means that there has to be a trade-off: innovation against the chance of success for a new product development project.

As you can see in the picture above, the set-based approach avoids this trade-off: by working on different options for each of the parts, the risk of one of the parts not delivering becomes less. If we combine that with an approach where a safe, known to work version of the part is included, then failure of the project becomes very unlikely. This allows you to take more risk, and thus invite more chance of innovation, for the alternative versions of that part.

This is (as is true for large parts of the Lean world, even if we call it ‘knowledge based’ instead of ‘lean’ product development) based on the way that Toyota works in product development. An example from them that Kennedy mentions in the talk above(just in case you haven’t watched that yet) is that of the Toyota Prius. There were a number of innovative components in that car: the hybrid engine, the transmission, etc. Toyota developed multiple versions of those components, where some would have been initially developed for earlier cars, but perhaps had not been included because the technology wasn’t quite ready. Toyota could take risks there, as it had backups for each of those parts from earlier car models. At the same time, the chassis of the car was not changed at all, and was simply the same as for an earlier Camry model.

Deciding which version of a part to use is done using something called Trade-off Curves. These graph the trade-off between various variables for a component’s design, such as fuel-economy and engine price, or for a bicycle road resistance vs. wheel stability vs. tire suspension. This is a very data-driven approach where the component are actually made, in multiple versions, incrementally improved, and tested against predefined criteria. It’s enough to warm my Test Driven heart!

There are some conditions to making this work, of course. This quickly goes into Kennedy’s ideas of the Knowledge Based Organisation, which I’ll leave for a future post. It suffices here to state that next to ‘Set-based Concurrent Engineering’, he has ‘System Designer Entrepreneurial Leadership’, ‘Responsibility based Planning & Control’ and ‘Expert Engineering Workforce’ as pillars of knowledge based engineering.

Software

But how would we approach such a process when we’re dealing with software? Is it even necessary? Software is soft, malleable, and easily changed (Your code is, right?) so maybe it’s not necessary to work in such a way? I actually think it’s not only necessary, but it’s already being done, and at quite a large scale.

Linux distributions

The best examples I can think of that use this type of process for software development come from the Open Source world. The first one that comes to mind is the way Linux distributions are managed. A distribution such as Ubuntu is comprised of many different components (packages). My laptop for example, has 4566 packages installed, and there are many more available. These packages are not all created by the same people. They have different requirements for dependencies, different features, perhaps different alignments with feature-sets of other packages. And different levels of stability.

The people who assemble Ubuntu then have choices to make: Do we use Evolution as a mail client, or Thunderbird? Which version of Thunderbird? Do we need to make adaptations of Thunderbird to work seamlessly with our other packages? And they do. Some of those changes can be big, risky, but bring significant innovation (“Drop Gnome as the desktop environment and use Unity instead”), some are smaller and can more easily be reverted (“Use Empathy instead of Gaim as chat client, with both using the same underlying libraries to support different protocols”). 

In a new release, most packages will be updated, but many changes are small, incremental and safe, while some are larger and bring more innovation. I doubt Mark Shuttleworth has a large set of trade-off curves on his desktop when the next version comes along, but he and the Ubuntu community are certainly making exactly those kind of trade-off choices.

Linux kernel

Another good example is again on the Linux front. The Linux kernel. This process may seem a little more complex, because it operates at a lower software level, but is in many aspects the same as above. In Linus, the kernel has its chief engineer (or ‘System Designer Entrepreneurial Leadership’). Calling the kernel developers an ‘Expert Engineering Workforce’ is also unlikely to trigger much discussion (though on the lkml, anything can trigger discussion). Though the kernel may seem less componentised than a distribution such as Ubuntu, it is in fact decoupled into many parts that can often be independently changed.

In the kernel, we again see set-based work in the way that separate components are sometimes incrementally developed, sometimes unchanged, and sometimes drastically changed or even replaced. Whether a change makes it into the kernel is the choice of Linus, but it is usually made based on discussion, numbers (“this filesystem structure has these performance characteristics, and such-and-such reliability” based on extensive testing of working code), and trust in team members. Only when a change is deemed safe and of high enough quality, it is pulled into the kernel. Then it is tested in integration with other changes before being handed to the outside world.

So we do already have set-based engineering in software. But how can you apply it to your own project, which might be large, or smaller? And what can be our software version of trade-off curves? Can we take advantage of the differences between hardware products and software to improve on this model.

All that in more in the next episode of… Soap!

On Discipline: Fooling yourself is an important skill!

Discipline is an interesting subject. One that I find myself regularly talking about. Or discussing about.derren brown mind control stunt

In the last year I lost about 20kg of body weight through a combination of diet change and exercise. This apparently give some people the impression that I am very disciplined. I’m not. I do know, however, how to make change easier to absorb. And how to inspect and adapt.

Fooling yourself is an important skill

The best ways to make sure you are able to keep discipline is to make being disciplined easy. And luckily, human beings are exceedingly good at fooling ourselves (click on the picture of Derren Brown, here, to watch a nice youtube clip demonstrating this).

For losing weight, this included:

  • Making sure that what I could eat was as least as nice to eat as what I had to stop eating (more meat, less potato chips)
  • Teaming up with my cousin to make not going to the gym not an option
  • Daily measurements of multiple metrics to get an understanding of progress, and variation
  • A very substantial reduction of insulin use, and improvement in blood sugar values with the corresponding increase in energy levels
  • Setting sensible targets that I adjusted as soon as I reached them.
  • Regular experiments to see what helped (drinking a lot of water), and what didn’t (too much exercise)

It’s just common sense. If you want change, make sure that what you’re changing to is enjoyable, and that your progress is clearly apparent. And a little peer pressure can also be useful.

Many of the practices promoted for agile processes fall in the same mould.

  • Short iterations give a clear sense of purpose for the short term, and a sense of accomplishment when completing them.
  • Visual progress, such as a scrum/task board give a direct view of progress, and the impression of things getting done (plus a little peer pressure…) when everyone on the team gets up and moves post-its a couple of times a day
  • Acceptance Test Driven development gives clear and achievable goals
  • Pair programming helps keeping focus throughout the day
  • Test Driven Development does the same, and again keeps progress visible
  • Retrospectives (and the resulting improvement experiments) give the sense of continuous improvement needed stimulate a positive feeling of support of the surrounding organisation

It might be slightly irreverent to throw all of these things together and talk about ‘fooling ourselves’. Is working in concordance with human needs ‘fooling yourself’? I don’t know, but I rather like the sound-byte:-)

On Effect Mapping and Pirate Metrics

During the Specification by Example training I talked about recently, Gojko Adzic introduced me to Effect Mapping. He’s writing a more extensive booklet on the subject, of which he’s released a beta here. I think this is an excellent tool for exploring goals, opportunities and possible features. It can be used as a tool to generate a backlog of features, as a way to explore possible business hyptheses, and perhaps even as a light-weight way to do strategic management of a company.

But let’s start with a short description (see Gojko’s site or beta booklet for the longer one) of what effect mapping is.

Effect Mapping basics

The basic structure of an effect map is that of a structured Mind-Map. A mind-map is a somewhat hierarchical way to note down ideas related to a central theme.

A Mind Map

A Mind Map

The effect map is a mind-map with a specific structure. The different levels of the mind-map are based around the answers to four questions:

  • Why? (The Goal)
  • Who? (Who can have a role in reaching that goal; Or preventing it)
  • How? (In what way can they help, business activities)
  • What? (What are the concrete software features to make; Or non-software actions to take)

Additional levels can be specific User Stories, tasks, or actions, but that depends more on how you want to organise your backlog. The important thing is that this provides an uninterrupted flow from high-level goal or vision to concrete work.

In this way, effect maps can provide one of the important missing steps in the Agile software development world: how to determine what features provide value supporting specific business goals.

The goal used in the centre of the effect map is supposed to be a measurable goal: we need to know unambiguously when this goal has been reached! Gojko gives a nice overview of the way this can be done, using a lighter-weight version of the way Tom Gilb prescribes for making goals measurable. This involves the scale (thing we’re measuring), meter (way we’ll measure it), benchmark (current state), constraint (minimum acceptable value, break even point), target (what we want it to be).

Effect mapping is not just about what ends up on the diagram, it’s also the process of generating the map. This is, of course, a collaborative approach. Getting the involved people together, and creating and discussing the goal, and the ways to get there. Important is that both business people with decision power as well as subject matter experts and technical people that can know possible solution directions should be present. And yes, they do have time for this. Using diverge and merge, as discussed in my previous post, can be very useful again. There’s more, but it’s not relevant to the rest of my post, about iterating, prioritising, etc. So just go and read the booklet, already.

Our Effect Map

In his booklet, Gojko also links this process to the Lean Startup process of customer development. I think this is a great combination, but I would like to see some tweaks in the type of measurements we use for goals in that case.

Actionable Metrics for Pirates

In his book The Lean Startup, Eric Ries talks extensively about the importance of Actionable Metrics, as opposed to Vanity MetricsAn actionable metric is one that ties specific and repeatable actions to observed results. A Vanity Metric is usually a more generic metric (such as total number of hits on a website, or total number of customers), that is not tied to specific (let alone repeatable) actions. There can be many reasons why those change, and isolating the reason is one part of making metrics actionable.

Dave McClure user the term ‘Pirate Metrics‘ to talk about the most important metrics he sees for organisations:Pirate Flag

A – Acquisition – User is directed to your site;

A – Activation – User signs up or is otherwise engaged;

R – Retention – User keeps coming back, i.e., is engaged over time;

R – Referral – User invites others;

R – Revenue – User pays or is otherwise monetized;

These are also the familiar ‘funnel’ metrics, and the above link to Ash Maurya’s site has much more background on them. When using these metrics, it is recommended to do Cohort testing, so that you can see the different results for different groups of users (again, see Ash Maurya’s site). Doing this such that the source of the (new) users is trackable allows you to identify the best ways of increasing the number of users, without deluding yourself into extrapolating from great growth figures if they’re the result of a single marketing action.

This is probably the only spot where Gojko’s booklet could use some tuning. The Gilbian metrics he uses for his example are functional metrics (SMART, and all that), but not the type of actionable metrics that would fit into the lean startup mold. In this example, we’re talking about reaching a certain number of player (one million), in a certain space of time (6 months), while keeping costs and retention rates to certain limits. Gojko does of course explain how to do this iteratively, taking a partial goal (less player than in the end-goal) and checking at a defined milestone whether the goal was reached. And because we’ve only done one ‘branch’ of the effect map, we do have a specific action to link to the result.

If we were to re-cast this more along the lines of our pirate metrics, we could rephrase the goal as increasing the Acquisition and Activation rates. To be clear: this is a whole other goal! This goal is about a change that will ensure structural growth in the longer term. The goal on 1M extra users could (perhaps) be reached by increasing marketing spending (note that only  operational costs are taken into account in the original example). In that case, the goal would be reached, but given that there is a typical Retention rate of (for example) 6 months, then there would be an equivocal exodus of users after that time. If the company had reacted based on total number of users, this could lead to incorrect actions such as hiring extra people, etc.

If the CEO comes down with the message ‘We want 1 million users!’, and it turns out he wants that in about 6 months time, we can then say, “Ok, that’s about 5500 new users per day, or
a growth rate of 1.6%” (per day, again). Then we can start creating and testing hypotheses in much smaller steps than those 6 or three months. What’s more, by using these metrics (and goals) it should become possible to use the same metrics further out into the effect map.

And if this is something at a larger scale, teams can take some of the higher level hypotheses / business activities and use their own domain knowledge to devise more experiments to find a way to reach those goals. Since churn is included in the figure, this also allows experiments based on increasing retention rates. And since we’re doing cohort testing on pirate metrics, we can know day-to-day and week-to-week whether what we’re doing has the expected results. This extends the set-based design paradigm used in effect mapping to a broader organisation.

Strategy and organisational structure

So by using effect mapping, we can make the relation between high-level goals, stakeholders and intermediate level goals visible, using a collaborative process involving different parts and levels of the organisation. By using a consistent set of (value / end-result focused) metrics that can be applied in both the short and longer term, throughout the organisation, we can enable all levels of the organisation to apply their knowledge and skills to reach those goals. And thus allows for more self-organisation (and experimentation) at all levels…

I recently came across the system of Hoshin Kanri (via Bob Marshall). This has some remarkable similarities to what I’ve been talking about. It’s also a method to ensure policy/goals can be distributed throughout the organisation, with involvement of multiple levels and stakeholders at each step. I’ve not studied it extensively, but to me it does feel like a strictly hierarchical system, and one that is mostly used in large companies with a fairly slow (yearly and half-yearly) cycle time. It is used by Toyota, and is part of Total Quality Control, which is supposed to be “designed to use the collective thinking power of all employees to make their organization the best in its field.” It’s nice to see that everything has already been thought of, and we’re just repeating the progress of the past:-)

The difference with effect mapping is its light-weight focus, and the ease with which effect mapping can more easily be used in less hierarchical organisations. In fact, I think such a system might well be a prerequisite to the type of organisations we’re talking about in light of the Stoos network: “learning networks of individuals creating value”. My recent proposal for a session at the Stoos Stampede was precisely about finding out how we can link an organisation’s vision/mission to goals specific enough that teams can work towards them independently, but open enough that they would not suffocate and entrap those teams. I think this might be one solution to that problem.

Stoos Stampede

Management Innovation, ca. 1972

SilosYesterday, after my brother’s 47th birthday, I was talking with my father. My father is 79, and he has had an interesting professional life. He started out as a catholic priest but, as you could guess from the fact of my existence, at some point figured out that this was not a sustainable career path for him.

While talking, my father touched upon the subject of work, and the importance of working for the right reasons. He discussed people that had found a work/life balance that worked for them, by not focusing on financial rewards, but on the contents of the work, and the need to spend time on their families. Of course he sees that many people, including himself at one point, have manoeuvred themselves in positions where making those choices has become very difficult, if not impossible. Certainly many people now are in positions where two full-time salaries are needed to be able to keep paying the mortgage. But focusing on intrinsic motivation for work is very important for your enjoyment of work, and life.

We also talked about management a bit. In 1972, also the year of my own vintage, my father became director of the social services department (‘Sociale Zaken’) of the city of Haarlem. This organisation of around 250 people was then organised in strict silos, where social workers, legal people, administrative work and other departments worked separately, and with little understanding of each other’s specific challenges. Clients (people who were waiting to hear whether they would be getting social support, usually) regularly had to wait until each of those departments had had their say, often adding up to a 4 month wait before their application was either approved or denied. Meanwhile social workers were reporting their conclusions to those client back in language that  was very hard to understand. All of this resulted in very unhappy clients. And thus for the people that had the direct contact with those client not always being treated in the kindest ways.

My father apparently discussed the use of understandable language extensively with the social workers, at one point demonstrating the problem of jargon by slipping back into some latin phrases

Quidquid recipitur ad modum recipientis recipitur – “Whatever is received is received according to the mode of the receiver.”

I have, having failed spectacularly at the one year of Latin I had in school, no idea if this was the actual phrase he used. But it does seem apt.

He also instigated a reorganisation of the service. The reorganisation moved from the siloed system to one where different geographical parts of the city were going to be services by multi-functional teams, consisting of social workers, legal experts, administrative workers and directly client-facing people. The goal was to reduce time wasted with hand-overs, breed understanding for people with another area of expertise, and create more understanding for the clients predicaments.

This move was not welcomed by the employees. So much so that unions were involved, strikes threatened, and silo walls reinforced. In the end, it happened anyway. The arguments were solid, and even with unions involved, there was a rather clear power structure in place. And eventually, when the dust had settled down, the results were very positive indeed. Client satisfaction was up and response times were down (I think it went from roughly 4 months to two weeks). But just as important, internal strife was removed to a large extend, employees were picking up skills (and work!) outside of their area of expertise, and employee satisfaction was considerably better.

Now for me, this is not surprising. It’s not surprising because I know and have lived the results of similar ways of working in Agile teams.

Or maybe I’ve been doing that because, in the end, some values are instilled at an early age, and I had a great example.

Turning it up to 11

Turning It Up To 11It’s odd how I’ve been unable to be very consistent in my subject-matter for this blog. I tend to hop around, going from very technical subject to very organisational ones. Some might see this as lacking focus. Maybe that’s true. I’ve never been able to separate execution from organisation and vision very well. To me they seem intrinsically linked. It’s comforting to me that even such luminaries as Kent Beck also seem to see things in this light.

If I look at my bifurcated (tri-? n-?) interests, I see a striking resemblance in the states of technological, managerial and commercial maturity in the world. In all of these areas, the state of affairs is abysmal. In all three areas, we seem to have recognised that this is the case. In all three, though, most people performing those roles are so used to the current state that only rarely do they see that a different approach could bring improvement. Could turn their work ‘up to 11’. There are some differences, though.

Technology

On the technology side, we’ve pretty much identified what works, and what doesn’t. Basically, XP got things right. Others before that also hit the right spot, but we know a mature team sticking to XP practices will not mess things up beyond salvation. If we compare that approach to what one finds in the run-of-the-mill waterfall situation, the differences are so great that there is truly no comparison. There are other questions still at least partially open, but most of those are concerned with scale, organisation, and finding out what should be built. And thus belong in the other categories. The main challenge is one of education. And, granted, a bit of proselytising.

Commercial

More commercial questions are less clear-cut, at least for me. In my work I’ve very rarely seen commercial, product development and marketing decisions taken with anything resembling a structured approach of any kind of rigour. A business case, if one is available at al is often only superficial, and almost never comes with any defined metrics and decision moments. The Lean Start-up movement is the only place I’ve seen that is trying to improve that. Taking this approach out of the start-up and into all the product development and marketing departments in the world is going to take a while, but it will happen. If only because companies capable of doing that will completely out-perform the ones that don’t.

I don’t think the case here is as clear cut as on the technology side, but we have a start. The principles of the Lean Start-up are based on the same ideas as Agile development: know what you want the result to be (validated learning) and iterate using short feedback loops. What to do, exactly, in those feedback loops is known for some types of learning, in some situations, but we’re still working on expanding our knowledge and skills in this area.

Management

As the solutions for the commercial and technical sides of things are rooted in experimentation and short feedback cycles, one might assume that the same would be true for the management side of things. And it’s true that those techniques have value in management in many situations. Many of the ideas on management are based on feedback cycles, Lean/Deming’s PDCA is one, for instance, but Cynefin‘s way of dealing with systems in the complex area is another. But we do seem to have many different ideas about how management should be done, how organisations should be structured and what gives people the best environment to work in.

One place where some of these ideas have gotten together is the Stoos Network. It’s interesting because of the different backgrounds of the people involved: Agile, Beyond Budgeting, Radical Management, Industry Leaders. Their initial gettogether this year resulted in a shared vision, with again an emphasis on learning.

“Organizations can become learning networks of individuals creating value, and the role of leaders should include the stewardship of the living rather than the management of the machine.” — Stoos Communique

This clearly expresses some of the shared values of the Stoos people, but still leaves quite a lot to the imagination. The people and ideas involved are interesting enough that I’ve volunteered to help organise one of the follow-up meetings,  the ‘Stoos Stampede’, which takes place in Amsterdam, 6 and 7 July.

Next to Stoos, as I said before, there are many ideas on how to change management. Lean has had an impact, but though the Toyota Way certainly does talk about people and how to support them in an organisation, this is not the prime focus of most Lean implementations. CALM has started talking about combining Complexity, Agile and Lean ideas, but so far has also not posted any results.  We’re still a bit lost at sea, here.

So what would we need from a new management philosophy?

  • We’d need to know how to structure an organisation. Stoos clearly think the current semi-hierarchical default is not workable for the future, or at the very least severely suboptimal. But what do ‘learning networks’ look like? And how do we grow them?
  • We’d need to know how to provide the organisation with a purpose. A Mission, a Vision, a Goal. Whatever you want to call it. Most organisations do have some sort of mission statement, but it is usually so far removed from the everyday practice of everyone working within the organisation that it might as well be absent.
  • We’d need to know how to connect that purpose to the rest of the organisation. How do we link the work of everyone in the organisation to its stated purpose? If the mission is specific this should be possible. But if we connect the work too tightly, it could be stifling.
  • We’d need to know how to connect the organisation with its customers, its suppliers, its partners. This would be different out of necessity, as the structure of the organisation itself is different. It would also be different out of philosophy, as those relations take on different meaning is the goals of the organisation outside of the monetary rise in importance.
  • We’d need to know how to align such organisations with the demands of the outside marketplace and governance. If the organisation is more oriented towards longer term viability and purposeful behaviour, this might have a good long term effect on profitability, but will certainly in the short term have a different financial behaviour. And budgeting and bookkeeping are areas that need very specific attention with an eye on the external rules these subjects need to comply with.

But apart from what new management would do to the idea of an organisation, there are also questions related more to the question of how to get there from here. Why would current managers want to change their organisations? Why would they want to change so drastically? There are plenty of reasons, but would they be convincing to the current CxO? What would they need to learn to be able to execute on such a vision? Will everyone enjoy working in these kinds of more empowering organisations, or will some people prefer something more hierarchical?

All of these things I want to know. Some of them we’ll discuss during the Stoos Stampede (propose a subject to discuss!), but personally I think we’re still at the very earliest stages of this particular change. In the mean time, we do have a few good examples, and some patterns that seem to work, and I’m going to try and get a few more organisations turned up to 11.