How to facilitate an awesome Sprint Review in “Bazaar mode”

This article aims at helping Scrum Masters to conduct the *MOST AWESOME* Sprint Review they ever witnessed. (This article could have been titled: 41 tips that will make your Sprint Review awesome!)

The main purpose of the Sprint Review (SR) is to collect feedback. After seriously inspecting the product, a number of changes to the backlog or action points for solving impediments should be identified.

The Scrum Guide says: “During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.”

You must have witnessed them at least a hundred times: those Sprint Reviews where each team gets their moment of fame to show off what they have been sweating on over the past couple of weeks. How disappointing it is to look at PDF documents, powerpoints and wiki-pages full of awesome designs or other fantasy the team spent the CEO’s money on. Someone occasionally asks a polite question to prevent awkward silences. The hurdle of brain dead sheep praises the demo with a dutiful hand of applause. Off course they do; They are the next in queue, inapt to present anything in front of large crowd, excelling at boring the hell out of us.

We can do much better than this. “Show me some value or GO HOME!”

Foremost, the SR is supposed to be a thorough inspection of working software. Sitting in a room looking at dull slides or screenshots will not very likely spark a creative buzz. Did you ever do a successful inspection of anything without being allowed to touch it? No. So people should get hands on with the product and the developers should observe them. Only then we will collect sensible feedback. The attendee will click the wrong buttons, will browse back, refresh and do everything else you can imagine that was not included in our happy flow.

Read More here

Product teams — agile done right

After transforming management, comes changing the actual teams working on your software. Most organizations think about software as projects: something that has a finite set of requirements, schedule and budget, and a finite end date, the date it’s delivered. There’s some consideration put into updating the software, managing its full life. This project mentality can seem to make a lot of sense, esp. if you’re outsourcing much of your software.

Mark Schwartz calls this project approach the “contractor control” model. His theory is that this model is based on management’s mis-trust of the people doing the work, whether they’re contractors or internal staff. As he outlines in A Seat at the Table, this drives a heavy emphasis on status meetings, compliance, and lock-step road-maps:

How could you control a contractor? You asked for an estimate and pressured the contractor to deliver at or close to that estimate. Or you agreed on a fixed price. How could you control IT? Same model, but with the twist that the IT staff were your own employees who were paid a fixed salary — a bit awkward. Since their cost was fixed (at least in the short and medium terms), your biggest worry was that they would waste time on frivolous activities. How could you know that they weren’t? Simple: you insisted that they deliver on schedule, and kept the pressure on them to do so. Some of IT’s work was transactional: user support, device provisioning, updates, and maintenance. In those areas, costs and lead times could be benchmarked and monitored. But a good deal of IT’s work involved delivering capabilities — developing and integrating applications, rolling out ERP systems, installing collaboration tools, and so on. For IT to demonstrate that it was performing that type of work responsibly and for the business to verify that it was doing so, the scope of each task had to be defined precisely, bounded, and agreed upon in advance. The work had to be organized into projects, which are units of work with a defined set of deliverables, a beginning, and an end. You could establish control by making sure the project was completed within the bounds of its estimated cost and schedule. How perfect the Waterfall model is for this purpose! How perfectly it aligned with the business’s need to know that IT was under control.

The results are predictable: frustrated people, bad software, and slow failure like two drunks in a bar-brawl.

Sobering up starts with two words: product and team. Doing software well requires thinking about it as a product, not an ongoing project. This is how software vendors think, of course: the software they create it what they sell. A product is interested in accomplishing its user’s (and customer’s) goals, ongoing, until it’s no longer needed. A product evolves to match the user’s evolving needs. The focus is on continually making the best software possible.

Product-centric organizations move from the functional organization, contractor control model to an agile, product-centric model.

Read more here