Simplicity comes from design patterns, reuse, and focus. User interfaces need to be easily understood. Our brains understand patterns; color schemes, design elements, navigation, messages, interoperability of core functions. Reuse simplifies construction, testing, and ongoing maintenance of the application. Focus requires a disciplined approach to prioritize the top features that deliver the highest value.

So what goes wrong?
Complexity comes from trying to do everything. Too many features implemented too quickly. Or features that provide little value. It comes from overly thinking use cases and boundary conditions instead of making things work for the 80% majority. It comes from customizations. It comes from designing intricate tightly controlled workflows. It comes from designing or developing things without consideration of standards or by developing standards when needed. It comes when quality and acceptance criteria isn’t well defined. It comes from deviations in process.

Why things go wrong
There are six key people that need to be on the same page in product development. The Product Owner truly must articulate priorities and a minimal feature set to drive value. The Designer must understand or establish repeatable design elements and user interface components. The Business Analyst has to flush out requirements and drive them to patterns. The Technical Lead needs to consult on feasibility, discuss estimates, and define the application architecture. The Quality Assurance Analyst must comprehend the full scope to help define the testing approach. These five individuals often benefit from a sixth, the Project Manager, who orchestrates this conversation and has the role to drive the team to a shared understanding of the priorities, feasibility, and approach. The Project Manager needs a point of escalation if he/she believes the team isn’t closing in on a shared understanding.

Things go wrong when this team is not in balance. The Product Owner may not be prioritizing (e.g. asking for everything) or sharing the rationale (e.g. the business value) behind priorities. The Designer may have conceptualized a full scoped user experience and can’t easily scale back based on shifting priorities. The Business Analyst may not see the big picture and isn’t help the Technical Lead to propose design patterns. The QA Analyst may have trouble keeping up with the sprint’s pace. The Project Manager may be having trouble getting the team together or asking questions based on all the activity.

Making this work
These six individuals need to meet regularly. More than once/sprint. For a 2-week sprint, I would recommend as frequent as four times. They must ask questions and challenge assumptions. When the team reaches a shared understanding, then they can meet less frequently. User stories and other documentation is the byproduct of these sessions.

The team has to review the state of the product and the state of the backlog, prioritize stores, and discuss at a high level aspects of these stories. If there is an ongoing UAT (User Acceptance Testing) or Beta process, this team should review feedback. The team should also review completed stories. Are the acceptance criteria correct and sufficient? Does the estimate look accurate? Are dependencies properly accounted for in other stories?

The Simple Product

The simple product is achieved when these team members are in sync on this “simple” strategy. Target simple features that have high business value. Use “simple” as a guiding principal when considering user experience, functionality, and application architecture. Use “simple” as an  uber test for completed functionality. Keep it simple.