Singapore Airlines is one of the worlds most respected airlines. They keep winning airline awards. I happened to live in Singapore and therefore it is most easy for me to fly Singaporeair. And, I have to admit, it is one of the better airlines and I especially notice this when I fly other airlines.

A well respected company. Known for its good service. A national company many Singaporeans are proud of. Yet, last week, they made an unbelievable F*** U*. So bad, that I'm seriously considering of starting to fly other airlines. Even though it doesn't relate to their flights but... their website.

Last week, Singaporeair did a sudden deployment of a totally new site. Absolutely no incremental deployments, but what seems to be perhaps years of work, suddenly deployed all at ones. I have heard that the company doing this for Singaporeair is... Accenture! (couldn't find anything on the web). And it is an absolute disaster. At first, I just thought the UI was bad, but no... the whole site is bad... but that's not all. The last days I have not been able to buy tickets anymore, which I assume is the main purpose of the site. Every time I try to buy a ticket, I get "system error". Everything in this deployment smells like a waterfall project gone very bad. But let me dive a bit deeper.

First, this was an all-at-once deployment, whereas it seems it would have been "easy" to do it incrementally. But lets assume that it is done "all-at-once" because of difficult technology changes. Even then, the old-site of Singaporeair was gone! Why would they run that risk and not, instead, have the old and the new site running together at the same time. Even the ISP I used for years (pair.com), they never swapped out their webmail at once, but kept the new site as a beta next to the old site. With a site where, I guess, a large part of your purchases come from, why would a company like Singapore Air run the risk of loosing that income (which they have now)?

All-at-once deployment aside, I'm not a UI expert, but the new UI sucks enormously. Not only make the choice of colors and fonts it hard to read, also it takes me a longer to buy a ticket (the one time I succeeded) because there are en enormous amount of clicks. Also a lot of technology seems off or used wrongly, which is visible by e.g. 1Password not working anymore for payments. Not only did they change their site, but also their booking confirmation emails (WHY!?). They didn't bother to inform tripit.com about that so that all the frequent travelers using both these services are not able to combine them. UI-wise, these things ought to have been discovered with earlier review cycles (sprint reviews) as they seem so obvious. If they would have bothered to take one frequent user of the site and let them use it, it would have been obvious. Why am I so sure? Well, just google Singaporeair and new site and you'll find complains for example on BusinessTraveler such as "Awful is an understatement" or Australian Frequent Flyer Community such as "Gotta say that I hate the new website." I mean, that is obvious and should have been found way earlier in the development. Not sure how this site was developed, but it smells like a pure waterfall.

All that aside, if I could use it, I would be somewhat happy. But if I try booking a (try it!) from "Singapore" to "Salt Lake City" date of departure "August 5", date of return "August 12", I'll get:


I tried it again and again the whole week. I reported a bug even. But no luck, it seems to not be possible anymore to book a ticket with the new site. This is truly unbelievable, how could a respected company such as Singapore Air allow to deploy a website which is SO BUGGY that even the basic functionality which is the main revenue stream for the company... does not work!

This was reported in the local newspaper: Straights Times in their article "Bumpy start foe SIA's new website". Didn't read the whole article (don't want to subscribe to straights times) but the most amazing part of the preview is the responds from Singaporeair Spokesman Nicholas Ionides:

'As with any major IT project, we do expect teething problems but we expect to be able to iron out these issues in due course. We will closely monitor the website's performance, and make adjustments where necessary.'

So, deploying an all-at-once, unusable, buggy and slow website in 2011 is *still* expected? I do not know where Nicholas has been the last 10 years, but I wouldn't expect it and find it truly shameful.

This post relates to a post written by a friend George Dinwiddie related to the Satir Change Model. In the post he refers to a tweet I made related to the Satir Change Model. I'd like to add some clarification and argue that it is not "just a model" :)

Over the last year, I've started to get a little annoyed with the Satir Change Curve. You can find this in nearly every Agile development book. An example of the curve can be found here. I've used the change curve myself in the past, so why my annoyance?

The diagram expresses an assumption that all change will improve the performance, which we all know, is untrue. If we all know this assumption is untrue, then why would it matter? It matters in the way the change curve is used.

Imagine I'm a consultant promoting reverse-typing-driven-development. It's a wonderful idea where we switch out editor to type from right to left and we start each line of code with the end. As a consultant, I collected all this evidence in brain research showing that right-to-left typing and reverse thinking enables more brain connections and thus making developers more creative, smarter and better. It will improve the performance! So, I go to a team and train them in RTDD. They start off, but it feels a bit uncomfortable in the beginning. I grab out the Satir Change Curve and tell them that that's normal. The earlier way of typing was their status-quo and this change is a foreign element, so their performance will decrease and you will be in chaos! The team accepts my wisdom on change, after all, Satir was a family therapist. Eventually they get used to it, they stop complaining and keep typing in reverse. I declare victory and use them as an example of a successful adoption of RTDD.

The above is exaggerated, but there are a couple of interesting lessons in it. First, the actual measure of performance was missing. This is common and probably a reality of the industry we work in. In product development, especially in software development, there are so much variables that nearly every measure of performance fails. The change in the example was made for productivity and especially productivity in software development is not measurable.

But, I think the most important lesson of the story is that the change model caused the team and the consultant to stop challenging and thinking about the idea. Especially the consultant, he assumed the RTDD working style will improve performance (independently from context) and with that assumption he closed his mind for learning further. This is a very common problem which happens to me also a lot--I know the solution, so no need to think about that anymore, I just need to figure out how to get through the resistance of the people. Very dangerous.

Is the Satir change curve useless? No, probably not, there is definitively some truth in it. This is where the discussion a couple weeks ago became very interesting. I grabbed my Virginia Satir book to look for the curve and... it wasn't there! Now, I'm not a Satir expert, but I couldn't find a direct reference on the Internet either. (If I'm wrong, please, anyone, correct me!). The main reference on the Satir Change Curve seems to come from Gerald Weinberg. So, the curve actually should be called the Weinberg Change Curve and should be separated from the Satir Change Model. Most of this post relates to the Weinberg Change Curve and not the Satir Change Model. Is the Weinberg Change Curve useless? No, neither, but it can be easily misused. (Note: I don't have all of Satir's work and if anyone discovers that this paragraph is nonsense, then please let me know! I'd love to learn more about how the curve and the model relate)

One last thing. George's post was called "It's just a model" and we need to keep that in mind. I agree and yet also disagree with that. I agree it is "just a model" and a simplification. However, models contain assumptions and when models promote wrong/dangerous assumptions, then the model itself becomes dangerous. If that is the case (I'm not saying it is related to the Weinberg Change Curve), then instead of saying "Oh, it's just a model," we ought to say "that model is wrong!"

In the previous blog post, I gave a list of points when adopting agile in an organization. One of them was:

• Start with one team but immediately make the organizational changes needed to support that one team.

But what does that mean "the organizational changes needed to support that one team" ?

I usually recommend four organizational considerations when getting one team to work. (they are actually 3, but one is repeated for stress):

• Dedicated cross-functional teams
• Define "done"
• All work flows via the PO
• Keep out project managers

Let me clarify these:

Dedicated teams

This is probably the biggest change. With a dedicated team, I mean a team where the team members are for 100% on this one team. Also, the team is not temporary... it is not "just a project team". The team members know the change is serious... so serious that this change needs to be reflected in the organization. The members of the team have to report to the same "line" manager--without this it causes the confusion of conflicting loyalties. The team should take a shared responsibility for all the work. Specialization should blur. But when people report to a functional manager then this will be an restraining force which causes people to focus on "their area". To break this and to show that the initial Scrum pilots are serious, the organization has to reflect this in their org chart.

Define Done

The "definition of Done" defines the scope of the organizational change (the one mentioned in point #1). If we include technical writing, systems integration testing in the initial definition of done, then the people with these skills need to be taken out of their silos and put in the dedicated team. However, when the definition of done is smaller, it would lead to less change (but more delay and risk!). So, an organization adopting Scrum needs to define done to decide on the scope of the change.

All work flows via the PO

Teams need to focus to get work done! Focus, one of the original values in Scrum, is difficult when the team is interrupted from many directions. To get the initial team to work well, they need to be clear on what the work is that they need to do and where this comes from. Make this clear in your organization that the team is off-limit and that if anyone wants work from the team then that person needs to talk to the PO.

Keep the project managers out

This is the same as the previous point but it seems useful to repeat it. Project manager is not a Scrum role and the project management responsibilities are divided over the three other Scrum roles. Adding a project manager to a Scrum organization causes enormous confusion in responsibilities and dis-empowered Product Owners and ScrumMasters. To avoid this, make sure the project managers in your organization know that a Scrum project is off-limits. If management wants status of the project, they need to ask the Product Owner.

These four points seem simple but are incredibly hard to implement in an organization. However, they can be implemented on a team-by-team basis and that enables a gradual transformation of the work... and the organization.

I'm frequently asked whether I got tips for how to start an agile adoption. A lot of people are looking for the ten step magic recipe that will magically transform their organization to an agile organization. I tend to reply with the 'bad' news first: Every organization is different and it probably takes a long time... think years not months. That said. Over the years I've collected small tips which helped organization I worked with. Some come from organizations that tried them out and it worked really well... others come from organizations that tried out the opposite and it was a disaster.

Here they are, tips for adopting agile:

• Avoid forcing Scrum on people and instead find people who are willing to try.
• Get enough training so that all people have the same understanding. Differences in understanding is a common failure point.
• Go See how things *really* happen. Talk to everyone. Look at code and tests.
• Start with one team but immediately make the organizational changes needed to support that one team.
• When adopting Scrum, also focus on the technical practices that are needed. Technical and organizational agility have to go hand-in-hand.
• Do not buy any agile tools. Tools are unlikely to be the main problem.
• Do not change Scrum or the technical practices without first many months of practices
• Get in coaches. Organizations that want to do it all by themselves usually make a lot slower progress. This will be a huge change and getting help is a good idea.
• Make sure the team is co-located and has an "agile-friendly" office environment.

Why just these tips? I don't know. From my experience, these seem to be of major importance.

Me and Craig have given more adoption advice in our "Inspect & Adapt" chapter of the "Practices for Scaling" book. You can find a free copy of this chapter on informIT

ps. Thanks to the other Odd-e people for their input!

Everyone knows it! Nokia is *not* doing well. The new Windows strategy is not popular with the (geeky) public or Nokia employees. Recently, a couple of blog posts and comments have been posted about Scrum, Nokia and "The Nokia Test". I don't want to criticize the points made, though do want to correct the linkage between Nokia and the Nokia Test. Let me clarify.

I used to work at NokiaSiemens Networks (NSN) and, before that, at Nokia Networks (and before that at Nokia, but that is irrelevant for this post :P). In early 2000s, Nokia consisted of making phones (perhaps 75% of the company) and making telecom infrastructure (perhaps 25%). They were still the same company, but within the company they were very very separated. In 2007, the Nokia Networks unit was merged with Siemens Networks to create a new company... NSN. This company is not Nokia or Siemens.

Nokia Networks was one of the early adopters of agile development and Scrum in Finland/Europe. I like to believe that it had quite an impact to the Scrum in Finland as they asked their partners to use Scrum, but that is irrelevant for this story. I was invited to 'lead' the Agile coaching team in Helsinki as I had agile development experiences (mainly xp). I accepted and moved from China to Finland (cold!) where we supported product groups that wanted to change their development to agile.

The adoption in Nokia Networks wasn't top-down as the coaching team was hidden in a centralized department and had no authority (good!). We visited different product groups who were experimenting with agile development and create one community. This made it seem like we quickly had a big adoption, but in fact, we only combined all the grass roots initiatives and made them visible. By doing this, we traveled throughout the company to visit different teams who said they were doing "iterative" or "agile" or "scrum" or "xp". But we quickly noticed something interesting...

Most of the time, when we visited a product, they told us things like "we do iterative development, our last iteration was planned to be one year long, but it actually took two!" or, one of my favorites, "we do scrum, we are now in our 6th planning sprint". We, the coaching team, were getting frustrated with this as we were only a few and there were thousands of developers, who should we support? At some point, we decided that going "deep" rather than "broad" was a good idea, that means, we worked with the product groups that were serious and make them into examples. All we needed to do was filter all the product groups that were not "too serious." I remember discussing this with Kati (my pair in Nokia Networks) and we together quickly created two slides, one saying "you are not doing iterative when" and one saying "you are not doing Scrum when". We added these slides to our introduction to agile material and agreed we would use it internally (in the coaching team) do decide which product groups are serious.

Perhaps a year later, Jens Ostergaard invited me to his course and talk a bit about Nokia Networks (not yet NSN at this point). I grabbed some slides including the "you are not doing iterative development when"-slide in the appendix. (the presentation was similar to this one). Jens liked it and mentioned the slide to Jeff Sutherland who started to use it himself and called it "The Nokia Test." We didn't think the slide was very special so, of course, we had no problem but were very surprised to discover that it  became popular. I guess that had something to do with its simplicity.
A couple years later, in NSN people asked us to ask what this "Nokia Test" was about. (I remember Kati, the co-creator, asking me about it!). Most people in NSN didn't know about the slide as it was mainly used by the coaching group and it wasn't used for product groups to self-evaluate them. A year later, people in Nokia started contacted me about what this Nokia Test was all about because people in Nokia had never heard about it.

A couple points related to this, Nokia and Nokia test:

• The Nokia test ought to be called "The NSN test" as it wasn't created in Nokia
• The Nokia test was *not* for products groups to evaluate themselves, but was a coaching tool
• The Nokia test was not really a test, it was called "you are not iterative when"
• Most of the early Scrum adoption was in NSN, not Nokia. Thus conclusions about Nokia and the Nokia test are very irrelevant.
• AFAIK, most of Nokia Scrum implementation wasn't deep. On the developer level, they adopted Scrum, but they never made management changes that ought to happen in a good Scrum adoption.

Oh, an amusing final note. I never use the nokia test myself. I don't particularly like the scoring test that it morphed to. I consider tests like that not useful except for a very specific context (and the context was quickly checking the seriousness of an agile implementation)

The last month, I've come across this issue several time, to my surprise (because it hasn't come up in the years before).

If you are wrapping tests around legacy code and the legacy code has a C-style assert in the production code, then what do you do? Do you write a test for it? If so, how? Do you delete it? Why?

C-Style assert

Lets first have a look what C-style assertions are and why they are there. Assert is used for expressing a state that is always true. An assert cannot fail, if it fails then there is a bug in the code. So, C-style assert should and cannot be used for error handling. If the error is possible, then proper return value or exception error handling should be used, but if the error is impossible then this can be ensured and documented by using a C-style assert.

An extremely silly example is:

int a = 5;
assert (a > 0);

If this would fail, it would be a bug in the compiler.

C-Style asserts often go together with design by contract. In design by contract, we design the pre-condition, post-condition and class invariant to be per definition true. If it isn't true, then there is a bug in the caller in the case of breaking a pre-condition, a bug in the supplier in the case of breaking a post-condition or in the class in the case of breaking a class invariant. C-Style assert can be used to document this by, in the case of pre-condition, putting asserts at the beginning of a function. For example:

void doBlah(int x)
{
   assert (x != 0);
   ...

So, this code reads that the doBlah can never be called with 0, if it does, then there is a bug in the function that calls doBlah.

Assert and unit tests

Oki, so now we know why the asserts are there, but how do you deal with them in unit tests?

Well.... you don't.

If we take the doBlah function above, we don't need to write a unit test for the doBlah to assert when x == 0. This is an impossible situation and it is not needed to test that. As said, assert is not error handling, it is error in programming :) You design (the contract) states that this is impossible and thus there is no need to test it.

Though, it ain't that easy. You do need to make sure the assert is really an assert. I often read code where the developer uses assert as a method for error handling (and he will regret that when the assert goes off in a production environment, though usually assert is commented out for production code). If assert is not assert, then you can delete it and add proper error handling.

Assert and test-driven code

Many years ago, I used to write a lot of asserts in my code. It was known as good style to make your contracts explicit. Today, I nearly never write an assert and tend to delete them from production code when I see them. Why?

First, I can't add the assert when I test-drive as it still is a line of code for which I don't have a test :) But that wouldn't be fair, as I *could* in theory test it (stub out the assert in the C-library). To better understand why I don't write them, we'll need to look at the purpose. An assert makes sure something can't happen and documents that. When test-driving code, we document how to use a piece of code in the tests. So, therefore the documentation aspect of tests causes the assert to be less useful. Also, the impossible situation often won't happen because I tested it, so I don't need to put the assert there.

So, what to do with C-Style asserts in existing code? I usually do either of these two things:

• Leave them and use the information as documentation
• Delete them, they clutter the code

Review posted on amazon.com:


I was looking forward to David Anderson's book. While I wasn't enthusiastic about his previous book: Agile Management, I liked his new work and the balanced view on change he is promoting. It all made me curious.

I've not been disappointed. Kanban is a readable and balanced book which introduces the Kanban method of bringing improvement and change to organizations. It is well written (better than his previous book, IMHO) and well-argued with many cases from David's own experience and from other people in the growing Kanban community. It is and will probably stay the definitive reference for the SW Kanban method.

The book consists of four parts. The first part is a short introduction to the subject. The second part is called "benefits of Kanban," but it better describes its history (from David's perspective). The third part is more of less a description of the Kanban method itself (called "implementing Kanban") and the last part contains several background improvement theories which the reader ought to know about when implementing Kanban.

Part two is called "benefits of Kanban" and is more or less a history of how Kanban has evolved. Chapter three is what the author calls "the recipe of success" and its David's opinion on what you need to do in order to build good and predictable software. I didn't like this chapter too much as it had a "just do this and everything will be ok" tone which I also found in his previous book. Chapter 4 introduces the work David has been done at Microsoft and how he improved a team without changing the process but by managing the WIP, an interesting story. Chapter 5 described David's work at Corbis where he continued his earlier Microsoft experiences and extended (or actually created) SW Kanban.

Part three describes the different aspects of Kanban. It starts with analyzing the existing processes, visualize it and then decide the boundaries of what is inside the Kanban scope and what is considered the outside world. The "outside world" works with the Kanban team based on SLA and releases based on a steady cadence (chapter 8 and 9). From chapter 12 the book covers less known Kanban topics such as classes of service, different reporting, scaling and operational reviews. Chapter 15 is then the actual "implementing Kanban" that suggests how you can move forward and implement these ideas in practice.

Part four covers broadly said three different improvement models: Theory of Constraints, Lean, and Deming. Each chapter provides a minimum introduction into the subject and suggests the reader to use these different models for making the gradual improvements in their processes. Chapter 20, the last chapter, discusses handling obstacles that need to be resolved quickly in order to make improvements.

There were a couple of things I liked a lot about this book... and a couple of things I didn't like and disagreed with the author. One of the things I disagreed with was the hidden suggestion that the problem of building quality software has been a solved problem. I got this feeling from the way he mentions things like professional testers, CMMi as obvious and barely covers e.g. integration. The book contains very little (nothing) about the actual development of software. But, as this isn't the main topic of the book, it doesn't matter that much... The thing that did bothered me was the suggestion that all works flows sequentially and that one activity has one purpose. I got this feeling from the way e.g. analysis topics were handled or how the last chapters talked about an activity being waste or not... for example estimation. Though, I agree that estimation might/might not be waste, during the process of estimating there is often requirement discovery ongoing, which is very valuable. However the side-effect of activities wasn't covered well and, I felt, it was assume that activities have one purpose and flow sequentially. That said, it might not have been the author's intention and just my sensitivity to this.

Then, the things I liked a lot about the book. One thing I really liked is how David positioned Kanban not as a SW development method but as an incremental (evolutionary) improvement paradigm. This book definitively challenged my own assumptions about change and how change ought to happen. Kanban tries to avoid change resistance by not making the change, visualizing the current processes and then making the change obvious to the people involved. I do think it has some drawbacks, but definitively like the approach. This message isn't given at one particular point, but it is the common theme of the book and of the Kanban method. Well thought of and also... well written. Another things I liked about the book is how David constantly refers back to his own experiences. This is not a book that says "hey, I got an idea, lets try this", but its a book where the author reflects on his history (together with the reader) and uses that to explain how he got to certain conclusions. Well done.

All in all, this book will definitively be the standard reference for Kanban. I was thinking between a four and a five star rating. I decided to go with four stars for the couple of things I didn't like. Anyways, definitively recommended for anyone who wants to know more about SW Kanban.

Below is a draft of an article I've been working on. Any comments are welcome!

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

Specialization in Scrum is a hot topic for already many years. It pops up at every Scrum course I do. It is an important topic and is relevant for a new team in their first Sprint.

Specialization comes up when I explain to people that by the definition of Scrum, a team must be cross-functional. I also recommend the members to be 100% dedicated to the team (they are not a member of multiple teams). Most people who are new to Scrum accept it without considering the implications. Sometimes someone will ask: "But what will the QA person do at the beginning of the Sprint?"

There are a couple of assumptions behind this question. The first assumption: test can only start after development is done. This common assumption is just not true. When adopting modern practices such as Acceptance Test-Driven Development, the test starts before the development has started. The second assumptions is that a QA specialist can only do QA. I personally found that one of the greatest skills of humans is: they can learn new things! So, I don't believe this assumption to be true either.

The question can be generalized to:"What does a person with blue-specialization do when there is no blue-work". Blue could be testing, front-end development, Java, component C, database changes, writing documentation or whatever. This happens nearly always in a team using Scrum. Why? Let's look at the scenario in the picture below.

Last weeks, I've been able to spend time with my good friend Lasse Koskela. He was in Singapore for three weeks to work together on a new "Scrum Developer" training. During the creation of the training, we came across the "repair manifesto" which inspired us to device the "refactoring manifesto" from it. It was an enormous amount of fun and turned out to be pretty good.

You can find the refactoring manifesto over here. Please sign it :)

An error message I just don't want to forget. Today, I got this error message in some code:

error: invalid preprocessing directive #eror

(do read it carefully)