How we agile - principle-led & context-dependent

· August 15, 2019

Agile is soon (?) to be forgotten and ditched like yesterdays clothes if you ask some agilistas that I follow. I think the reason is that we have watered down the meaning of the concept by applying the name to more and more un-agile things. Soon we will be able to become agile without letting its ideas and principles changing a thing about what we do or how we act. Because agile is just some simple, yet powerful, ideas - originally described in the Agile Manifesto.

I yesterday posted the following at twitter:

And on LinkedIn I got even cockier and added

Yes that is “scaled” (whatever that is) hashtag#agile working and helpful, without any specific framework or tool. Just guided by hashtag#principles towards ever better versions of our practices. Thinking for yourself - it’s a good train. Get on it!

Some people asked me to write a blog post about “it” as in “What you have done there”. I wanted to do that but from the perspective of the principles. Because I don’t think anyone should copy what we have done - but I’d love if more people understood the principles we built it on and used that as inspiration to make something better for them.

I’m a bit worried to write this though. Because I’m worried someone will copy these practices.

Don’t do this! It will not work (as) well for you as for us.

Do, however, see beyond our practices and to our principles and see why we did what we did. And then try to apply that principle in your world.

Here I list a few of the principles that we have used to help us find better practices. For each of these principles, I will list what it’s about, what and how we have gone about finding our principles, but more importantly why we have done this.

Before we start

I will repeat this in the document:

Don’t do this! It will not work (as) well for you as for us.

Do, however, see beyond our practices and to our principles and see why we did what we did. And then try to apply that principle in your world.

So with a hesitant hand: let’s go through some of our principles

Visualization and transparency

This big board is a really good example of the principle of transparency and the practice of visualization.

Our board

Visualizing is awesome because it takes information that previously was not visible and makes it apparent (and hopefully understandable) for everyone. This is in turn foster a culture of transparency and we can spread knowledge and get input from more people than just a few that the information in their head.

What / How

So we have created this big board. It’s my first ever vertical kanban board and very simply each column matches a team. The teams are responsible for products or a value stream (for example Partner Portal or Internal administration systems). I’ll get back to that structure later in the post.

Each column contains the following information (from top):

  • Name and definition. Each column/team has a name and a purpose that is given by the company leadership. Kinda: “We would love for you to improve the way we interact with our partners. Please”
  • Effects and KPI the next row describes the effect (impact or outcome) that the team is here to create. The team themselves have come up with KPIs that describes these effects. For example: “Ok - if we’re gonna improve the way we interact with partners then we think Number of active partners/day and Total Sales over the partner portal are good indications”
  • Just delivered - here we keep the things we just delivered, until the next weekly meeting. Oh, btw - delivered means “used by users in production”
  • Now - this row indicates the things that our teams are working with right now. For each of these “value deliverables,” we strive to make a good connection to how the effects we are here to deliver. It also means that (sub-)activities that we need to do to deliver value are not reported here. Because they, individually, doesn’t create value. This is how we keep the correct level of details.
  • Next - these are the value deliverables that the teams want to do next. But honestly this is just the best guess, most commonly new thing pops up that trumps this list.

Since this is a vertical board per team, value bubbles up from the ideas in Next to support the Effects and KPIs. I kinda like that visual representation.

We have many other visualizations going on there but you’ll have to squint and use binoculars to see it.

Why

Now that I’ve described how our board looks now (yes we change it a lot - even from the picture I took yesterday there are changes made to the structure :)) - but that is not that interesting. What is interesting is why we did this.

We wanted to create transparency across the entire company about what was being built and worked on in each team. And we wanted this to be both interesting and relevant to anyone in the company.

Hence we focused our efforts (and visualization) on value and effect rather than the activities and progress.

If you are working in the reception or part of the sales organization, which is more interesting to you, do you think:

Last week we finished 12 user stories of size S and we have 3 medium-sized soon to be released. Our average is 10 so we are pretty happy.

or

As you remember, last week we had a dip in the number of partners/day trend, but we addressed that through deliverable A and B. That will be released today and then we should see an increase not only for the number of partners but also for the sales.

(A and B are placeholder names because I ran out of imagination… Sue me!)

The latter creates a much better understanding of what the effect is of the activities. Also - it doesn’t require everyone to understand the details of what and how we are building.

Furthermore, the effects the teams are here to create should make sense throughout the company or we might have the wrong goal.

Continuous feedback and improvements

That board is nice (arguably…) and everything but we need to use it for it to be valuable.

The way that we do this is quite simple to meet around the board frequently and discuss how to best progress to better deliver the effects that we are seeking.

What / How

Yes - we meet weekly. For 15 + 15 minutes. The entire company is invited.

The first 15 minutes we spend going through each of the teams where they report the changes since last time and gives a little glimpse of what will happen next.

The latter 15 minutes are open questions and opportunity for people to stay around and go deeper into specifics and details for questions of their interest.

Why

Anything agile run on feedback. That’s pretty much what we are after and why agile does things differently (smaller things, faster deployment, shorter iterations, standups, etc. etc.); get feedback faster - and act upon it to make your situation better.

For us, that means that running a weekly meeting where everyone (that are interested) in the company gets to know what is happening and how we are progressing to reach our goal.

In the second part of the meeting, we can quickly and frequently resolve any synchronization issues, dependencies that slow us down or hinders of different sorts. Did you squint and saw the pink note on top of one of the tickets? That’s a blocker that helps us to know what is blocking something from completion.

Autonomous teams

We think that the best way of making amazing things happen is to let a group of motivated, skilled people pursue a goal. Then step out of their way and support them as needed.

This is why we have created autonomous teams that can govern themselves and quickly make decisions, change their minds and find better ways to improve their value stream/product/systems to reach the effect.

We wanted them to be autonomous - not isolated mind you

What / How

The real challenge in forming the teams was to find good areas to form around. But that means that we need to find “things” that are possible to take ownership and responsibility for. That has proved a bit tricky.

In part, this is because the rest of the organization is not formed around value streams, but rather around functions like Sales, Finance or Customer Support. And another, equally big problem is that our systems are built, over many years, to support the functions and not the flow of value.

But where possible we have created teams that have an area, a couple of discrete systems or a value that they can govern.

Why

We wanted the teams to be as autonomous as possible, which for starters means that we want the people needed to make decisions in the team. Therefore there are business people (what are the IT-people, btw? Not-business? Ah, I’ll leave that to another blog post) in each team.

Where we succeed with this we see fast-moving teams that continuously make changes in their plans to reach the effects and values. We also notice a great understanding across the chasm between IT and business; where the sales representative is speaking passionately about the need for technical debt clean up and the developer has deep understanding in the inner workings of our most complicated financial instruments sales stats.

Another reason for this focus on autonomous teams is actually to start to challenge and start to break up the current system architecture. Yes - we change the architecture from what it is today towards a world that better supports how we want to work. It’s well beyond the scope of this all-too long blog post to describe this idea fully but check out Conway’s Law and the inverse Conway maneuver

I’m convinced that a big part of the problem of making teams (in any organization) autonomous has to do with our obsession with reusing software. Is it a good idea that we have only one customer definition that everyone is using? I just hear “a single dependency that everyone needs to access/change all the time”. That does not support creating a fast-moving autonomous world to me.

Focus on value

One of the fundamental shifts that an agile brings about is the shift from projects (focus on activities, followed up on staying within plan/budget) to products (focus on effect and value, measured and followed up on the value created).

This has far-reaching implications of as disperse topics as budgeting, time reporting, and organization.

But we strive to do that anyway… because we think it’s dangerous that people are working on something that they don’t know the value of. More about that under the Why-heading

What / How

For the most part, we try to accomplish this shift in focus by having each team responsible for an effect rather than the delivery of activities.

This means that we want the effects/KPI on each team to reflect the value that we are here to create, rather than reporting how much we have worked. What if we do awesome work that no one ends up using? How much value was created then?

This also gives us a good starting framing-answer for the question:

How much details should go on to the “big” board and what should be on the team boards?

The answer is “Show the things that will render value/effects when users are using it.”

Interesting enough we often get requests to do activities, rather than to achieve effects. Add a new field in report X or Ensure we follow GDPR in system Y and not We need to be able to make decisions faster or We need to be GDPR compliant to a reasonable cost.

But the great hack to solve that is to ask Why? or even Why now?. Why do we need a new field in this report? It might take a couple of Whys but pretty soon we will arrive at the value/change/effect that we are after. If we didn’t do this now - how would we see that problem in our world?

Once the Why question has a good answer we can be even more advanced and ask How much? to understand even better what kind of change we are after, and also how to track it.

Why

If we want a team to be autonomous everyone in the team must understand why we are here and why we are doing what we are doing.

With that in place, we can allow the team to make their own decisions on how to best reach that effect. Without that understanding in place, we are creating marionettes that are just here to translate our thinking into code or actions. And they will do that badly since there’s a high degree of misunderstanding.

Software development (if were gonna limit ourselves to that area now) is knowledge work. Most of the things we do has never been done before. Here. Now. In our context. By us.

We need to help people discover what actions and deliverables best will serve us. In the words of Woody Zuill

It is in doing the work we discover the work we need to do

A really good thought experiment, although a little provocative, that we have used to illustrate this is: let’s say that a team has 12 value deliverables line up for delivering the next couple of months. They are all good and well-described as how the support the effect. Then, suddenly, in the meet weekly meeting, the team clears out the entire list of items and replace it with 2 new ones. They proudly declare: we found that these two would better give us the effect we are after. We will not do the 12 we said last week - but rather these 2 instead.

What should the appropriate reaction be?

Exactly - applauds, fireworks, and champagne! They have a decision they think is better, based on being closest to the information and context (system, etc). And we do not track success based on delivery of activities but reaching the value/effect we are here to create. Well done, team!

This is what the focus on value over, focusing on activities means in practices. This is also what an autonomous team is here to do - that is what autonomous mean: govern themselves.

Foster a psychologically safe environment

Fear is here (as in: in our world today). It shows its ugly face in so many ways that I lost count; screaming in a meeting, the odd bad comment in the corridor, a joke that wasn’t really meant to be funny, giving people deadlines without any way of taking ownership of the scope, etc. etc. And sadly etc.

Here’s the thing do; if we want people to discover what works best, or find a good solution or even develop code - we need to allow for mistakes. It’s bound to happen. Hey - some people argue it’s the best way to learn.

I read that Microsoft is aiming for 70% “failure” rate of their experiments in product design. That is; not giving the result that we thought we would get. And I heard that Google has 8-10 failed product for every successful one.

Also - think about any substantial innovation and research it. I doubt that you will find a single example of someone doing the right thing from start to finish. We are here to learn.

Modern Agile says it beautifully

Frame the problem as a learning problem - not an execution problem

What / How

We are constantly challenging our teams to try to do this, but this is really a big change since we’re coming from a situation where “the business” has requested/ordered things from “the development department”.

I still remember the first time I heard a product owner realize that

I’m gonna stand there and say that we are not doing great (if that happens). And I am gonna say that something is late? In front of the entire company?

Yes. That is what transparency is.

And I remember a couple of weeks later when that same PO took down one thing they were working on and replaced it with another:

Since we now are focusing on A we have stopped doing B.

That was a proud moment. Well done PO. Sadly the moment only stayed for about 3 seconds because someone yelled in anger:

WHAT?! A is mine! I’ve waited. I will not accept this decision.

A perfect example of how to not foster a psychologically safe environment.

Why

We still think that autonomous teams make the best decisions. In order for them to dare to do that they need to operate in a safe environment. People that are scared are not their best self and they are not courageous and bold.

We need that. Because we don’t know what the best course of action is. That is what we need them to go out and discover.

Fostering this type of culture is something that everyone needs to pay attention to all the time. It is hard work. Luckily I have shaken hands with the CEO and go the permission to shut any un-safe behavior down.

That anger-yell was actually frustration leaking … ah well exploding out. But that person wanted to know why. The way it came out was not good though, because that poor PO was now scared again. We can talk about this. It’s not personal - it’s behavior that we can do something about.

And together work towards a better tomorrow.

Cross-cutting concerns

It would not really be scaling if we didn’t have more than a couple of teams. We are, as I write - but the jury is out, 7 teams that are working like this.

But sometimes … who am I kidding … often we have a need to synchronize on certain topics: Architectural guidelines New regulations and laws Changes in business strategy and others that you can probably figure out better than me As we now have made a big number out of having autonomous (but not isolated!) teams that govern themselves - how do we handle the things that we do need to synchronize on?

Because there are things like that - and it should be.

What / How

If you drew our organizational structure of teams it would look something like this:

Our team org

A classical matrix organization. But this also how we handle cross-cutting concerns; we form cross-cutting groups where needed.

Make no mistake; the decisions are still within the autonomous teams because they have all the perspectives.

But obviously they cannot know everything - so we have a group where they meet to get external input. It can range from Enterprise Architecture to prioritization to hiring new people. The best way to get access to the decision making in the team is to … meet with the teams.

The product owner for the teams meet weekly (or if it is bi-weekly) and that is a perfect opportunity to reach all of the teams at once with information.

There are other groups forming around other types of cross-cutting concerns; developing and testing for example. And hey; Agile, of course. We share and spread information but leave the decisions up to the autonomous teams.

Why

The first thing that I’ve noticed here is that much of the things that used to be a need for synchronization goes away as we start to focus on team autonomy and effects.

Two examples; is it important that everyone is using the same method with the same cadence/iteration length? Some are using Scrum other teams flow-based approaches. Is that important to synchronize on? No - it is not. As long as we can find ways to do integrations with those that we need to integrate with. There’s a hack for that; talk to them.

Second example: just about every team here has a different board. It ranges from a simple hand-drawn board on a whiteboard, with 3 columns, over a HUGE hand-drawn board with about 22 columns and 100+ tickets to a few web-based boards. They are all different. Because the teams are all different and have different needs. Is this important that we synchronize on? No - as long as we can understand status and progress between the teams when needed. Our hack for that is the big board with value deliverables, as described above.

We want and promote differences in the teams. Otherwise, it would not make a lot of sense asking them to improve their process, right?

But there are some overarching things that we need to synchronize on. We make sure there are forums to reach the relevant people/teams with that information and then leave the implementation of that to the autonomous teams. Because they will also live with the consequence of that decision.

If someone outside the team decides for them (how they should work for example) a very strange situation appears; where someone without skin in the game has decided details for people with skin in the game.

You can read more about this reasoning in a blog post on guilds

Confession time

First, dear reader, this blog post went WAY too long. Sorry. But I also wrote it as a summary of many of our thoughts and reasoning. Thanks for bearing with me so far.

We are not living this to the full. Some of the teams are not governing a value stream, but more projects or initiatives. We are working on that so that the teams can be even more autonomous.

This doesn’t work that well for us. Yet. As we live with a legacy of systems that are not built for autonomous teams to work in we sometimes encounter a hefty dose of dependencies. We are working hard to make our system architecture helping our way of working.

The weekly meeting is not always productive and helping us to reprioritize. It turns into status reporting where everyone is nodding and quickly walks away. But we are changing the format from time to time and trying to engage in more productive discussions.

The effects that each team is working towards are frequently confused with activities/progress and we end up with seeing (gulp) Gannt charts on the board. But we are continuously evaluating to make it more about value.

In short - we are not doing this perfectly. But I don’t care that much, because we are improving. Just about every day or week at least is a little bit better than last. That fills me with hope.

Summary

Don’t do this! It will not work (as) well for you as for us. Hey - not even we are happy with this. We are tweaking this constantly.

Do, however, see beyond our practices and to our principles and see why we did what we did. And then try to apply that principle in your world.

Oh, the short snappy title (“Principle-led. Context-dependent.”) came from Andy Carmichael. Thanks, Andy!

Twitter, Facebook