Agile smagile!

Book review: Kanban

Daði Ingólfsson — Mon, 07 Jun 2010 10:27:07 GMT

Just now I finished David J. Anderson's recent book, Kanban - Successful Evolutionary Change for Your Technology Business, in between trips to the kids who are supposed to be asleep but keep calling for water, books, hugs, ...

To do this review I'll use the rules from The Perfection Game to guide me. So, here goes:

I give the book a 9 on a scale from 1-10 (hint: I really like it a lot).

What I liked about the book was (not an exhaustive list)

how well the first chapter described David's searches for sustainable pace and successful change management, and how it took me by surprise with its very humane message of giving the team back a social- and family life.
David's Recipe for Success for the Technical Manager
- Focus on Quality
- Reduced Work-in-Progress
- Deliver Often
- Balance Demand against Throughput
- Prioritize
- Attack Sources of Variability to Improve Predictability
the great stories from his own time at Motorola, Microsoft and Corbis.
David's insistence on making the meaning of words bandied about in Agile/Lean cirlces very clear before proceeding to tell you it's great and you must have it. For instance, his fabulous description of Kaizen culture on pp. 49-50 where he dives deep into why Western culture's win-lose mentality makes it so hard for us to establish a win-win Kaizen culture in our workplaces.
in general I find that David writes well and very much to the point which I really appreciate.
that the book contains an extremely practical guide to implementing Kanban, as well as going into the more advanced techniques, such as how to deal with non-linear workflows, classes of service, scaling Kanban, and others.
the Operations Review chapter, as it was a revelation to me to read about how a business unit of 100 or more people could retrospect every month in only 2 hours and get good results from it.
the sections on the goals for doing Kanban are great because it exemplifies how David keeps himself and the reader grounded in reality, and makes sure to keep the business needs in mind at all times.
David's intense focus on science and asking why.
how David always ties every practice or guidance with a higher level goal.

For me to give the book a 10 the following improvements would have had to have been made:

tell more good stories like he does in the first part of the book to counterbalance the very clinical vocabulary of the whole text.
Provide a better explanation for the reasoning behind the advice to delay improving requirements prioritization (the PO process as I think of it) until the team "is capable of focusing on quality, limiting WIP, delivering often and balancing demand against throughput". I have a hard time swallowing that advice and agreeing with David's view that "[p]rioritization is rightly the job of the business sector, not the technology organization..." I agree that biz should prioritize, but I read these words as too black and white where biz designs the product and IT just implements what the biz comes up with.
Instead of using the word 'resource' to describe a human being, use 'person' or something similarly animate-sounding.

To summarize: A brilliant book from a brilliant guy that all IT people should read, especially managers and team leads.

Uncle Bob stirs the pot again with "Dependency Injection Inversion"

Petar Shomov — Sun, 24 Jan 2010 23:48:53 GMT

Uncle Bob posted what was considered a rather controversial blog post, which basically pointed that just because Dependency Injection is a good thing, does not mean you cannot shoot yourself in the foot with the DI framework. He drew attention to the fact that these frameworks in their desire to be more usable have all kinds of bells and whistles, which you might just stop and think about before you jump in and start using them.

My initial reaction to this post was very positive since I always have considered the DI container something external and (potentially) replaceable. Looking from a DDD point of view (I tend to look from that one, don't I? ;) it is infrastructure which is not central to my apps, which means it should not be meshed with my core code. Hence my tweet:

I liked the point he made: you see, you can do Dependency Injection without a container. I would add, I think everyone who is doing Dependency Injection should do an exercise once in a while - write a small app without a DI container. There are two points in this exercise: one - to make sure one remembers the point Uncle Bob made, and two - to appreciate the DI containers.

Towards the end he says:

Most of the time the best kind of Dependency Injection to use, is the manual kind. Externalized dependency injection of the kind that Guice provides is appropriate for those classes that you know will be extension points for your system.

Not so sure how I feel about this one though. Most of the time I do use DI container unless the app is very very small, but unless I try I will never know, right ;)

Interestingly enough the .NET alpha-geek crowd jumped(and again and again) Uncle Bob on this one. Agreed with him for the most part and bashed him for the quote I just mentioned as well as for his example being too simplistic. I feel they are being a bit arrogant(bashing the Java tooling and all that) but they do have a point though. What do you think?

Last week and Situational Leadership II

Daði Ingólfsson — Thu, 10 Dec 2009 22:43:10 GMT

What I've been doing, almost exclusively, for the past 2 years is to help various IT teams here in Iceland make the leap to becoming agile IT teams, and their departments to become agile departments. The way in which I have been doing that is to work with each team for at least 5 weeks, in a program we've developed at Sprettur Marimo called Agile Jumpstart.

Anyway, just last week we hosted the biggest series of events in our company's short history where we sandwiched our AGILIS 2009 conference with, first a CSM class with Alistair Cockburn and then a CPO class with Jeff Patton. The whole week was as a smashing success, as my partner Petur Orri likes to say, and we are all very thankful and proud that so many people came to get excited about Agile and Lean.

Finally, the preamble is over and I can get to my point. I was talking to Jeff Patton about the way we structure our Agile Jumpstart package and that we use Ken Blanchard's Situational Leadership II (SL II from here on) model to vary our coaching style through these 5 weeks. He found it interesting and told me he'd 'steal' that idea (I hope you do, Jeff!), so I thought I'd share it with you as well.

The SL II model is really quite simple. It aims to guide leaders (teachers, coaches, ...) to pick the right style to lead with based on the learning needs of the people being lead, so to speak. To read more details about it check my link above or Google. The way I employ SL II in our Agile Jumpstarts is to start by informing the team I'm working with, that this is a way I've found to be effective when working with teams, and if they have no strong objections I'll do that with them as well. This is very important - I have forgotten to do this and it's not good.

Consequently, using this model I start out with a Directing style. This is at the beginning when I'm helping the team get started with Scrum. It means I train them, and direct them through a series of facilitated sessions to bootstrap their process as well as directing them through much of their first sprint.

Next, I go to a Coaching style, and work closely with the Scrum Master and Product Owner while they get used to leading and facilitating the process. Here I'll be less directive and the Scrum Master takes on most of the facilitation that I did to begin with. I give the Whole team high support and provide them with the safety they need to do the process work themselves, but I try to facilitate a lot less.

Third, is the Supporting style where I don't facilitate at all, I'm just observing and supporting the team. I answer questions of course (and ask some of my own), but at this point I'm getting ready to leave the team to itself, so the less I do (or need to do) the better I feel about leaving.

Fourth, is the Delegating style, and many cases this just means I move on to another engagement at another company. In other instances, where I'm coaching many teams at one company I can be reached and consulted with, but effectively I'm off the case!

The past year or so we have been using this model we've been really happy with it and it seems to make a lot of sense to people that we coach. Obviously, it's not always as cut and dried as this linear description of mine seems to suggest, but having the model is very helpful and I'd recommend people take a look at it if they are in any sort of leadership position in their lives.

Introduction to the Core - Core Series Part 1

Pétur Orri Sæmundsen — Mon, 09 Nov 2009 00:18:22 GMT

We have been implementing the idea of a working agreement within teams when we do Scrum consulting. The team develops a list of principles which the team members agree not to break. Popular principles include things like "Respect each other", "Don't be late" and "Say what you think". The working agreement defines a social contract that help people work together. When I was introduced to the idea of a working agreement I immediately liked it since I saw it as a good way for team members to connect better with each other. But that was about it.

More than 6 months ago my Sprettur partner Daði introduced us to the Core by sending a video featuring Jim McCarthy from Agile 2008. I found out that the Core is a system to support a shared vision within a team. It is a working agreement that has been in development for over 10 years and is in version 3.02. Listening to Jim talk about the Core made me realize that the working agreement is the most important aspect of teamwork because it supports a shared vision (even more important than the right development method :) ). I already knew that a shared vision is crucial if a team is to succeed but always had vague ideas about how to get there.

We, the Sprettur guys, have now been using the Core for 6 months now and its power is amazing. Always when we run into trouble in our teamwork it's because we are not using the Core enough or we find out we didn't fully understand how to use it. The Core is so powerful that I have started using it at home with my family :)

The Core defines 11 commitments and 11 protocols. The commitments are similar to the working agreement discussed before but the protocols are procedures to support the keeping of the commitments (more on the protocols later). Following are the 11 commitments which should be read "I promise, X ":

I commit to engage when present.
I will seek to perceive more than I seek to be perceived.
I will use teams, especially when undertaking difficult tasks.
I will speak always and only when I believe it will improve the general results/effort ratio.
I will offer and accept only rational, results-oriented behavior and communication.
I will disengage from less productive situations
I will do now what must be done eventually and can effectively be done now.
I will seek to move forward toward a particular goal, by biasing my behavior toward action.
I will use the Core Protocols (or better) when applicable.
I will neither harm—nor tolerate the harming of—anyone for his or her fidelity to these commitments.
I will never do anything dumb on purpose.

In this series I will go through all the commitments and the protocols and describe how we, the Sprettur guys, have been using them and failing with them.

Managing energy, audiobooks and fractured ribs

Guðlaugur Stefán Egilsson — Tue, 20 Oct 2009 22:25:35 GMT

One of the best things that resulted from my founding of Sprettur a couple of years ago, was that I learned a thing or two about the importance of continuing learning and acquiring new knowledge. A part of that is that we listen to audiobooks quite a bit. As a result, I've listened to 18 audiobooks, most of them with a management or business related focus. A couple of those books have influenced me deeply, the last one to do so is "The Power of Full Engagement" by Jim Loehr and Tony Schwartz.
The subtitle of the book says a lot about its content, which is "Managing Energy, Not Time, Is the Key to High Performance and Personal Renewal". For me, this is turning out to be a very fundamental paradigm shift, as I have been focused on time and project management practices, both on the personal level, such as Getting Things Done, and of course all the Agile processes, such as Scrum. The revelation for me, is that as good as those processes and practices are, the chances are that managing your time better is not what you really need.

It so happened that just over a month ago, I had a little accident and fractured a rib. A friend of mine which had a similar injury not so long ago, told me that week number three would be the worst, apart from the first few days of course. This turned out to be pretty accurate, I was able to attend work until about three weeks after my accident, that I simply had to go home around noon, as I was completely drained of energy. It just so happened that I had downloaded this book the day before, and decided to start listening to it.

One of the statements made in this book, which is common sense when you hear it, but obviously something whose importance is easily forgotten, is that we get our energy from two sources. The food we eat AND the air we breathe. It is this latter half that we apparently take too much for granted, and rarely think about. Now, even with a fractured rib which affects your breathing significantly, I did not think much about breathing (other than how painful it was to take a deep breath) until reading this sentence. And it hit me, that I was obviously taking unnaturally shallow breaths due to the fractured rib, and that was a probable cause of my fatigue. So I decided to experiment with this on myself, and perform a simple breathing exercise described in the book for the rest of the day and the next day. The results were pretty dramatic for me. Not only did I last easily at work until 7pm the next day, but the fatigue I had experienced the last days before was completely gone.

The issue I had was apparently that the pain associated with breathing with a fractured rib leads to shallower breathing than is normal, leading to drained energy and fatigue. As soon as I realized the problem, and performed a simple breathing exercise a few times a day (take a deep breath and exhale slowly, repeat a few times over a minute), the problem vanished. This result is quite dramatic, which could become my fortune, because this is a lesson I will never forget. I fully believe that the benefit for healthy people is substantial as well, simply from conscious breathing.

Apart from the breathing, there are a lot of good advice regarding proper diet habits, physical and mental exercise, rest and recovery which I am starting to implement. Although a bit early, I am going to say that my energy levels are now (after only 2 weeks of doing this) at the highest level they've been in years, leading to more willingness to do things and higher productivity. I trace this mostly to this book, and I would like to encourage everyone to read it. And, although not much time has passed, and other factors are influencing me, I feel that the results from this paradigm shift are so great, that I will continue to consider this book the most influential I've read, so far.

- Guðlaugur Egilsson

Here is my top 10 list of audiobooks, ranked by the place the have in my mind at the moment.

The Power of Full Engagement Jim Loehr and Tony Schwartz
How We Decide (Unabridged) Part 1 Jonah Lehrer
The 7 Habits of Highly Effective People (Unabridged), Part 1 Stephen R. Covey
The Future of Management (Unabridged) Gary Hamel, Bill Breen
Outliers (Unabridged) Malcolm Gladwell
Beyond the Goal (Unabridged) Eliyahu M. Goldratt
Getting Things Done (Unabridged) David Allen
How to Win Friends & Influence People (Unabridged) Dale Carnegie
Tuned In (Unabridged) Craig Stull, Phil Myers, David Meerman Scott
The 8th Habit (Unabridged), Part 1 Stephen R. Covey

And the other 8:

Rethink (Unabridged) Ric Merrifield
What Got You Here Won't Get You There (Unabridged), Part 1 Marshall Goldsmith and Mark Reiter
Dumb Money (Unabridged) Daniel Gross
The Audacity of Hope Barack Obama
Crucial Conversations Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
Lean Solutions James P. Womack and Daniel T. Jones
Made to Stick (Unabridged) Chip Heath and Dan Heath
The E-Myth Revisited (Unabridged) Michael E. Gerber

Orkustjórnun, hljóðbækur og brákuð rif

Guðlaugur Stefán Egilsson — Sat, 17 Oct 2009 15:58:30 GMT

Eitt af því besta sem gerðist fyrir mig þegar ég stofnaði Sprett með félögum mínum, var að ég lærði ýmislegt af félögum mínum um mikilvægi þess að halda áfram að læra og tileinka sér nýja þekkingu. Hluti af því er að við hlustum mikið á hljóðbækur, og hef ég núna hlustað á 18 slíkar, lang flestar með stjórnunarlega eða viðskiptatengda vinkla. Nokkrar af þessum bókum hafa haft mikil áhrif á mig, núna síðast "The Power of Full Engagement" eftir Jim Loehr og Tony Schwartz. Útgangspunktur þessarar bókar er að lykillinn að velgengni og hamingju í lífinu, sé meðvituð og góð stjórnun á nýtingu og endurnýjun á persónulegri orku, frekar heldur en tímastjórnun, sem er þessi hefðbundna sýn, og sú sem ég var alltaf að reyna að vinna eftir.

Það vildi svo til að ég lenti í því fyrir rúmum mánuði að bráka í mér rifbein. Félagi minn sem lenti í því sama ekki fyrir löngu síðan, hafði sagt mér að vika þrjú væri verst, fyrir utan fyrstu dagana, svona þegar þetta væri að skríða saman. Þetta gekk nokkuð vel eftir. Það gekk alveg þokkalega að sinna vinnu fram að því að rétt tæpum þrem vikum eftir brotið var ég farinn að vera verulega þreyttur, og kom að því að ég entist ekki nema hálfan daginn, og varð að fara heim, alveg búinn á því. Það vildi svo til að þennan dag byrjaði ég á því að hlusta á þessa bók.

Eitt af því sem þeir segja í þessari bók, sem er augljós sannleikur þegar maður heyrir hann, en greinilega eitthvað sem menn eiga auðvelt með að gleyma, er að við fáum orku okkar úr tveimur áttum. Matur og drykkur sem við borðum, og súrefni sem við öndum að okkur. Það er þetta síðara sem við tökum sem of sjálfsögðum hlut, og hugsum nánast aldrei út í. Þetta fékk mig til að hugleiða stöðuna sem ég var í, örþreyttur að fara heim um miðjan dag, þó lógískt séð ætti ég í raun að vera í betra standi heldur en vikuna á undan. Ég ákvað því að gera tilraun á mér, og gera öndunaræfingar eins og lýst er í þessari bók, það sem eftir var dags og næsta dag. Og árangurinn var mjög dramatískur. Ekki eingöngu entist ég til 7 daginn eftir á löngum og ströngum degi, heldur bar ekkert á þreytueinkennum eftir þetta.

Málið þarna er nokkuð augljóslega það að sársauki vegna rifbeinsbrots verður til þess að maður andar grynnra heldur en eðlilegt er, sem veldur síðan orkuleysi og þreytu. Um leið og maður gerir sér grein fyrir vandamálinu, og gerir einfaldar öndunaræfingar nokkrum sinnum á dag (anda djúpt að sér og hægt frá, endurtaka 2-3 sinnum á einni mínútu), þá hverfur vandamálið. Árangurinn við ofangreindar aðstæður er mjög dramatískur, og það gæti orðið mín heppni því ég mun aldrei gleyma þessu. Árangurinn fyrir fullfrískt fólk er umtalsverður líka, bara af því að anda meðvitað.

Fyrir utan þetta hef ég reynt að fara eftir öðrum ráðleggingum í þessari bók varðandi mataræði, öndun, líkamlega og andlega þjálfun og hvíld, og ég held að ég leyfi mér að segja að orkustigið hjá mér og vilji og löngun til allra verka sé nú þegar (2 vikum síðar) orðinn hærri heldur hann hefur verið í mörg ár. Ég rek það að mestu leyti til lestur þessarar bókar, og hvet ég því alla sem ég hitti núna til að lesa þessa bók. Það er að vísu stutt síðan ég las hana, en árangurinn hingað til lofar það góðu, að ég býst fastlega við að þessa bók muni ég í framtíðinni álíta sem þá af þessum bókum hér að neðan, sem mest hafði áhrif á mig.

- Guðlaugur Egilsson

Til gamans er hérna topp 10 listinn minn af hljóðbókum sem ég hef hlustað á:

The Power of Full Engagement Jim Loehr and Tony Schwartz
How We Decide (Unabridged) Part 1 Jonah Lehrer
The 7 Habits of Highly Effective People (Unabridged), Part 1 Stephen R. Covey
The Future of Management (Unabridged) Gary Hamel, Bill Breen
Outliers (Unabridged) Malcolm Gladwell
Beyond the Goal (Unabridged) Eliyahu M. Goldratt
Getting Things Done (Unabridged) David Allen
How to Win Friends & Influence People (Unabridged) Dale Carnegie
Tuned In (Unabridged) Craig Stull, Phil Myers, David Meerman Scott
The 8th Habit (Unabridged), Part 1 Stephen R. Covey

Aðrar hljóðbækur sem ég hef hlustað á (óraðað):

Rethink (Unabridged) Ric Merrifield
What Got You Here Won't Get You There (Unabridged), Part 1 Marshall Goldsmith and Mark Reiter
Dumb Money (Unabridged) Daniel Gross
The Audacity of Hope Barack Obama
Crucial Conversations Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
Lean Solutions James P. Womack and Daniel T. Jones
Made to Stick (Unabridged) Chip Heath and Dan Heath
The E-Myth Revisited (Unabridged) Michael E. Gerber

Lessons learnt the hard way

Petar Shomov — Fri, 02 Oct 2009 22:35:50 GMT

I just got off a large project that one of our customers is running. I will not go into details but it should suffice to say that it is a rather large multi-phase project that is supposed to create the future IT backbone for that customer. Before I move on I though I should stop and analyze what we did right, what went wrong and what can I learn from this experience. And I thought I would share it with you dear reader ;)

1. Deploy by the end of the first month to a user
In large companies there are usually many reasons why a project cannot be deployed: dependency on another project which in turn depends on another project and so on, or someone has to get legal approval for something to be released. Yes, there are many excuses not to deploy, but in the end that's all they are - excuses. The business needs to see value, your team needs to get feedback from real users about the system otherwise you are risking building something no one is interested in and/or the business people loosing their business patience. My future rule of thumb would be - if you have not deployed to actual users by the end of the first month of the project, you need to do get angry and demand this to happen right away.

2. Do not accumulate technical debt, push back on Product Owner who does not understand technical debt
Technical debt(from here on referred to as tech-debt) is hard to explain to product owners that have not programmed. This is understandable and there is no easy way around it. We tried all kinds of metaphors but I don't think we succeeded in communicating what tech-debt is and why it is important. The best approach that I can see working is to negotiate a slice of each sprint to go into paying off tech-debt and demand extra on top of that at the first sign of trouble. Letting it pile and telling yourself that it is ok, that you are going to fix it "later" does not work. Never has, not for me. "Later" the debt is usually so big and the bad stuff has usually spread all over the place and fixing it becomes an all-or-nothing mini-rewrites that are very hard to do and are rather unpleasant and unsatisfying experiences.

3. Do not allow architectural astronauts to tell you what tools to use
It is a strange phenomenon but seems quite persistent: a company becomes mid-sized and someone decides that now they need to unify "how we do things around here". And then an Architect (may be even Chief Architect) is appointed who starts googling and creating a list of tools and technologies allowed to be used. And this is the moment when you start to be told what tools to use to do your job by the guy who has never done your job or it has been a while since he has last done your job. Do not let this happen, say "no" to company politics and demand that you decide what tools to use. The list of tools should be coming from you and the rest of the guys that are working in your organization. Architects can be valuable, but this is not the way. Do not buy into tool vendors based on power point presentations and one day carefully orchestrated demos from the salesman. You and your peers should be making the standard in your company. 'nough said.

4. Manage expectations so that they are achievable
I have come to appreciate marketing as a *very* important aspect of product development. The same product may be perceived as two complete opposites depending on how its being marketed. One thing that I've found out is not wise, is to proclaim that your product will be a universal panacea that will fix all there is to fix. This might sound obvious and plain common sense, but I am mentioning it for a reason: the larger the promise you make, the more difficult is to keep it. So I would advise to do small achievable projects and build software products incrementally and iteratively. And the product owners have always to be on the lookout how to generate value with minimum effort.

Well, I am off to the new project ... ;)

Soft as in "Software" - Part III (Dependency Injection for the CEO)

Petar Shomov — Wed, 04 Mar 2009 02:18:51 GMT

In part I of this series I set the stage by introducing angry management/businessy types that feel like being ripped off with this IT stuff but out of peer pressure or what not they keep pouring money into software. In part II I looked at what I believed to be the top reason for the customer dissatisfaction: the fear of change. In this last part of the series I will look at a few of the techniques we at Sprettur believe to be the cure. For the sake of the complete picture I am going to say that we truly believe that the SOLID principles and the XP practices are the way to go, but trying to discuss all of them would make this line of posting very, very long.

So, let's say you are this guy with the solid base to lean on, what do you do next to stop your software from corroding? A few ideas: Dependency Injection, Separation Of Concerns, Domain-Driven Design. I will very quickly go over these and how they can help you, if you are interested just google for any of these and you will get a lot more info.

Dependency Injection allows your code to stick less. Non-sticking code has two benefits: 1) allows the good pieces of your code not to stick to the rotting ones; 2) when you try to take one piece of code and reuse it, it will not make you drag in a whole bunch of other pieces for it to work.

Wow, I guess I can call this explanation "Dependency Injection for the CEO" ;)

Next is Separation of Concerns. What that refers to is when you chop your software up in small pieces based on the granularity of the tasks they accomplish, and then combine the small pieces into bigger clusters to achieve new or bigger tasks. This way the rotting pieces will be separate from the good ones and it will be easy to replace them with "fresh" ones as needed.

There you have it - "Separation of Concerns for the CEO".

Now for the underdog, Domain-Driven Design. Domain-Driven Design (DDD) is not as hot as "agile" but it is gaining a lot in popularity lately. DDD has numerous benefits, but I am only going to look at how it can help your software deteriorate less. The core idea of this school of thought is that you should separate the core logic that makes your business run, from the infrastructure and APIs. I guess you can call it the ultimate anti-corroding technique, but that is the punch line of DDD - recognizing that the business logic far outlives IT infrastructure and therefore we should take extra special care of it, so it will keep delivering value long after cool and hip fades away.

I will try to summarize in a sentence or two. It seems to me that IT has not really proven to be delivering high value and I put blame for that on the Waterfall model and inadequate software quality. We have the knowledge and the tools to solve both problems so we should try to get them to the developers and managers out there. In practice that's what we do at Sprettur.