eWSJF - Using Real-World Lean Startup, Emotions, and MVPs in Product & Portfolio Decision Making
Are you “going Agile” but your executives are still asking you for Gantt charts and delivery dates? Here’s an exercise to do with them instead. Usually, they just want to know when to check back on “the project”, and whether or not their money is being well invested.
To answer the last question, many teams have discovered the “Weighted, Shortest Job First (WSJF)” method of project prioritization. Basically, if you have two items of equal effort, but one has twice the return on investment (ROI) of the other, do the one with greater ROI. And if you have two items of equal ROI, but one can be done in half the time, do the shortest job first. But that’s not enough. We all know of projects that had great promise, but customers wouldn’t pay for it.
Lean Startup has discovered that emotions are one of the best leading indicators (predictors) of future product success. Emotional-WSJF (eWSJF) balances customer demand with Minimum Viable Products (MVPs), i.e. "this only has true business value if we can deliver within 2-3 sprints."
I use eWSJF within my teams to prioritize Epics, and I’ll show you how to use it to keep your executives happy! It replaces the conversations about “Show me a Gantt chart,” and “When will this be delivered?” My executives instead ask, “Have you talked to any customers?” or “Can you build it faster?” To which my teams respond, “Yes we have talked to customers, and they’re even helping us beta test it!” and, “The next version will be delivered in two weeks, and here’s what it contains.”
Outline/Structure of the Lightning Talk
I’ll present an Excel worksheet for capturing values, and explain the purpose of each column. (I find Excel to be the fastest intro, but this can also be integrated into Jira, Aha!, Trello, and countless other applications.)
Each of the following column is assigned a numeric value according to the Fibonacci sequence, 1, 2, 3, 5, 8, 13, or 21:
- Business Value - Will this increase revenue, decrease overhead, or increase assets?
- Risk Reduction - Not only is this venture risky or not risky, but will we actual reduce our risk if we implement this feature? Higher value means higher risk reduction.
- Time Criticality - Can we do this whenever we want (value=1), or are we legally required to, and our CEO will go to jail next month if we don’t (value = 21)?
- Competitor Risk - Have any of our customers said that they will leave us if we don’t do this? If they’re upset but they’re not going anywhere it gets a 1, but if we’ll go out of business it gets a 21.
Timing-wise, I’ll introduce each of the columns above in 1-minute descriptions, and then I’ll describe the new “Emotional Customer Impact” column below, and how it is counter-balanced by the “Job Size” column. (2 minutes each.)
Emotional Customer Impact answers the question, “Have you talked to any customers about this?”
- 0 - No, we have not talked to a single customer. We just came up with this idea and discussed it internally.
- 1 - Yes, we talked to them, but they only seemed nominally interested. OR One user submitted a bug report or feature suggestion, but no other comments were made.
- 2 - Yes, and they seemed interested. They asked us a lot of questions. But no one seemed to get emotionally invested at all. OR Multiple bug reports or feature requests were submitted, but they didn’t respond when we tried to call them.
- 3 - Yes, and I could see/hear that they were upset/enthusiastic (emotional), though that emotion was largely localized to just their face. OR Someone took the time to call our help desk, instead of just submitting a bug report, and they sounded pretty emotional.
- 4 - Yes, and they were so emotional about it that their whole body was activated. OR One of our customers came to us because this has been causing them stress throughout their organization. So their CEO/VP told our CEO/VP, who is now upset that they had to hear about it from outside the organization.
In eWSJF we measure Job Size in the number of sprints.
When all numbers are filled out, then the following calculation is applied to each proposed feature.
I’ll wrap up by giving examples of how the worksheet is used with my clients. (2 minutes) We use this at prioritization meetings between multiple teams using Planning Poker cards. Product Owners from all the teams get to vote on the values, and they negotiate among themselves about whether Team X’s feature is more valuable or less valuable than Team Y’s feature. It resolves debate between teams using data, and every team can increase their score by either talking to more customers (increasing Emotional Customer Impact), or reducing Job Size by using MVPs to release a smaller version of the feature in less time.
- How to prioritize portfolio backlogs
- How to compare vastly different projects from different teams fairly using data
- How to educate your teams about their real-world impact on your Business Models
- How to encourage your teams to talk to each other using concrete data
- How to encourage your teams to talk to customers
- How to encourage your teams to design Minimum Viable Products (MVPs)
Executives, Portfolio Managers, Product Managers, and anyone who has to decide where to spend their money!
Prerequisites for Attendees
- An understanding of business value
- An understanding of risk
- An understanding of project budgeting
schedule Submitted 3 years ago
People who liked this proposal, also liked:
Bryan Miles / Darren Hoevel - Adaptive Leadership...WTF is that?Bryan MilesAgile CoachPliant SolutionsDarren HoevelAgile CoachPliant Solutions
schedule 3 years agoSold Out!
“The single biggest failure of leadership is to treat adaptive challenges like technical problems.” -Ron Heifetz
We live and work in an increasingly interconnected and rapidly changing world. New business models are shifting duties to teams instead of individuals, which means people are now working more closely together. It also means leaders at all levels have to begin to adapt their leadership style to guide the intricacies of human dynamics and channel the collective knowledge of the groups they interact with.
In this workshop we will explore how leaders create environments that navigate the complexity of interpersonal relationships, overcome the human element of barriers to change, and support the growth and engagement of their employees. Attendees will walk out of the room with a clearer idea of their own leadership style and a list of action items they can use (tomorrow!) to move their teams one step closer to higher performance.
RUSHABH SHAH / Dave Omondi / Ghazi Omar / Philip Masiewicz - Introduction to TDD (Test Driven Development): Lessons from Loan Delivery applicationRUSHABH SHAHScrum MasterFannie MaeDave Omondi--Ghazi OmarSoftware Engineer (Tech Lead)Fannie MaePhilip MasiewiczSoftware Engineering ManagerFannie Mae
schedule 3 years agoSold Out!
“Test-driven development (TDD) is a programming technique in which the tests are written prior to the source code. It is proposed that TDD is one of the most fundamental practices enabling the development of software in an agile and iterative manner. Both the literature and practice suggest that TDD practice yields several benefits. Essentially, it is claimed that TDD leads to an improved software design, which has a dramatic impact on the maintainability and further development of the system.” (Reference: ieee.org)
Fannie Mae, a government sponsored entity (GSE), is in the fourth year of it’s agile transformation. Teams use an Agile Maturity Matrix as a roadmap for optimizing their agile capabilities as well as technical engineering practices.
As long-standing teams, we have a long track record of trying to incorporate persistent TDD practices with varying degrees of success. But it was only after the LDNG teams collectively matured their agile mindset and focused on optimization, implementation of TDD took flight.
Past year, 4 teams comprising the Loan Delivery Next Gen were recognized for being the first teams in organization to complete highest agile maturity model’s category, hallmarks for which include: Feature level BDD, Test first mindset & All layers of testing are automated and executed on every check-in.
- Do you want a real world example of implementing TDD in a large program?
- Are you unable to grapple with the challenges of TDD? Is TDD frustrating you?
- What are some misconceptions about implementing TDD?
- How do you get a good ROI (Return On Investment) by developing TDD capability?
- By the way what’s the big deal about TDD? Is it really helping or just another hype??
This talk is intended for the technical members on a cross-functional team (responsible for the “how” who are faced with implementing TDD) as well as well as Scrum Masters and Product Owners who are interested in understanding the benefits of TDD and why they should be advocating for / insuring there is capacity to develop and mature these practices as part of the team’s work. Unlike most TDD training sessions, this focuses on the subtleties and challenges of implementing TDD in a pragmatic manner that address everyday concerns of a large organization.
Join us to get answers to all these questions based on our real world experience as well as see a live intuitive demo.
While we are not experts in this field (at least not yet), we will share our journey and practical learnings. How does that sound?
Our presentation shares experience of Loan Delivery teams. We will share our journey in adopting TDD along with moving away from testers in team, to training developers with test-first mindset. We will also cover misconceptions and touch a little on testing techniques for developers. We would like to cover the non-technical blind spots that most TDD trainings might miss, based on our real world experience.
Also in the spirit of Agile, we will present practical real-time example of TDD in action that addresses a number of concerns, but mainly how to re-factor code using TDD. We will use personal laptop to demonstrate a loan calculator example.
Roland Cuellar - Experience Report: Agile and Lean UX Techniques for Hardware DevelopmentRoland CuellarManagement Consulting Practice LeaderLitheSpeed LLC
schedule 4 years agoSold Out!
Experience Report: Applying Lean UX to New Hardware Development
We often hear how Agile and Lean UX techniques are applied to software development, but there is much less information available on how to use these same ideas to develop new hardware solutions.
In this experience report, Matthew Maddox, VP of Digital Strategy at Mirion Technologies and Roland Cuellar of Lithespeed will show how Lean UX techniques were successfully applied to the design of new and highly complex integrated hardware and software products.
Mirion makes complex, highly regulated equipment that is focused on radiological safety for national security, first responders, and nuclear power. Mirion’s radiation detection equipment is used to protect people from radiation exposure, secure major events, and track down illicit radiological sources. Over the past year, Mirion has been experimenting with agile and lean UX techniques to design it's next generation radiation detection hardware and software.
In this experience report, we will hear how Matthew utilized rapid, lightweight, lean UX techniques to quickly develop hardware prototypes, gather feedback from past and potential new customers, and quickly pivot initial designs based upon feedback from customers.
As a result of this important process innovation, Mirion is now embracing more modern digital and agile techniques to more quickly bring innovations to market that are more closely aligned with customer desires.
Matthew Madox is the VP of Marketing & Digital Strategy, and lead the field research, primary design and customer validation phases of the next generation Personal Radiation Detector (PRD).
Topics Include: Agile Hardware Design, Lean UX, Hardware and Software Design Integration, New Product Development, Engineering Culture Change
Arlen Bankston - Performance Management in the Age of AgilityArlen BankstonFounderLitheSpeed
schedule 4 years agoSold Out!
Agility is about adaptation, challenging the status quo, experimentation and learning. HR has historically hewed closer to compliance, but that has been changing rapidly.
Today's nimble teams and workers will no longer tolerate stifling, staid environments and management practices. The newly popular label "people operations" implies an emphasis on human engagement over bureaucracy and regulation, and indeed many organizations have been moving this way.
Be inspired by some of the most daring advances in human resources while also learning some practical approaches and techniques that can be applied to start leading your business down this path. We'll discuss new approaches in hiring, performance management, learning and development, and even the structure of HR groups and roles. Participants will also enjoy a few exercises that will illustrate some interesting techniques.
Prepare yourself for HR in the next generation.
Bob Duffy - Fannie Mae's SDLC Journey from Waterfall to AgileBob DuffyInternal Controls TechFannie Mae
schedule 4 years agoSold Out!
A well-defined Software Development Life Cycle (SDLC) is a requirement for many government institutions. However, the typical SDLC process is very "Waterfallish" by nature of it's phase gates and documentation requirements. This talk will explain how the SDLC at Fannie Mae has evolved as the company has transformed from a Waterfall to a lean Agile organization in alignment with Agile best practices.
Pete Oliver-Krueger - A Real-World Roadmap for Rolling Out Agile TransformationsPete Oliver-KruegerHolistic Agile Management ConsultantLithespeed
schedule 3 years agoSold Out!
This case study describes an actual roll-out of an Agile Transformation across 7 product lines, and 18 scrum teams in a local commercial organization. It maps out 4 levels of industry best practices, and describes what techniques worked, why some techniques failed when they were introduced, and what other techniques had to be mastered before they could be re-introduced.
We will also talk about assessment models, and give examples on how to design good metrics for each level of performance. At Level 1 we have 6 core metrics that all teams must report. When the teams start Level 2 we ask them to design their own metrics, based on their products’ business models, to show how they impact income, overhead, strategy, and risk. When teams reach level 3 they are ready to start advising executives on corporate strategy, with a track record of proven performance.
To motivate teams we’ve mixed in several elements of gamification (rather accidentally, to be honest), that inspire teams to complete their assessments, “level up”, and engage in healthy competition. But it’s also not a winner-take-all culture. We leave room for multiple teams to receive rewards and appreciation for their unique achievements across 5 different performance categories.
The design of this Agile Transformation program is based on the principles of Teal Management, drawing on techniques from DevOps, Lean Startup (R), SAFe (R), and more, and combined with practical, real-world techniques, honed over years of practice. (You do not, however, have to be a “Teal” organization to use this model. Rather, this program is a map of “the road to Teal”. And while Teal Management will be referenced in this case study, it will not be talked about in depth.)
An Agile Transformation is very difficult. We found that each team needs to travel at its own speed, and one size does not fit all. This case study is how we make that happen, show appreciate for the uniqueness of each team, and ensure consistent, measurable, overall success.
Pete Oliver-Krueger - Agility in Software Architectures through PI (Property-Invocation) ProgrammingPete Oliver-KruegerHolistic Agile Management ConsultantLithespeed
schedule 3 years agoSold Out!
Your team process is getting Agile, but is your code Agile? How long does it take you to add a new feature? How about a logger that listens to every object in your application? For me it’s a just a few lines of code.
After designing software for over a decade for the DOD, the FDA, NASA, the DC Metro, multiple startups, and more, I discovered the architecture that made me truly Agile, and it became the foundation for my next decade of work. It was designed through what I call “looking back at the present from the future,” which is a long-winded way to say that it was designed around what would make an application easier to maintain, since on average 85% of the cost of any application is during its maintenance phase. Turns out this makes it easier to build applications from scratch too!
Property-Invocation Programming is like Story Splitting in code form. Each step of your workflow is encapsulated in a function, and the init() function for your object shows a map of how all those pieces come together, and in which order. With this map, you can have multiple developers working on the same object, and even the same file, without merge conflicts. Integration testing is just a matter of executing your functions in the correct order. And a year from now, when your Product Owner needs changes, but you’ve forgotten what you wrote, it’s all mapped out neatly in your init() function. No hunting for code. Just read what you wrote, add new functions, and insert them in the right order.
In this session I’ll show you the four simple rules at the heart of Property-Invocation Programming, and how to leverage them to create truly Agile software architectures. We’ll also look at how to build a new cross-platform (mobile and desktop) application from scratch that can handle anything your Product Owners throw at it. Plus I'll walk through the 5 Pillars of Modern Application Architecture that I used with my teams.