Book review: Management 3.0

"Management 3.0" is written by Jurgen Appelo, a dutch author with an active blog.

If you take a look at the blog, you'll understand where the book came from, most of the content covered in the book is on the blog in some form or other.

So, what is the advantage of the book over the blog? Well Jurgen introduces his 6 views on management and gathers/aggregates his blog entries under these 6 views, splitting each view into a chapter on theory and a chapter on practice.

The book succeeds in presenting alot of information, from a wide variety of disciplines such as chaos theory and agile. Quite often Jurgen gathers existing models and combines/modifies them to build his own model. Generally the thinking is good and gives some new insights.

I found the book hard to get through at times (and in fact I didn't quite finish it). There isn't that much of a "story" in it, and I find it could profit from some more real life examples to spruce it up. I do think it makes a great reference. If you ever find yourself wondering about this or that model, and how it all fits together with agile/leadership/managemment, then this book is a good book to pick up and flip to the relevant pages.

ADAPT and Switch

In Mike Cohns great book "Succeeding with Agile" he mentions the acronym ADAPT as the 5 steps necessary for an agile transistion in an organization(ie change). The letters stand for Awareness, Desire, Ability, Promotion, and Transfer. Very similar to Prosci’s ADKAR change model which describes the necessary phases for an individual to adopt a permanent change in their behavior and attitudes. The K an R stand for Knowledge and Reinforcement respectively. I guess in moving from an individual to an organization knowledge and reinforcement are replaced by promotion and transfer.

Anyway, I wanted to match ADAPT up with the steps in the great book Switch by the Heath brothers (see an earlier blog). So here goes,

Awareness

The reason why change is required should be clear (ie the problem that has to be solved).

This is related to "direct the rider", particularly "point to the destination". After all, the destination should be better than where we are now.

Desire

You may know a problem but still not want to fix it. Some unfinished chores in the house come to mind.

This is related to "motivate the elephant", particularly "find the feeling". Desire is after all all about emotion.

Ability

You may want to fix a problem, but simply lack the ability to solve it or make a positive change. Again, certain household chores spring to mind.

This is related to "Direct the rider, script critical moves"; after all, everyone can carry out simple instructions. But this is also related to "Motivate the elephant, shrink the change"; after all small changes are easier to carry out than big daunting overhauls. And finally, this is related to "Motivate the elephant, grow your people"; after all training, teaching and coaching will increase the ability of people and your organization.

Promote

In an organization, you need to motivate more than one person for a change to occur. This involves alot of communication (selling).

This is related to "Shape the path, rally the herd"; organizational changes require momentum to build up. Also, this is related to "Direct the rider, find the bright spots"; if positive change is working somewhere then celebrating it goes a long way to keeping momentum going.

Transfer

In an organization, having succeeded with change in one department, or team, or organization unit doesn't mean you are done. The rest of the organization will also need to adapt, otherwise organization gravity will simply drag the changed unit back down to the old state.

This is basically saying, iterate the ADAP steps again and again everywhere in the organization. In that sense, it relates to the Switch steps mentioned above. More generally, this relates to "Shape the environment".

Switch (the book) and Agile/Lean/Kanban/Scrum

"Switch, change when change is hard" is a great book about change (see an earlier blog entry). Now lean/agile/kanban/scrum (LAKS) is all about continous improvement, and all improvement is change (although not all change is improvement!). So after having read the book I started wondering which of the guidelines in the book are reflected in the LAKS way of thinking/frameworks. After all, LAKS is good at continous improvement so there must be significant overlap with the guidelines in the book. Here's a first stab (from my limited experience with primarily scrum and kanban).

Direct the rider, find the bright spots

In the retrospective, which is a meeting held regularly, what went well is a typical item on the agenda. This serves to assert the positive, but also triggers an awareness of things that are working and can be extended and improved upon for even greater gain.

Similarly, in the daily stand up team members tell what they did. This is an opportunity to share their work amongst the team, and thus also communicate about things that went well, problems solved, etc. Thereby creating awareness of the bright spots.

Direct the rider, script critical moves

During the retrospective, the most pressing problem is identified and tackled by defining (and carrying) out one (and only one) small step that will lead to an improvement. Typically this is *not* a complete solution to the problem, but just a first small step in the right direction.

Also, during the daily standup any impediments are identified with the explicit goal of getting these resolved as soon as possible with the product owner. This is an example of a scripted action that should lead to improvements (ie removal of the impediment).

Direct the rider, point to the destination

One of the goals of LAKS is to stabilize the velocity and then improve it. Having the velocity visible in charts (like the burndown) for all the team to see (and also the variability in the velocity) is key to making sure the team knows what they are aiming at.

Also the iterative development process with frequent demos and constant interaction with the customers and/or product owners ensures that the software that is being developed (the final destination) is constantly being realigned and redefined, and is constantly in the fore front of everybodys mind.

Motivate the elephant, find the feeling

Feelings in IT? Never! Still, nothing like a weekly demo for customers to cause a developer te break out into a cold sweat. Fear and the desire to please are strong motivators to deliver good software on time. Also, regular interactions with the customer and/or product owner go a long way to fostering and understanding of why the customer wants what he/she wants. Generally, this understanding will lead to improved software being developed.

Motivate the elephant, shrink the change

Refactoring and test driven development are great examples of shrinking the change. If you have unit tests in place, then improving your code (refactoring) is a breeze and nothing to be afraid of any more. In fact, it becomes a pleasure and something you do because it makes you feel good.

In general, LAKS avoids trying to "get it right the first time". Instead the focus is on building a small part as simple and as fast as you can, and then improve from there. A big software project is chopped into smaller user stories, all broken down into even smaller tasks, each task written test driven so that refactoring is easy going forward.

In terms of processes, LAKS provides a starting point only; a bare framework and a minimal set of guidelines. The whole point of LAKS is to begin with something (anything) and improve upon it continously. Finally changing the process into something unique that fits your business. The guidelines or framework are not contained in a complicated 400 page manual but typically fit on one A4. I'd call that shrinking the change.

Motivate the elephant, grow your people

LAKS is all about the team, not the individual. Team members are encouraged to become more multi disciplinary so that they can help out whenever bottlenecks occur and can cover for each other during holidays and illness etc. This requires growing both technical as well as team player skills.

Frequent interactions with customers extend the domain knowledge of the team, thus enabling them to build better software. In addition, code reviews and peer programming allow team members to learn from each other.

Typically, team members can pick their own work from the current queue of prioritised tasks. They are thus more responsible and have greater control over their own work. This is most often conducive to personal growth.

Shape the path, tweak the environment

The focus on the team typically means scrum or agile teams will be working together in team rooms. This fosters communication and mutual understanding, opening the road to frequent minor improvements, often too small to mention or pinpoint.

LAKS is often about making things visible, think kanban or scrum board (information radiators). This means that team members are confronted every day by the work in progress and waiting for them. They literally see it on the walls of their team room. Having the work visible makes it easy to talk about it, and this often leads improvements being discussed right infront of the board.

Shape the path, build habits

LAKS is all about habits. We have the daily standup, the retrospective, test driven development, refactoring, peer programming, code review, scrum planning meetings, demos, and more. As we have seen above, all of these habits are conducive to improvement. After all LAKS is a process, and a process is nothing more than a collection of habits we have all agreed to build.

Shape the path, rally the herd

The team focus instead of the individual focus is one form of rallying the herd. Peer pressure tends to drive people to carry out improvements they might not have done solely for themselves.

Also, the large and active LAKS community is a great source of motivation to improve should you find the team beginning to flag in enthusiasm. Nothing like a good conference or open space to get a team fired up again about making improvements.

Small barriers

I'm a tall guy, so when I shower I move the shower head all the way up along the adjustable rail just so I can stand under it without stooping. Of course, not handy for the rest of the family who can't even reach the shower head to lower it when they want to shower. So my wife was constantly reminding me to lower the shower head back when I'm done, and I of course was constantly forgetting. But then I figured it out. My wife was always reminding me after I had left the shower and already dried off, so adjusting the shower head then would mean getting wet again (from the shower head dripping), and it was this small, teeny "barrier" that was blocking me from actually learning/remembering to do it myself. On the boundary line between concious/subconcious I was making a decision that I just didn't want to do it.

Once I became concious of the barrier blocking me, it was easy to fix. Now I lower the shower head before I leave the shower and dry off, so the dripping is not a problem as I'm already wet anyway. Now I always never forget.

Trivial? Maybe. But I happened upon more examples once I realized how such small barriers can control your behaviour. Another personale example is the garbage container. I have to roll it out on monday evening for it to be emptied by the truck on tuesday morning. Meaning that tuesday evening I have to go back outside to roll the now empty container back. Something I never relished doing, especially in the winter, when it's cold, and you're nice and cozy inside.

In this case the barrier is more obvious, the cold outside. But the solution less so. Funnily enough, I just started jogging again (yes, not easy to keep up either) and when heading back it suddenly dawned on me that since I was outside anyway, I might as well drag the container back in. Trivial? Duh! But still it was now almost a pleasure to do the task, whereas before it was always a chore I "forgot" every now and then.

Small problems, and even smaller solutions, but the impact can be big. I've seen that with agile as well. Using a kanban board to make the work and flow (or lack thereof) visible is a great information radiator which encourages lively discussions right infront of the board. Nothing like a bunch of blocked tasks (impeditments or barriers) to start a discussion how we can improve the process. And the solutions are often small, trivial steps that in themselves cannot be the complete solution, or so it seems. But quite often, just making one tiny step is all it takes. All the subsequent improvement steps you thought were goign to be needed fall by the wayside because the problem is gone, the flow is back, and the process is working acceptably again. Too often people think up elaborate plans to tackle a semmingly big problem and then get stranded. Kanban I find encourages you to identify the first small step and then do it, and then see what next. Works much better.

Another 2 book reviews

Lean software development: An agile toolkit, by Mary & Tom Poppendieck

Great book! Definitely choc a bloc full of really usefull information. This is a book I'll be returning to many times and each time I will probably learn something new. Alot of the stuff needs hands on experience first to really understand the value of what has been written down but I'm definitely eager to get started right away.

------------------------------

User stories applied: for agile software development, by Mike Cohn

A pleasant, easy read. Nothing very shocking but good to have on paper to grab for reference. there is quite a bit of padding to the book, it could have been a bit thinner without having lost value I feel.

Two book reviews

Test driven development: by example (Kent Beck)

An easy read (also quite thin). Didn't learn too much new but the later sections/appendixes that list refactoring patterns were quite interesting (I hadn't read about them before but I sure recognised some of them!).

Growing object-oriented software, guided by tests (Steve Freeman, Nat Pryce)

Sometimes a tad theoretic, sometimes a tad too practical. The automated testing of the user interface (reading value of label for example) is too extreme for my tastes but it was impressive to see it done. Great book to learn about mocking and mock objects! After all, Steve and Nat helped build jmock. It also expanded my ideas of TDD. I was to focused on unit tests but this book broadened my scope to include tests at every level and not to get too hung up with terminology.

Certified scrum master!

Five years ago I started my own IT company JanXL. Since then I haven't been without freelance work unless I chose to be. Which is great :-)

But I realized I hadn't been to a course in over 5 years as well. So it was time to talk to management (me). After all, a good company invests in it's employees. Luckily, it was an easy sell, which is why, come last thursday, I found myself in a room of 40+ IT people all hanging on the lips of scrum founder Jeff Sutherland.

It was great! Despite the course consisting mainly of 2 full days of slides , Jeff is the real deal and he told from personal experience which kept it interesting. Luckily, there were a few exercises and games. The scrum master course was organized by Xebia who also organize the scrum meetup nl (next one is februari 4 in Hilversum).

So now I'm a scrum convert, certified scrum master, member of the agile alliance, and eager to go out an preach the agile gospel.

Which is why I started this blog. To chronicle my agile adventures (or lack thereof).

Wish me luck :-)