Hands-on Agile Webinar #3: Product Backlog Anti-Patterns
•Download as PPTX, PDF•
2 likes•3,247 views
The third Hands-on Agile webinar product addresses backlog anti-patterns — from out-dated and oversized tickets to the part-time proxy product owner and his or her idea repository. Learn more about the numerous product backlog anti-patterns that can manifest themselves when you try to create value for your customers and your organization. BLOG: https://age-of-product.com/webinar-product-backlog/ YOUTUBE: https://www.youtube.com/watch?v=fCE1PmtbGXQ
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Similar to Hands-on Agile Webinar #3: Product Backlog Anti-Patterns
Similar to Hands-on Agile Webinar #3: Product Backlog Anti-Patterns (20)
More from Stefan Wolpers
More from Stefan Wolpers (20)
Recently uploaded
Recently uploaded (20)
Hands-on Agile Webinar #3: Product Backlog Anti-Patterns
- 2. About Stefan Wolpers Agile Coach, Scrum Master, and Product Owner since 2006: stefan@age-of-product.com
- 24. stefan@age-of-product.com Flanking Maneuvers by Stakeholders: • HIPPO-ism • Brute-force • Have daddy fix it • Bribery • Creating tickets directly • Dispatcher mode • Labeling feature requests as bugs
- 27. Contact Information Stefan Wolpers Email: stefan@age-of-product.com Blog: Age-of-Product.com Newsletter: https://age-of-product.com/subscribe (Join 17,000 peers) Slack: https://hands-onagile.slack.com/ (Join 3,200 peers) Twitter 1: @StefanW Twitter 2: @AgeOfProduct
- 37. Psychological Issues (Tricked by Your Brain) stefan@age-of-product.com
Editor's Notes
- Welcome to the 3. hands-on agile webinar on product discovery anti-patterns I am your host, Stefan Wolpers Some housekeeping: The webinar will take about 25 minutes which will leave enough room for Q&A at the end
- Some background on myself: I have spent 12-plus years in agile Mostly as a product owner in fast growing, vc-funded startups in Berlin (including a later Google subsidiary) At the moment, I am working as an agile coach/scrum master for a large European electricity and gas provider I am also a steward for the Xscale Alliance in Germany
- holistic perspective on "agile product development" my mental model of how agile works: You start with a vision on the left side And you end up with delivering code continuously to a resilient system on the right side
- I label the left side “product discovery” And the right side “product delivery” Of course, the separation is not as strict; both parts are overlapping somewhere in the “near term planning” era. (In scrum speak it is usual the product backlog)
- Product discovery tends to be much more affordable and low tech on the left side, And much more expensive the further you move to the right side It is literally comparing “a napkin” to a “a full-blown continuous delivery pipeline shipping code"
- From a risk mitigation point of view, the further to the left side any product discovery activities happen, the more affordable they become.
- Product backlog is the last line of defense Make or break: team = internal agency or go-to people to solve people? Don’t become a feature factory
- From near-term planning to short-term planning — a continuous process
- A product backlog is not a monolith Best use of available resources at any given time => living thing Weekly refinement B2B or B2C Releases or CD? Stage of product life-cycle?
- PO: Achilles heel of Scrum LeSS: ONE product owner No Product design by committee => feature factory Stage-gate through the backdoor Nice waterfall 2.0
- Token 4 discussion: co-creation, discussion, shared understanding Backlogs = forensic analysis tool for organizational debt User story ≠ jira-based requirement document Make issues in Jira fit to BE DELETED Counter argument: required by Governance / documentation
- Old ticket = Waste
- Do not dump ideas in the product backlog No more than 4-8 maybe 12 weeks worth of work. Delete the rest Objection: We cannot delete them — it is our documentation #LossAversion we put in a lot of work… #SunkCosts
- PO w/o doubt where to go Does not need the team — collaboration only slows him/her down Provides the “Why + How + What” at the same time (=> not uncommon for former engineers who became PO) Dominant PO w/ submissive team = bad combination (checks and balances gone)
- Delivering artefacts Use stories by copying paragraphs from a document? Collaborative creation: Independent Negotiable Valuable Estimated Small Testable
- Minimizing workload? YES Let the team work Let the team write user stories Let the team interview users
- No alignment w/ roadmap, strategy or vision Being “busy” ≠ providing value to customers & the organization OUTCOME, not output Sloppy work is expensive!
- Overlapping w/ sprint planning Where to put NFRs and bugs? => transparency No maintenance, No refactoring? => feature factory — but a lousy one
- “Definiton of Ready” helpful => set a standard Dont overdo “PO vs. DEVs” game: • Haggling YES • Stalemate NO => You are wearing the same jersey DoR not a stage-gate => anti-pattern
- From near-term planning to short-term planning — a continuous process
- In 2 weeks: agile failure patterns In 4 weeks: sprint planning anti-patterns,
- From near-term planning to short-term planning — a continuous process
- Think Jira monkeys & coders, and treating the product department as an internal agency — the “we pay you” approach. This anti-pattern often occurs in organizations that supported the shareholder value-approach of the 1990; outsourcing non-essential tasks such as software development. (Too bad, that software is eating the world now…) This anti-pattern leads often to Conway’s law: you are shipping the org-chart, as its communications structures are incorporated into your product This results typically in local optimization efforts within a silo-ed organization
- Speaking of silos: Siloes, for example, marketing or sales, insist on channeling communication with customer and users. So, the sales people prevent “product” from talking directly with customers which makes user interview, user research very problematic, particularly in the B2B sector. This inevitably leads to a massive loss of information and context as the silo is operating under a different mental model than product.
- Engineers are supposed to deliver “code.” They are not supposed to talk to customers or take over customer support duties to get the first-hand experience of customer problems. That is pure Taylorism at work, entirely output oriented. The problem is, we are no longer assembling Model-Ts. But we go every day, where no one has ever gone before. Rule of thumb: Coding is less than 30% of the whole effort — the best way to increase productivity of the product team is to avoid building unnecessary stuff
- Okay, let’s not assume a victim role and have a look in our backyard: There is one issue that regularly triggers frustration on the side of the stakeholders: "Product" is not transparent about how they work, how a suggestion/ idea/requirement can make it into a sprint. =>this black box approach reduces stakeholders’ willingness to collaborate across the board, impeding product discovery.
- Politics and personal agendas do not require any introduction, I assume.
- Pet projects are often stakeholder driven. However, they do not exclusively apply to the middle management. Think of gold-plating as an engineering approach. Or why an exotic new technology suddenly becomes a part of the tech stack. A root cause analysis will probably point to the “What is in for me?” syndrome. It could be, for example, a CV optimization effort for the next career step. Or the person in question built something, he or she is proud of — which hence more valuable to them (that’s the IKEA effect) Pet projects are always driven by personal intent. And the resulting high personal investments can lead to the blame game, death marches & other face-saving techniques at the expense of product discovery.
- The famous quote of Jim Barksdale of Netscape: If we have data, let’s go with the data. If all we have are opinions, let’s go with mine. However, there is no scientific proof that the pay grade of an individual is linked to his or her ability to identify what's worth building. Innovation is nowadays a team sport; the lonesome innovator is a myth. Yet, submission to the will of one with the higher status is often common. (Except for Google, maybe.)
- Bonus at risk – the misalignment between individual incentives and team objective: Shortly before the end to of the bonus period the product team gets swamped with “must have” requirements from sales. Typical manifestations are: Selling specific features that close a contract without talking to product. A ,more desperate attempt: Making assumptions that certain new features will bring new business. (throw something at the wall and see what sticks.)
- The last category is the fun category as it opens the field of cognitive science or how we like to trick ourselves into believing something.
- The Sunk Cost Fallacy: We believe that we make rational decisions. In fact, we are often only rationalizing them afterwards. One mind trick is the sunk cost fallacy: here, our aversion loss – gee, we already invested so much — overrides the rational decision, for example, cut losses. I do not know whether you are also tuning in to the soap opera callee “Berlin’s new airport” from time to time, However, it is a good example for the sunk cost fallacy. Planned from 1991 on, construction started in 2006, and 2011 was the supposed grand opening. Did not work due massive violations of safety standards. Kahnemann: “Thinking, fast and slow.” Dan Ariely “Predictably Irrational”
- Intro Kahnemann system 1: The difficult question that require reflection and analysis is substituted by a simpler one you can ask immediately. Kahnemann: “Who is your life nowadays” is substituted by “How is your mood today?” People are not simply “loving their solution” to problem. They also believe that they are answering the right question. Hence their engagement…
- The Self-fulfilling Prophecy is closely related to the “I know what we have to build” issue we just talked about With the best intentions, you want to validate your hypothesis or solution — you are data-driven, right? However, your confirmation bias lets you unconsciously pick the a design that will deliver the data to ”confirm” your solution — by a self-fulfilling prophecy. That has happened twice to me over the years: as a chemistry student in the labs — at least that resulted in a good discussion with my professor of organic chemistry at the time — and then there was Ebookmakr, a failed application to create ebooks online. (We “picked” the wrong participants for the user-tests.)
- Wikipedia: Survivorship bias or survival bias is the logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility.
- Wikipedia: Survivorship bias or survival bias is the logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility.
- Building the product mainly based on data & insight from ”paying” customers
- Steve Jobs once said: “It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them.” Psychologists called this effect psychological distance—that is, gaps between yourself and other people (social distance), the present and the future (temporal distance), your physical location and faraway places (spatial distance), or imagining something and experiencing it (experiential distance): Asking users what they need is often overburdening them — they will probably have no clue. And even if there is a problem they will most likely not find the right way of framing it. (Remember the old saying: if your only tool is a hammer, every problem looks like a nail?) At the same time, people want to be helpful — reciprocity is deeply embedded in our social DNA. So, if you ask users what they need they will provide an answer. Be cautious, though, only money talks. Alternatively, observe how your customers work. If you show prototypes, use wireframes, not polished designs.