Here’s a situation I see quite often. The software development team is rapidly adding features and functions to an application. It makes no difference if the app is completely new or being enhanced. The team is making rapid progress. Yet, the Product Owner is reluctant to show the incomplete app to the business stakeholders and power users.
The PO claims that missing features and defects will confuse and alienate the business supporters. They’ll question everything they see and want to know why features are missing and/or why the software doesn’t work as expected. This problem is pervasive enough that it’s worth stopping to think about.
There are a few things going on here that need to be addressed in parallel.
1. The issue of missing features is rather silly. Of course features are missing — the software is a work in progress! It’s not done yet. If there’s trust among the technical and business teams, missing features are never an issue — everyone understands feature priorities. If trust is weak or missing, everyone is suspicious of the others’ intentions and motivations. The business team will continually seek confirmation of what will be delivered in the final release. They won’t accept anything at face value.
The trust issue has to be met head on. Trust can’t be built overnight or even in the course of a single release. The important point is to make a start. Open up. Show what you know. Make commitments you can keep. If someone requests something outside the current scope, say no and explain why. People will respect your transparency.
2. Defects are a real problem. Why are defects, particularly major ones, getting into the deployments accessed by end users? Software defects in the development environment are expected. The development team needs time to sync and stabilize. If there’s a separate SQA environment for systems integration, additional defects related to inter-system activities can also be expected. But once the software is deployed into a pilot or evaluation environment, it needs to be reliable — not perfect — reliable.
If the software crashes or behaves in unexplainable ways when in the hands of business users, the team’s development and QA practices are insufficient. They need to cut back on adding features and focus on stabilizing what they have. Delivering features is not enough. Features have to be done! (Your team has a definition of done, right?)
3. I’d like to make one last point. I’m big fan of feature toggles. A feature toggle is simply a way for the development team to enable or disable software features. If a feature isn’t ready in time for the next deployment, disable it. If a feature proves to be unreliable, disable it. Once the feature works reliably, enable it.
If you want to get fancy, you can even toggle features by user or group. You might give power users access to an incomplete feature so you can get early feedback while preventing others from accessing it. Feature toggles are a great tool. They avoid the problem of having a deployment stalled because one feature isn’t ready.
You have to get software into the hands of real users early and often. If that isn’t feasible in your situation then, at the very least, they need to see software demonstrations regularly. If they can’t see it and/or touch it, it doesn’t exist.
photo credit: Tambako the Jaguar via photopin cc