The Greatest Product Ever Built
When you live in a wonderland
Once upon a time, there was a need… The need to build the greatest digital product the world has ever seen. One product that would revolutionize the market, creating new trends and opening disruptive ways for doing business. A product built by the greatest team walking down the Earth, using the most efficient framework ever defined: Scrum.
“Why?”, “What?”, “When?”, “Who?” are questions that don’t need research. The market-fit is clear; the end-users identified upfront, the stakeholders listed and converging, the monetization strategy is a gold mine waiting to be put into practice. There‘s no way such an endeavor could not build the right thing...
Product Discovery? A side note. Unclear initiatives need alignment and research to refine, prioritize and understand the “problem” space. But not this team and their product. The problem statement is so clear that they spend all their efforts in the “solution” space.
Prototyping? “Why putting effort into simulations when we can deliver the real thing?”, the team thinks. Prototyping is great when you want to save development investment upfront by delivering a product’s draft, so stakeholders and end-users provide feedback before getting the final version. But here, all parties know exactly what they want, providing requirements in a clear and detailed way, which reduces to zero the risk of rework.
Minimum Viable Product? What “Minimum” and “Viable” exactly stand for…? The team does not cope well with such concepts: “If we do it, we do it all the way through!” they think. Such a concept may be great with early adopters who need hypotheses over different models, but why bringing an incomplete product to life only to wait for feedback on something they already know how to proceed with?
Team level? No forming, storming and norming bullshit. The team lives and breeds in the last stage: performing. All team members are proficient, autonomous, influential, with great hard & soft skills. They require minimum to no training because they are all amazing self-learners. Another great treat is their elasticity: all of them are ‘full-stack’, in the tech-stack and the mindset. All Developers cope well with business analysis, quality assurance, architecture, and infrastructure tasks. They actively acquire and share knowledge between them, and they know exactly what each team member is working on at a given moment, facilitating rotation on topics. Usually, there’s no opinion backlash since they are perfectly aligned. Every single day, they’re pumped up with sky-rocket motivation.
Process adoption? A walk in the park. Since Scrum is easy to apply & master, the team can:
- Be the personification of the Scrum values. All members focus & commit to reach the sprint goals with enough courage to do the right thing. They also foster a culture of respect and openness with full transparency while providing feedback.
- Run time-boxed, inclusive and valuable Ceremonies. All parties provide timely, assertive, and respectful inputs; create conditions for every voice to be heard, and no session ends without proper outcomes and follow-up actions. All ceremonies serve a purpose that is understood by all.
- Refine backlog items with little to no effort since all team members know the business & tech extensively. Usually, zero discussion around estimations since the teams know the drill and convergence on story points.
- Create amazingly well-written User Stories. All team members actively contribute to story writing, not only the Product Owner. They apply the “AS A… I WANT… SO THAT” template, and with I.N.V.E.S.T. principles in mind. And the good part? They are effectively user… stories. No “As a Product Owner I want…” nonsense.
- Produce spot-on Acceptance Criteria. The team is proud of using a behavior-driven development approach, which produces beautifully designed criteria, with “GIVEN…WHEN…THEN” templates.
- Craft perfect Sprint Goals. After amazingly well-done refinements and prioritization sessions, all PBIs (Product Backlog Items) are clear, understood by all, properly evaluated, and immutable. Why immutable? Because all stakeholders know exactly what they want and by when. Their level of clarity makes everyone’s job a lot easier, avoid the suffering of pivoting decisions or (God forbid!) changing the scope while the sprint is running. So when the time comes, the team knows exactly which goals will guide them to the outcome.
- Definition of Ready? “Does it crosses anyone’s mind to have a Sprint Planning with a PBI not respecting the Definition of Ready? God forbid!” All PBIs are clear, testable, and feasible before entering Sprint's scope, avoiding never-ending back-and-forth discussions and possible rework.
- Definition of Done? A consequence of doing things right. All sprint PBIs have their code produced, commented, built, merged, tested, reviewed, and deployed. All increments receive stakeholders’ green light since they perfectly deliver the solution to the defined problem.
- Increment. By the end of the sprint, all goals are achieved. Consequently, the produced increment is potentially shippable due to a strict “Definition of Done”. All dependencies (business and technical) are properly sorted out by clearing any constraint that would affect the rollout strategy.
DevOps philosophy? The team excels at it. They have strong principles to build, test, release and monitor their software delivery pipeline. They truly believe in automated processes, looking for engineering excellence in everything they do. We are talking about a new breed of engineers with a clear sense of ownership: “you build it, you own it”. All sprint work is planned with proper buffers to address not only new features but also production incidents. No deviation exists since the sprint scope doesn’t change.
Improvements? a mythological concept, in the team’s eyes. Often feedback is provided but only as an appraisal round. From stakeholders to end-users, from team members to 3rd parties, everyone agrees the team is doing an outstanding job.
It would’ve been great if all of the software engineering initiatives worked like this, right…?
