1. IoT is f*#%ing awesome! Like a boss...

2. Agile Experiences
from the trenches
Telekom SmartHome
Patrick Sauerwein
@Virtual_Patrick #DBART
https://www.virtualpatrick.com

3. Disclaimer
Subject period March 2017 till January 2020; product available since 2013
New organisation since February 2020
Product Owner’s view; biased personal view; incomplete

4. The customer view about the product

5. Complex team & deployment architecture

6. Spotify adapted: “lipstick on the pig” model

7. Individual agile development process
http://www.development8.de/

8. DTAG 5 level hierarchies and mixed legal
orgs
Division
Technology &
InnovationVorstand
Technology &
Innovation
(VTI)
Deutsche
Telekom AG
Telekom
Deutschland
GmbH (TDG)
Manager
Consumer IoT
H
e
r
e

9. Conway’s Law
Organising your product and value streams matters
and is reflected in Conway’s law:
“…organizations which design
systems … are constrained to
produce designs which are
copies of the communication
structures of these
organizations.”
M. Conway
(https://sites.google.com/a/scrumplop.org/published-
patterns/product-organization-pattern-language/conway-s-law)

10. Larman's Laws of Organizational Behavior
1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-
level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading
the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”,
“revolutionary”, "religion", and “needing pragmatic customization for local concerns” —
which deflects from addressing weaknesses and manager/specialist status quo.
4. As a corollary to (1), if after changing the change some managers and single-specialists
are still displaced, they become “coaches/trainers” for the change, frequently reinforcing
(2) and (3).
5. Culture follows structure.
https://craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

11. Try system thinking - WIP it real good
Count the hops between the
team and ...
- users
- customers
- support/success
- sales & marketing
- each other (inc. design & test)
- the budget
- data & insights
- strategy/why
- deployment into prod
- prod-like env
- hiring (new teammates)
- tools
You'll learn a ton.
“A bad system will beat a good person every time.”
– W. Edwards Deming

12. The nudge: product teams and thinking
https://amplitude.com/blog/journey-to-product-teams-infographic

13. Delivery vs feature vs product teams
Delivery teams are not cross-functional (basically just developers plus a backlog
administrator product owner), they are not focused on outcome (they are all about
output), and they are not empowered (they are there to code and ship).
Feature teams usually are cross-functional (at least some form of designer and some
form of product manager), but they are still all about output and not empowered.
Product teams are cross-functional, focused and measured by outcome, and
empowered to come up with solutions that work.

14. Product Team Empowerment
Why don’t more companies empower their teams?
In a word:
TRUST.
- Marty Cagan

15. “People are allowed to do their thing.”
https://twitter.com/johncutlefish/status/975026422002589701?s=20

16. Alignment & autonomy
https://twitter.com/cagan/status/1232018036531638272?s=20
https://spotifylabscom.files.wordpress.com/2014/03/spotify-engineering-culture-part1.jpeg

17. Team mandates & scope

18. 12 Signs You’re Working in a Feature Factory
● No measurement.
● Rapid shuffling of teams and projects (aka Team Tetris)
● Success theater around “shipping” with little discussion
about impact.
● Infrequent (acknowledged) failures and scrapped work.
● No connection to core metrics.
● No PM retrospectives.
● Obsessing about prioritization.
● No tweaking.
● Large batches.
● Chasing upfront revenue.
● Shiny objects
https://amplitude.com/blog/12-signs-youre-working-in-a-feature-factory-3-years-later

19. Tetris mindset: fetishizing busyness & output
Focus on
innovation/
value delivery
Focus on
predictability/
plan fulfillment

20. Pandora’s box of prioritization: roadmap violation & overcommitment
A roadmap IS NOT
● a project or release plan
● a list with dates and features
A roadmap IS
● a strategic communication tool
● a prototype of your product strategy
● state of intend and direction
● how you will realize your product vision

21. The revenge of the PMO - obsession with (ill-)planning

22. Roadmap vs project plan
https://www.mindtheproduct.com/roadmaps-are-dead-long-live-roadmaps-by-c-todd-lombardo/

23. Impact with product team empowerment
https://amplitude.com/blog/journey-to-product-teams-infographic

24. Output over outcome?
Product delivery
Building it.
Goal: Ship fast!
● Annually
● Quarterly
● Monthly
● Weekly
● Daily
● Continuous Integration
Product discovery
Deciding what to build.
Goal: Learn fast.
● Are we meeting stakeholder needs?
● Can customers use it?
● Do customers want our solution?
● Are we solving a problem the customer
cares about?
● Are we driving a desired outcome?

25. XP: Manage Your Goals Instead of Activities
Less of... More of ...
http://www.agile-process.org/byfeature.html

26. An Iterative Waterfall Isn’t Agile - #BDUF
https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile
Engineering gets brought in way too late!

27. Successful products balance many concerns

28. Plan driven vs agile convergence

29. Dual track development
https://www.jpattonassociates.com/dual-track-development/
“To set your expectations,
strong teams normally test
many product ideas each
week—on the order of 10 to 20
or more per week.”
- Marty Cagan (Inspired)

30. Product discovery

31. Product discovery

32. Opportunity decision tree

33. TL;DR: embrace change

34. Danke!
Eure Fragen & Feedback?
@Virtual_Patrick
https://www.virtualpatrick.com
#DBART