Archive for the ‘Group dynamics’ Category

Systems Thinking


It all started when I read The Fifth Discipline – The Art and Practice of The Learning Organization by Peter M. Senge. I was inspired to read it after my brilliant previous colleague Pat Kua did a workshop on Systems Thinking. (Dennis Stevens wrote a better summary about this book than I will ever be able to.)

I then continued by reading Freedom from Command & Control by John Seddon as well as attended a presentation from John Seddon on the same topic. While Peter Senge’s book was a very interesting read – John Seddon’s was the easiest one to grasp and the one that really opened my eyes.

Seddon brilliantly shows how the wrong targets and measurements encourage the wrong behaviour and creates what he calls failure demand. Furthermore managers and governments sometimes specifies how people should execute their work – with the intention that these processes will then produce the best results. However, as you probably already know – it rarely does – and leads to poor results and demotivated people. Especially managing cost often leads to sub-optimizations which is not good for the end result. (I find some of this is a good match with the Beyond budgeting movement.)

I would love to use some of Seddon’s own examples to convince you, but I would encourage you to read his book instead. I will try however, to give you a few examples of where I have recognized these patterns in IT projects myself:

Managing cost:
Many IT projects seem to be managed on cost. This sometimes leads to testing only being applied at the end of a project (because that should mean less man hours needed for testing.) This obviously leads to bugs only being found at the end of the project. The later you find the bugs – the harder it is to fix them – and the more expensive you can argue it is to fix them. One of the reasons they are expensive to fix later would be that the developers might have forgotten everything about that area in the code base – the ones who wrote the code might even be gone. Also there is a huge risk that parts of the application might have to be redesigned etc.. So by managing cost – and trying to reduce the cost of one part of a process – the total cost of the project might end up higher than what it could have been had the testing started day one.. One should look at the project as a whole and not try to optimize parts of it independently. And while you are at it – does the project itself make sense at all – if you look at it from a Systems perspective?

Targets and failure demand:
Measuring velocity is common in Agile projects these days. In Kanban you would often measure cycle time. The problem however, is that we rarely get to measure this end to end. I.e. from when the customer requests a feature until he actually starts using it. Let’s say you only measure cycle time from when a developer picks up a story until it is ready for System Test. The developer might have to make the story pass a few unit and acceptance tests, but bugs found later in the process might be raised as new bug stories. Hence in terms of the statistics it does not make sense for the developer to go that extra mile and build in the amount of quality needed for the story to pass System Testing. The developer keeps coding at a high speed – while new bugs are raised. From a Systems Thinking point of view – i.e. from the end customers point of view – this of course does not make sense. The bugs are essentially failure demand – and reducing the failure demand would probably allow the user to get to use his (bug-free) features earlier and cheaper.

To fix this, you should start by looking at the System that encouraged this behaviour in the first place. Namely remove the targets that created local optimizations. From a Systems Thinking perspective it is not the developer’s fault that he produced a lot of bugs – it was the targets he was measured on. So is it his manager’s fault then? Well, maybe, but how is she measured then?

Starting out with Agile – you might try to follow the book – and hence end up doing for instance estimation. I.e. Scrum and XP says we should do estimation – if it doesn’t work for us – then we are probably doing something wrong so we should read some more about Scrum and see how we could do estimation better.

Wait a minute – if estimation doesn’t give you anything – then you shouldn’t do it! Blindly believing in processes or measuring people on compliance – is not the way to get the good results. The important thing is the end result – not how you got there.

Eye opener
What I realized as many have before me, is that all these different tools, CI, pair programming, estimation, 7 types of waste, product owners etc. are all just tools. You should use them if they make sense in your context, but don’t use them just for the sake of it. It is not like Kanban is always better than Scrum. It is not like stand-ups is something you have to do. It is not like IT is the solution to every problem. It is not like people are stupid just because they do stupid things – they are to a certain extent a product of the system. Reflect on your end goal. Learn to see underlying structures. You will be amazed!

Is this it then?
No it is not. I believe I have finally learned by know – that whenever I discover a better theory or a better tool – there is always something better waiting for me around the next corner. Take a look at Jurgen Appelo’s stuff on Complex Systems or the Chaordic Mindset in Bob Marshall’s the Marshall Model of Organisational Evolution for instance.

There is much more to Systems Thinking – and I have only barely started to understand it. Feedback is more than welcome!


Distributed “Kanban”


The distributed team I am working with currently has been trying out a little bit of Kanban.  We have assigned a WIP limit to the In Development / For Review column(s). That is, if the total number of stories in the In Development + For Review columns adds up to (or more than!) the WIP Limit, you should not pick up a new story, until at least one story has been reviewed and closed off and we are again below the WIP limit. (Ideally, going forward we should obviously add WIP limits to other parts of the process to, but we had to start somewhere.)

While there are lots of interesting things to say about this – such as that it has made us more disciplined and probably reduced lead time (working on the stats) and might make the team more predictable –  I will focus on the distributed side of things in this post.

Communication is a challenge on every distributed project I would say, and hence getting buy-in and understanding of the WIP limits at one location, does not necessarily mean that every location understands or starts respecting the WIP limits immediately. As every other change effort, one needs to use the full range of consulting skills / influence strategies.

What is a concrete challenge though is the time-zone differences. If one team finishes development and puts a story into For Review, then their typical next step would often be to pick up a new story. What so if the WIP limit will be breached? Should they wait until the resources that will do the technical and business reviews of the stories gets in (given they work in a different time-zone)? Or should they break the WIP limit?

The previous might force you to add a bit of a buffer to your WIP limit. And that might make sense. However, initially this is what happened to us: Location B puts story 1 into For Review and picks up story 2. Location A reviews story 1, but it needs more development or bug-fixing. Location B gets in the next day, does some fixes on story 1, and finish development on story 2. They even pick up story 3. Location A reviews story 1 and story 2, but they are both still not accepted. Hence Location B now has 3 stories in play.. This could go on for some time.

Let’s say the capacity of Location B is to work on one story at a time. Does it make sense to add in a buffer of 2++ extra then? I tend to disagree. So what we ended up communicating to Location B was to focus on quality before quantity. Do not rush to pick up new stories, but try to finish stories with significant quality.

What happened was two things:

1. Location A started reviewing stories much quicker. Focus was first on cleaning out the For Review queue – then do some development. (In order to give Location B quicker feedback, and prevent them from picking up too much new work before stories had been successfully reviewed).

2. Location B decided the brilliant thing of doing some local technical review first, before marking the story as For Review. This raised the quality, and took some of the work load off location A. It also meant that Location B are no longer rushing to picking up new work, but focusing on completing stories properly.

These two things allowed us to keep our WIP limit relatively tight. We do have a buffer for the stuff in For Review, but we try to keep it as small as possible.

Beyond Budgeting


Staying true to my Personal Kanban, I am obliged to blog about all books I read. Fortunately it will be a pleasure to blog about this book I have been reading lately.

Beyond Budgeting is all about the negative impacts of budgets and how several organizations have flourished without them. Getting rid of budgets, that’s a drastic change, and clearly no serious organizations would ever dream of doing that, you might be thinking now. However, the best example from the book is probably the Swedish bank, Handelsbanken, which have been doing very well without budgets for more than 30 years. Furthermore, I have worked for an organization without budgets myself.

There are several drawbacks with budgets:

  • Cost – They cost a lot, many organizations might spend up to 6 months every year on creating budgets for the following year. There might be far better ways to spend your accountants’ time.
  • Politics and bureaucracy – Budgets can make people lose focus, and a lot of time might be spent playing political games and fighting bureaucracy.
  • Lost opportunities – Your budget targets might say you have to increase revenue by 10%. Well, that might force you to work hard, however, it might also distract you from grabbing an opportunity to increase revenue by 50%.

Removing budgets would typically allow you to empower your frontline workers, make information more visible to everyone, defer decisions until a more responsible moment (no more planning 1 year ahead), reduce waste and utilize your accountants’ competence in a much better way as well as grab more opportunities as they come along. This all is clearly music to lean and agile ears.

If you want to know more about how to move on beyond budgeting, I would highly recommend reading the book. It contains several case studies from different organizations that have replaced budgets successfully in more or less similar ways.

A Kanban Brown Bag Recipe


Kanban appeals to me, and I have had the privilege to hold a brown bag on it two times in the last weeks. The feedback and especially the discussions it started exceeded my expectations in a very positive way. Therefore, I thought it might be worth sharing my recipe for a Kanban brown bag.

The materials you need:

  • Henrik Kniberg’s Kanban kick-start example. (Thank you very much for sharing this Henrik! It would have taken ages to prepare the brown bag without it)
  • A keyword cheat sheet
  • 20 coins
  • 5 stopwatches (or mobiles)
  • 8 participants + yourself

Step 1: Presentation
Connect your computer to the projector and open Henrik’s kick-start example. Scribble down the following keywords on a flip chart as you explain how they are illustrated with Henrik’s example:

  • Visibility – The Kanban board. Visualize bottlenecks
  • Limit Work In Progress (WIP) – Avoid task-switching. Focus on throughput rather than over-utilizing individuals
  • Pull – You are not allowed to push work down the workflow, you pull work when you are ready and are below WIP limit
  • Flow – A steady flow (all the way from analysis to production), not iterations
  • Cadence – You measure and predict, instead of plan and promise

Assuming you have a basic understanding of Kanban and agree with my selection of keywords, your audience should now have learned the basic concepts of Kanban. To make them fully grasp the value of limiting work in progress the next step is to play a simple game:

Step 2: Play a game
I learned this game at XTC (once again thanks to Henrik Kniberg who facilitated the game at XTC).

Basically you start with four players, and four “managers”, standing behind one player each with their stopwatches ready. The first player gets 20 coins. His job is to flip all 20 coins, then pass them on to the next player, which will then flip all 20, then pass them on etc.. Each manager measures the time, from when his player starts flipping the first coin, until he has flipped all 20. You as a facilitator, should measure the time from the first person flips the first coin, until the last person flips the last coin. The initial scoreboard would look like this:

Batch size Player 1 Player 2 Player 3 Player 4 Total time

The next round, the first person flips 5 coins, passes them on, flips the next 5 etc. Each manager measures the time from his player flips his first coin, until he passes the last coin on. The next person starts flipping the 5 coins as soon as he receives them, passes them on, then starts on the next 5 when available… You as a facilitator, measures the total time. The last round, the first player flips one single coin, passes it on, then flips the next..

If you don’t want to know the typical outcome of the game, stop reading now!

The outcome of the game will most likely look something like this:

Batch size Player 1 Player 2 Player 3 Player 4 Total time
20 9.8 11 13 14 56.4
5 16.7 17 21.5 19 32.6
1 14.9 21 23.1 22.3 26.3

As you can see, the individual times is higher for the smaller batch sizes. However, the total time is much better for the smaller batch sizes.

Batch size Methodology
20 “Waterfall”
5 “Scrum”
1 “Kanban”

I have indicated next to each total time which process the different batch sizes could relate to. Hence, tell your audience that if they want to improve their overall throughput, they should limit their WIP and give Kanban a try 🙂

Thanks again to everyone in the community who have shared their material and knowledge.

Adopting Agile – Challenges with the bottom-up approach


Even though someone has probably written about this before, this is something I have experienced to a certain degree and feel I would like to share  with other Agile evangelists.

I’ve read a lot about Agile being adopted with the bottom-up approach. Developers wants to do their jobs better, faster and deliver more business value more frequently. They start exploring Agile approaches such as continuous integration or test-driven development. Sooner or later a couple of evangelists have convinced their team-leader or project manager to try out agile on their next project. They find themselves creating a sprint backlog, having daily stand-ups and maybe even retrospectives.

But hey – what about the demonstration meetings and the product owner? If the business people that are supposed to prioritize the product backlog are not familiar with agile, or are organized in a way that makes it hard for them to agree on a prioritization of the user stories in the product backlog, the project managers or the architects have to take on the customer role. This is a compromise that may very well work out okay. But it is hard to know if it the developer team really is delivering the optimal pieces of business value at the end of each iteration. Meanwhile the organization looses some of the benefits of their teams doing agile – for instance the possibility to turn around or change course quickly.

My point is  that using the bottom-up approach for adopting agile, will force you to make compromises that will affect the benefits of agile. Sooner or later the adoption may spread further up the organization – or if you’re really lucky someone might start a top-down approach too and meet you half-way (not that I know how that would work out =)

Searching for the truth of group dynamics


Every now and then you discover or learn something that you believe is a sound statement, fact or pattern. Something which is true and will stay true even after a long time. Regarding group dynamics, I believe the following are such universal facts:

  • Endre Sjøvold, a professor at NTNU I have deep respect for, states at his website (freely translated from Norwegian): “..when you believe that learning a specific technique is enough to ensure success, is when it actually fails.  It is always so that the balance between technical skills and a genuine willingness to work together is what ensures success.” He says this in the context of looking at the history of hyped methodologies from team building to SCRUM. If you’re an innovator like me, who loves to embrace new ideas, try to keep Endre Sjøvold’s statement in mind whenever you get confused, caught up in too much details or feeling your intuition tries to tell you that something is wrong.
  • Linda Rising and Mary Lynn Manns’ Fearless Change: Patterns for Introducing New Ideas. If you haven’t read this book or been to any of Linda’s tutorials yet, you should really try it! People are not rationale, you cannot convince them with traditional argumentation, instead you should find their guru and feed him with chocolate chip cookies (amongst other patterns).

Finally I believe Joseph Pelrine is really onto something with his heat model. His talk at QCon London was great, and I’m really looking forward to his book. Meanwhile I’ll continue my search..

Will I be the Innovator forever?


I love to embrace new ideas, some would say a bit too much, others would say I challenge them and provide valuable input. I enjoy trying out the latest technologies as well as methodologies. Thanks to Linda Rising I also know that people are not rational – hence if everyone doesn’t buy in on my suggestions all the time, I know I could always try another approach (e.g. feed people chocolate chip cookies..).

However, I learned at the university (especially from Endre Sjøvold)  that members of a mature team does not step into static roles. They adapt to their environment, and acts out the roles that are necessary at specific points in time. So if I find myself taking on the role of being an Innovator for most of the time, does that mean I’m part of an immature team? If so, am I a mature as a person, and as I spot the lack of an Innovator I take on that role? Or do I just do it because I have a preference for taking on the role of being an Innovator? And could that stop me from being a sceptic (or in Linda’s terms, I think; a Laggard) when it is needed of me?

Working as a software consultant in the financial industry, I’ve discovered most people doesn’t tend to take on the roles of being Innovators. But what would happen if I were put in a team where everybody loved being Innovators? Would I put on a more conservative hat when needed? I believe it would be possible for me to do that, but I’m of course afraid that my passion for learning new things would challenge me on that. I think it would be especially hard for me to take on a long term role of being more conservative. Hopefully my other team members would have relieved me from my duties from time to time, since they would be just as mature as me (probably even more :).