As a user story
I want people to understand what my purpose is
So that I cease to be a tool for ineffective agile development
This format "As a... I want... In order to..." is called the "Connextra format" named after the company where it originated. It was created to solve a very specific problem.
The original intent of what was once called simply "stories" was to elucidate what was to be built in a manner more lightweight and consumable than a requirements doc. When people at Connextra discovered that stories were simply becoming the new specification and lacked any insight into the purpose being fulfilled for the user they tacked on "user" to the front of the thing. Thus the concept of the User Story was born.
I don't think the Connextra format is a bad idea. I think mistaking the Connextra format for an actual user story is a common anti-pattern and leads to some painful misunderstandings.
As a hard drive
I want better indexing
So that my platters don't hurt so much at the end of the day
The hard drive is not a person and using a story to anthropomorphize some part of a system in order to continue focusing on technical implementation details is the most common anti-pattern
Read the rest of the article here
"I have abandoned MVP"
After years of struggle, I’m advising all of my clients and product leader coachees to stop using the term “MVP”. Not to stop doing validation, discovery, prototyping or experiments they may associate that that acronym, but to remove the label from all of their docs and presentations and talks. To delete the letters MVP from roadmaps and product charters. To banish it from their vocabularies, not let it cross their lips
The maker organizations refer back to Eric Ries (and much earlier) for MVP definitions like “any offering or capability that requires the least effort to build while giving the organization the greatest ability to learn about customers.” Critically, this might be a text description or Balsamiq sketch or non-working web prototype or flipbook that gives us a chance to show an outsider what we mean. It’s not intended for sale or revenue, but for rapid learning. The ‘P’ nominally stands for ‘product,’ but it’s almost always not a product.
The go-to-market organizations really want something to market and sell. So in spite of our long-winded academic arguments, they focus on the word ‘product.’ In fact, the most frequent definition I get from GTM execs is “something I can sell right now to selected customers for current revenue, instead of waiting another few quarters for a perfect product.” And within minutes, this is shortened to “something I can sell right now.” Everyone is excited about pitching (and closing) live customers, even if we only have only mocked-up slideware so far.
What To Do?
This is often more than just a vocabulary problem. But we can reduce confusion/frustration by choosing unambiguous words with clear meanings. Here is one set of replacements:
“Problem validation” or “Concept test” (NON-REVENUE)
- Tools might be Jobs To Be Done, canvasses, journey maps, paper prototypes, hero stories, what-you-bought-instead interviews
- Goal: understanding if we identified the right root problem. Can we learn what’s really broken and test-close a few imaginary solutions? How excited are potential prospects?
“Conceptual workflow” or “UX test” (NON-REVENUE)
- Assets might include mocks or flipbooks or clickable web interfaces with no internal logic
- Goal: See if sample users can complete a task. What inputs are we missing? Have we named things correctly? Does workflow A or layout B test better?
“Engineering concept validation” (NON-REVENUE)
- Might include sample data run through partial algorithms or scalability tests or “hello world” code for API integration
- Goal/questions: will X work? Does it blow up our cloud servers? Can we find actionable signals in the data? Is our architecture sensible? Do early technical trials change our scope or identify missing capabilities?
Read the original article here
Recently I had an opportunity to have a video podcast(campfire chat) with TameFlow community.. We discussed about LeSS and TameFlow
Check out this link
Snippets from Richard Hackman's "Leading Teams"This book is one of the recommended books to read as part of the LeSS trainer certification. Thought would share some good snippets.
“Real work teams in organizations have four features: a team task, clear boundaries, clearly specified authority to manage their own work processes, and membership stability over some reasonable period of time. The first and perhaps most important task of those who create or lead work teams is to make sure that these four essential features are in place.”
“The first group I encountered in my research career was in the central office of a telephone company. My colleague Ed Lawler and I were being shown around the company in preparation for some research we were planning. One group we visited was introduced to us as “Supervisor Szczarba’s team.” Arrayed before us were a dozen or so telephone operators, each at her own console (there were no men in the group), each talking to her own customers, each taking her break at a time negotiated with Ms. Szczarba. Members of the group did perform their work alongside one another. But the only thing they actually shared was Ms. Szczarba.
I have conducted several online training for Certified LeSS Basics and Provisional Certified LeSS Practitioner till date. I recently completed a few and would be announcing a few more soon. Keep an eye on this newsletter.
Many might not know that I also offer Certified LeSS Executive training. This is specifically for senior leaders who might be interested in learning the intricacies of management and structure to influence the culture.
Please reach out: venky at agileworld.com.au for further details.
About Empirical Coach
If you are interested in Agile coaching, mentoring and training services, please reach out to me (email@example.com). We have a team of passionate coaches collaboratively working together and could help.
Our team has deep expertise in Agile, Lean, Systems Thinking and Complexity science. We look at challenges from different angles and apply tools from various schools of thoughts. This is different from the cookie-cutter approaches you see around. We are proud to be different.
I have been deeply involved in many of the initial experiments that lead to the birth of LeSS, one of the countable number of people globally.