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

Improvement Stories: a simple alternative to User Stories

You are the Product Owner for a Scrum Team. Your team has just released a brilliant feature they have been working on for months: Change History. Change history allows to track who made what changes to users. Everybody is excited and happy the feature will be finally shipped.

Users love the new feature, but they immediately provide feedback. After the feature is released, you end up with a list of 10 small improvements you want your team to work on.

Translating the list of improvements to User Stories

You start writing User Stories, but boy is it a lot of effort. It is difficult to write clear User Stories for these changes. The improvements seem so small and simple, why is it so hard to capture them in User Stories? You also get the feeling that you are repeating yourself. After all, you already have great User Stories for the features these improvements belong to.

For example, you notice the user change history overview takes about 10 seconds to load, so you start writing a User Story:

As an administrator, I want the change history overview to load quicker, so that I have less waiting time.

You also notice there is no hover state on the filter row of change history, even though this violates UI guidelines. You try to capture this in the following User Story:

As an administrator, I want the filter row of change history to have a hover state, so the affordance is clearer.

2 User Stories down, 8 more to go. Using User Stories does not feel natural at all. Is there a better way to write these User Stories?

Enter Improvement Stories. Improvement Stories are great for small improvements. You already have User Stories that explain the context really well. You just want to make some small improvements. The User Stories describe the problem you are solving for what user. You just want to make some small tweaks. So you just link the Improvement Stories to your existing User Stories. Now you and your team can easily access the context of the existing User Stories if necessary for deeper understanding. The Improvement Stories get to remain small.

Read more here