Andy's Mind

I just found a great video about motivation that explains why self-organization works better.

I think this neatly shows why the very term “human resources” which implies treating humans just like any other machine in a company’s inventory is not only unethical and repugnant, but also simply wrong.

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.

A friend sent me a link to a posting on the official Google blog that says they are effectively killing Wave. The reason given is lack of user adoption.

I think what it shows is rather Google’s failure to properly position the product on the market – or even turn the technology they have developed into a product. What they had was a potential Exchange killer – a system that could have been a real game changer in corporate communications as I wrote when it was unveiled. Instead of trying to get general Internet user community to adopt it Google should have packaged Wave as a corporate messaging/integration/collaboration system and market it bundled with support services to large corporations.

Someone else can still do this if they will indeed release much of the technology behind Wave to the public as open source code. Heck, maybe even Microsoft will adopt some of the concepts (and maybe even protocols) into their next release of Exchange/Outlook pair.

Still, this shows us Google is not immune from the problem of many great tech companies: inability to market great inventions. This has happened before many times – companies developed brilliant technology, but then failed to turn it into a product or market it successfully. Some didn’t survive it (Commodore, DEC), some did, but just failed to grasp a great opportunity (like Xerox for example).

So far Google still has its huge revenue stream from their basic product – pay per click advertising driven by search results – so failure to market Wave won’t hurt them. However, some research suggests ppc ads are declining in value as people learn to mentally avoid them (even if they don’t use the great Ad Block plugin as I do). So, dear Big Brother Google, better think twice next time before you throw away some great product in the making.

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.