Don't Skip the DEMOs

DEMO sessions or Review session are skipped more offen then you can imagine. I do understand the reasons why people may skip this sessions, sometimes people don't have working software to show, team could be not happy with the sprint results or could be that you have so few stories to show.

I worked in projects with lack of demos and this sticks as not only lack of demos but also lack of openness and really could be a sign of doing agile wrong. Because you don't have nothing to hide of your customers, right ? We don't need get paranoiac about that because in several adoptions team do daily meetings with the team everyday smooth integrated.

If the team does regular daily meetings with the business(team + business(pos)) together, why bother to do DEMOs sessions, let's say you do have a great communication in place, I do really need regular DEMO sessions ?

Going back to the Values

I mentioned openness before BUT we don't need stuck only with that one, there are two other important scrum values that I do need mention here like Respect and Commitment. You show respect by your customer show whats really is going on no matter good or bad, because we are not trying to hide or weakness or mistakes, instead we're fighting to archive success and real business value.

Commitments also tells me that its better talk about something that could create value/damage rather than keep it to my self. The matter is not only about showing issues BUT even when you do a kick ass sprint and your POs known everything about it(don't get me wrong they really should known it) could be a good idea perform a DEMO session. Unless you have a very short context, I mean you team and the business are very small so in that case you may skip DEMO sessions and it's fine.

Your possible Business Reality

Scrum tells us no matter the size of the sprint(usual 1-4 weeks) we should perform a DEMO session before the retrospective and the next sprint. There're small great kick ass companies like 37 signals BUT also there're good big companies like Amazon, no matter where you are is doable that you're developing a system that may affect your whole organization. DEMO  sessions are not for the sake of the Product Owners checking public if you shipped what you said on the previous sprint instead is a great opportunities to let other people see whats going on in your project.

You can see the DEMOs not as small training BUT a great opportunity to share information and let the whole company learn what are you delivering, using scrum massive in your organization this is very useful for other work streams or teams. 

Ultimately people will have a taste on what you guys are doing and the value that you are delivering. If you get in this sessions with your pos given acceptance criteria to you it's a smell of lack of communication or  even pos not having time to do it during the sprint.

In this case DEMOs will also be a moment to check if you're performing you job without some bottlenecks, we don't do it for finger pointing or blaming purpose but instead to learn about the process and also improve it.

The team maybe get very close to the pos and this is good don't get me wrong BUT this is one of the few moments that enable you to get out-side-of-the-team opinion and you really should take it.

Depending on the complexity of the project or even the timing of the releases you may want have a little preparation before the demo I see this as a good opportunity not waste, why ? People(developers) will be talking about business and because they prepare to talk about that this maybe provide a different view on what they built. This is noting BUT a source of learning, every source of learning is welcome a board!

DEMO sessions also give space to developers talking in public, Skype or webex with business people and this is great for the personal development, this is contribute with the sense of ownership, more ownership, more people care better. As a Brazilian I also see DEMO sessions in distributed off-shore projects as big deals to improve and put my English skills to proof. 

Diego Pacheco

Popular posts from this blog

Java Agents

Manage Work not People

HMAC in Java