I’ve been using this spreadsheet to ease the WSJF calculation, facilitating collaborative workshops with that.
Reach: how many people will this impact? (Estimate within a defined time period.)
Impact: how much will this impact each person? (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.)
Confidence: how confident are you in your estimates? (High = 100%, Medium = 80%, Low = 50%.)
Effort: how many “person-months” will this take? (Use whole numbers and minimum of half a month – don’t get into the weeds of estimation.)
Lean Inception is a method to build a product focusing on Minimum Viable Products. MVPs like Lean Startup. It can help small or large organisations to realise what’s the priority to build next. It addresses a week-planned agenda with Product Development and UX techniques like Elevator Pitch, Personas, User Journeys, Brainstorming and Sequencing of Features, and the Canvas MVP, the proper result of a Lean Inception.
It was developed by the easygoing-geek genius Paulo Caroli from need. With his newborn son in 2011, it was virtually impossible to balance work and family running an old-fashioned Inception for weeks. More constrains, more creativity. Lean Inception was created to accomplish a product inception in a week.
A facilitator leads the process. Key business and product people do a kick-off presentation in the beginning about what shall be about the product, and for who. The team attends the entire 5 days agenda, presenting the results to those interested in the MVP(s).
However, even Lean Inception is a method, it’s not just about to build the next MVPs. As Dwight D. Eisenhower said “Plans are worthless, but planning is everything”. A perfect MVP planned is worthless without people engagement.
Lean Inception is about making people awesome, engaging them to build an awesome product.
Awesome because they are part of the process, part of the product. They feel like owners of the product, because they helped to decide what to build. Even business knows what to build and UX decided for who, it’s very important encouraging the team develop the product too, doing the Elevator Pitch and sketching Personas.
Right after I woked up today, I read this Dan North’s tweet:
Trunk-based development makes the development teams integrate and test on a single code, which is the trunk (or master in Git). It is the base for Continuous Integration and Continuous Delivery. This approach brings software releases early, reducing time to market. At the extreme, Lean Startups.
Two weeks ago I was coaching an agile team for the first time, they use feature branches, having a slow cadence of deliveries. They are working on a single product with other three teams in their organization, plus other three organizations. In this case, code integration is a mess and its code is fragile. After a short time, business cannot have fast time to market anymore.
So what is missing?
It is virtually impossible having trunk-based development without test automation. When you need to integrated code, you need to test the feature and every thing related. So doing it manually is insanity. Manual testing can be easy in the beginning, but the software becomes more and more complex. You need test automation.
First of all, your team have to understand the need of test automation. Secondly, they have to learn and practice test automation. Why not try coding dojos or mob programming?
Based on the Redundancy principle of eXtreme Programming, your team can automate tests on critical features, difficult problems, so it can be approached in many ways. Developers focus on unit and integration code mostly, even functional tests. Testers automate functional and many other types of tests. They help each other. There is no right division on that.
Keep something in your mind: “Legacy code is simply code without tests” by Michael Feathers. So every code you commit without tests, it is legacy code.
So cheers for good practices on software development…