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.

Sales is understanding and satisfying clients’ needs, not pushing a product or solution onto them. Agile’s contribution is bringing back the understanding of the fact that what is the clients’ true need in software industry is, well, software.

I have been in Warsaw yesterday to meet with Dave Prior, chair of the PMI‘s IT&Telecom SIG who was there attending PMI’s Polish Chapter annual conference. We had a very interesting discussion on agile, project management and… Banana Scrum, most of which was videotaped by Dave and will be made available as a part of IT&Telecom SIG videocast.

This is part of Scrum practitioners and traditional IT PMs trying to come closer together. This will be a hard effort, because of cultural divide (which we discussed too) but it will be definitely worth it and traditional PMs are very attracted to agile. When it comes to getting work done knowing other methods can’t hurt.

Dave, it turned out, is also a huge fan of our humble Banana Scrum tool. It was really cool to meet someone who likes and uses what we have built. Gave me another incentive to make sure our fall hiring campaign will allow us to get more resources to work on the tool. I’d like to finally add a few bigger features to Banana that have been waiting on the backlog for weeks now. It would be good to have something for Christmas for our users.

For those of you unfamiliar with PMI SIGs a few words of explanation. PMI is the most known organization of project managers (yes, those dreadful guys with Gantt charts, shamanic metrics and ugly waterfalls), inside of it there are Special Interest Groups – groups that focus on a certain aspect of project management or projects in general. IT&Telecom SIG is the group that is most interested in agile – they know best how miserably waterfall’s record in software development has been.