Andy's Mind

A question I frequently see asked on the Internet is whether agile teams should release every iteration (or even more frequently) or not. When asked in relation to Scrum the question is usually if software should be released every sprint. With other methods – like now-popular Kanban – the question is what release frequency would be right, as the method itself doesn’t say anything about it.

I think that many times this question reveals an underlying confusion between keeping software releasable and actually releasing it to the public. I think one construct from Scrum can help clarify things here.

Scrum calls explicitly for a “shippable product increment” to be delivered at the end of each sprint. It means that the end of each&every sprint a new version of the software must be ready that passes the quality criteria (in Scrum expressed as the “definition of done“) and ideally includes all the features the team committed to delivering at the sprint’s outset. However, this new version is called “shippable” not “shipped” for a reason. This reason is that whether to release a new version of software to the users is ultimately a business decision.

This distinction is very important. Just like the shape of the backlog is a result of a whole series of business decisions made by the Product Owner the decision to go with the product to the public is a decision that can be (and quite frequently is) made by stakeholders. As such it is definitely out of the scope of any process/method managing the development itself or the team doing the development.

There are of course numerous benefits from actually releasing each and every “shippable product increment“: greater user satisfaction, faster user feedback, better discipline in the team and less risk (deploying smaller changes is less risky than deploying a big-bang, all-changing release). In fact this is what we have been always practicing, also when working on our Scrum tool.

However it has to be understood that situations (companies, products, etc.) vary and can be very different. Sometimes there are other factors involved – for example domain (in embedded software releasing every sprint may not be even possible), market influence (eg. developing a major feature and not wanting to let on before it is complete) or alignment with other elements (like when software is part of a larger project, where other things have to be in place for the new features to be used or usable).

So, a team can be agile even if what they develop is not released every iteration. They just have to work as if it was in terms of quality and effort spent testing the software to ensure that it could be deployed when needed.

Someone has asked if management or project management should come to the sprint retrospective ¹. Think the way this question was asked indicated that there was some confusion regarding sprint retrospectives versus sprint reviews which, I think, is worth clearing.

Sprint retrospective and Sprint review are two different things that shouldn’t be confused.

Sprint review is for everyone involved, especially stakeholders, to inspect where the project is and discuss how to adapt as needed. Sprint review revolves around what was built – the “shippable product increment” produced in the last sprint – and the overall product, not how it was produced.

It is good if Product Owner “represents” stakeholders, but it is even better if they come and see themselves what was accomplished, what runs etc. My advice is to welcome management of all kinds if they want to come to a sprint review, just being sure they know what the purpose of the meeting and their role in it is. Ensuring that and educating them is primarily Product Owner’s job, but of course the Scrum Master may assist him.

Sprint retrospective is primarily for the team to inspect their last sprint, concentrating less on what was done than on how it was done, and then adapt their way of work. I wouldn’t include anyone outside the team in those, besides maybe the Product Owner if he/she wants to join.

A common objection to bringing management of any kind into retrospective is that team may not be comfortable talking about their dirty laundry in front of them. It is indeed very valid – but it is also worth noting that from managements’ prospective this would be a waste of their time to, for example, listen to developers debating how to improve branching in their code repository. Even if the management knew what the heck the team is talking about this is not something they should waste their time on. Managers have lots of things to do (collectively called “bigger picture”) which no one will do for them – this is where their time will be better spent.

Having said that an overall retrospective on the project or on a longer chunk of it (like a quarter or half a year) that would include management may make sense, but it would not necessarily include all team members (if you have many teams that would make it even impossible to do). Such a retrospective would concentrate on “big picture” and could be very beneficial – if there is of course a right atmosphere within company for people to be honest enough in such a retrospective for results to be useful.

Speaking of retrospectives – definitely worth buying is “Agile Retrospectives” Esther Derby and Diana Larsen. There is not much to read there – just a couple of introductory chapters – but it is a great cookbook of various techniques to use in different phases of a retrospective based on how much time you have and what is the retrospective about. Each technique has a description of how much time to set aside for it, how to facilitate it and where its place is the overall sequence of a retrospective.

Great help, since classic “what we did well? what we didn’t do well?” etc. becomes boring pretty quickly. Anyone who facilitates retrospectives on a regular basis should have this book.

[1] – original question.

Jesse Fewell – a long time proponent of building bridges between the world of traditional project management and agile – has brought to my attention the newest initiative by Alistair Cockburn – “The Oath of Non-Allegiance”:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

This should be obvious in the context of looking for ways to better run projects, but clearly it is not. The world of agile is full of divisions, bickering and discussions that remind me of good old days of comp.os.advocacy. As Jesse points out, even the thought leaders of the agile community practice very little collaboration that is the cornerstone of this whole approach. Why?

I think there are two reasons for this.

First, for some agile – or, worse, just one flavor of it – has become something akin to a secular religion that gives their lives sense and meaning – the one and only true way to not only run software projects, but also “transform the world of work” and people’s lives worldwide. It doesn’t matter if this attitude is true or faked – believers will fight with each other over slightest details always defending their chosen flavor of agile. They will also savagely attack anyone who dares to suggest agile is just a tool.

Second, once money is added to the mix things are bound to get hot. People have built their livelihoods around teaching and promoting certain “labels” and, naturally, they will fight to protect what they consider to be their turf. This is exactly same reaction as the one we are getting from “traditional project managers” when promoting agile – they feel their jobs are at risk from methods with no room for someone that will tell workers what to do.

Both attitudes are normal and very human indeed, however they should not shape the world of agile. I think most of us – people involved in agile – want to get things done. I’m enthusiastic about Scrum not because I think it will put the whole world as we know it on its head – but because I know from first hand experience that Scrum simply works on software projects. I’m pretty sure there are projects where it would fail – and I would use other, more appropriate methods there.

I’m sure there are more pragmatists like me and it is a good thing that their voice is heard. I signed the Oath.

Last Saturday I attended a mini-conference called Agile Tuning here in Cracow. Kanban was what was talked a lot about and there was the usual automotive reference: Toyota. There is a lot of fascination with Toyota in the agile community (and elsewhere) and it has always bothered me a bit, but I didn’t really understood why. Somehow this came to me during that event.

You see, there are two problems I have with this “Cult of Toyota”.

First, clearly some of stuff that is inspired by Toyota’s approach to making cars is about how they manufacture them. For example, the whole Kanban system has its roots at Toyota but it was used there to optimize the flow of material to the assembly line and thus the line’s effectiveness. However, software development is not, repeat, not about churning repeatable products from a production line composed of machines and people performing endlessly same tasks. Software development is an inventive process. Therefore we should rather look at similar fields, like product development – we should look at how Toyota designs their cars, not how they assemble them. This whole notion of looking at software as manufacturing is utterly nonsensical and ignores the reality of how software is created.

But, secondly, one thing that is clear to me is that whoever got fascinated with “Toyota way” clearly wasn’t a petrolhead. Toyotas may be reliable and Toyota surely is a great company in business terms, very well organized and managed but their products are anything but fascinating. Toyotas are generally boring small cars and family sedans, not very innovative, not very beautiful, just means of transport to get from point A to point B and not think about it too much. In a sense Toyotas are mediocrity perfected.

I personally would be way more interested in observing and trying to understand how companies that produce outstanding, breakthrough products – or at least products one can be passionate about – work. I would prefer to know how Tesla car came to be than how Toyota Corolla was design. But we don’t have to look at automotive industry for examples – within our own industry we have way lots of creativity and passion. Take Apple. It did produce more innovative, great products people do care about in the last 10 years than Toyota did through its entire corporate existence.

The only problem is that we will have to wait until Steve Jobs dies before management science would be finally able to analyze how Apple works on the inside. Before then his legendary paranoid secretiveness and unending myth-building would, I guess, prevent any serious study of this truly amazing company.

That doesn’t mean, however, that until then the best thing we can do is try to mimic Toyota’s assembly line.