@johncutlefish's Threads
a quick thread about "sprints" (and #agile)
1) frequent integration (of ideas, code, expectations, perspectives, data, etc.) makes absolute sense. It works. There is an optimal tempo, and that point is lower than we intuit most of the time...
1) frequent integration (of ideas, code, expectations, perspectives, data, etc.) makes absolute sense. It works. There is an optimal tempo, and that point is lower than we intuit most of the time...
2) frequent integration will also, defacto, feel a little uncomfortable ... because *by design* it will expose disconfirming information, and will always feel a bit premature. Forcing functions are designed to make us pay attention... 
3) we have to contend with a limiter...and that is our ability to actually make use of/process the information that the forcing function elicits. A long time-box will yield so much information, that it will be difficult to make full use of the information
A quick story...
I worked at a company that pointed to a “big successful project” as a shiny example of “how to do things”. When any effort was going badly, you’d hear about Project X. “Why can’t we do it like that?” So... (1/3)
I worked at a company that pointed to a “big successful project” as a shiny example of “how to do things”. When any effort was going badly, you’d hear about Project X. “Why can’t we do it like that?” So... (1/3)
I started to dig a bit. Why did it work so well? 1) They held a 20p standup every morning, 2) They had teams of project managers to keep communication flowing, 3) The C-suite attended the meeting and made decisions on the spot, and...(2/3)
4) everyone involved knew this was the “single most important thing for the company”. Clear the decks!
The interesting thing was no one put 2 and 2 together. They assumed it was brilliance vs. basic focus. (3/3)
The interesting thing was no one put 2 and 2 together. They assumed it was brilliance vs. basic focus. (3/3)
What is the "operating system" for continuous improvement in your org?
By that I mean....interventions aside, who participates, how are opportunities explored/prioritized, rituals?, artifacts?, who "runs" the interventions, etc. ?
Here's what's on my mind.... (1/5)
By that I mean....interventions aside, who participates, how are opportunities explored/prioritized, rituals?, artifacts?, who "runs" the interventions, etc. ?
Here's what's on my mind.... (1/5)
Consider two orgs:
1) Feedback goes to managers. Managers address. Escalate if required. Managers "own" trying to fix impediments & generally protect teams
2) Team meets quarterly for large-scale retro, prioritizes areas for improvements, forms small work-groups
Well...(2/5)
1) Feedback goes to managers. Managers address. Escalate if required. Managers "own" trying to fix impediments & generally protect teams
2) Team meets quarterly for large-scale retro, prioritizes areas for improvements, forms small work-groups
Well...(2/5)
The reality is that there are "healthy" versions of both organizations. What is important is that they actually take it seriously. They care. There's a not-so-buggy OS on which to run "interventions".
It's like individuals....there are many ways to "be healthy"... (3/5)
It's like individuals....there are many ways to "be healthy"... (3/5)
[Thread] This is a super basic hybrid #kanban board. The basic idea is that we prioritize opportunities to tackle, pull the topmost opportunity, and then run experiments to "intervene" and generate an outcome. (1/11) #prodmgmt #kanban
Not “rules” by any means...but tendencies
1/10. We underestimate the amount of work we actually have in progress and the impact on flow, quality, value delivered...and overestimate the value of parallelizing work #proddev #kanban #flow
1/10. We underestimate the amount of work we actually have in progress and the impact on flow, quality, value delivered...and overestimate the value of parallelizing work #proddev #kanban #flow
Limiting Beliefs...
1) to upskill we need to hire externally vs. train internally
2) we’ll fail at X because we failed at X once before
3) we can’t innovate internally
4) [some group] can’t handle transparency
5) we can’t afford “good” developers/designers
(1/5) #teams
1) to upskill we need to hire externally vs. train internally
2) we’ll fail at X because we failed at X once before
3) we can’t innovate internally
4) [some group] can’t handle transparency
5) we can’t afford “good” developers/designers
(1/5) #teams
6) the team needs to start with training wheels
7) the best people have already left
8) we can’t prioritize w/o a solution in mind
9) they’re not management/leadership “material”
10) I need to do it myself for it to be done right
(2/5) #teams #limitingbeliefs
7) the best people have already left
8) we can’t prioritize w/o a solution in mind
9) they’re not management/leadership “material”
10) I need to do it myself for it to be done right
(2/5) #teams #limitingbeliefs
11) there’s no way we can all work together on that
12) this is too rough to show a user/customer
13) w/o supervision, they’ll just slack off
14) w/o a strict process, chaos will ensue
15) this decision is too high stakes to involve the team
(3/5) #teams #limitingbeliefs
12) this is too rough to show a user/customer
13) w/o supervision, they’ll just slack off
14) w/o a strict process, chaos will ensue
15) this decision is too high stakes to involve the team
(3/5) #teams #limitingbeliefs
Book recommendation ...
A book published 20+ years ago to show a young person that what’s old is new again (or that our present problems aren’t all that unique or new)
Go...
A book published 20+ years ago to show a young person that what’s old is new again (or that our present problems aren’t all that unique or new)
Go...
Must be something in the air...so...OKRs (thread)
If an org has a coherent model for value creation, a way to address uncertainty & assumptions, an actual strategy, and all of that has been communicated/processed...then OKRs are easy/an afterthought (1/4)
#prodmgmt #ux #design
If an org has a coherent model for value creation, a way to address uncertainty & assumptions, an actual strategy, and all of that has been communicated/processed...then OKRs are easy/an afterthought (1/4)
#prodmgmt #ux #design
The problem is when OKRs become “the thing”....overloaded to try to do all of the jobs above and more (performance management, even). They are not fit-for-purpose for these jobs, and pretending that they are can be damaging to the team. (2/4)
A big problem is uncertainty. I can give you an OKR for carrying bricks across my parking lot. Or increasing avg shopping cart $ size.
Many prod dev efforts aren’t that neat and tidy. OKRs are context-less. There’s not a one-pager attached to an OKR (most of the time) (3/4)
Many prod dev efforts aren’t that neat and tidy. OKRs are context-less. There’s not a one-pager attached to an OKR (most of the time) (3/4)
Here is a little thread on words. Words matter. By using slightly different words, you can nudge your organization in a new direction (assuming they take hold).
Take something subtle like replacing "project" with "mission". A mission feels more outcome oriented...(1/n
Take something subtle like replacing "project" with "mission". A mission feels more outcome oriented...(1/n
Or using the word "bet". Bet is nice, because you can attach it to something highly prescriptive. For example:
"Oh, so your bet is if we build this feature we'll see this positive outcome, right?"
Bet conveys uncertainty, value, investment, information...(2/n
"Oh, so your bet is if we build this feature we'll see this positive outcome, right?"
Bet conveys uncertainty, value, investment, information...(2/n
Lots of teams get stuck on problem vs. solution dichotomies. I prefer... "opportunity vs. intervention". Lots going on there. Problem conveys a binary "solving". Intervention feels experimental. Opportunity feels valuable (3/n
here's a little thread on roadmaps and roadmapping
1/8 Roadmaps are almost *never* enough as standalone artifacts. There is no possible way one "thing" can communicate so much nuance: assumptions, risk, vision, "the bet", nesting, etc. #prodmgmt #UX #design #Lean
1/8 Roadmaps are almost *never* enough as standalone artifacts. There is no possible way one "thing" can communicate so much nuance: assumptions, risk, vision, "the bet", nesting, etc. #prodmgmt #UX #design #Lean
2/8 The need for a "solid roadmap that everyone understands" (without additional conversation/context) is a race to the bottom on some level. You'll succeed, but almost by definition everyone will be missing *something*.
3/8 PMs know this...go low level, people will ask you to go high. Go high, they say get more specific. Get solution based, people will ask for "the problem". The problem... "we need specificity". It is a never ending cycle.
Whenever I see a tool become popular (e.g. #wardleymapping #cynefin, [insert tool here]), I have a tinge of sadness (amidst a lot of gratitude).
Why? Bc it reinforces for some ppl that the lack of “tool” was “the problem” all along. Tools help. But it’s not “the problem” .(1/3)
Why? Bc it reinforces for some ppl that the lack of “tool” was “the problem” all along. Tools help. But it’s not “the problem” .(1/3)
I remember a decade ago having an awesome whiteboarding session. We weren’t “doing X” exactly, but we were improvising well. We were grounded in first principles. We got so much mileage from those conversations.
That required an extremely safe environment. AND PRACTICE (2/4)
That required an extremely safe environment. AND PRACTICE (2/4)
Whenever you have a new Way ... you have the Way of Ways. As you move further along this path, you’ll get shallower and shallower interpretations. Less context. Less awareness of the influences, prior work. More silver-bullet-ism (3/4)
Some quick tips for guiding your team to be more outcome focused.
1. Use the language of missions, bets, outcomes, etc. *alongside* whatever ppl are currently used to (output, dates, features, etc.). A trojan horse! No one will stop you. #proddev #ux #design
1. Use the language of missions, bets, outcomes, etc. *alongside* whatever ppl are currently used to (output, dates, features, etc.). A trojan horse! No one will stop you. #proddev #ux #design
I was talking to a coach the other day. They were going deep (into systems thinking, org design, complexity, NVC, etc.). And something hit me:
Me: “I see you care very, very deeply about this team and company. What do YOU need?” (1/5)
Me: “I see you care very, very deeply about this team and company. What do YOU need?” (1/5)
He was taken aback, and gave it some thought...
“I need to be in an environment where people give a fuck. Where we can explore new ideas without so much cynicism. Together w/o the mistrust and success theater.”
Those words hung in the air...(2/5)
“I need to be in an environment where people give a fuck. Where we can explore new ideas without so much cynicism. Together w/o the mistrust and success theater.”
Those words hung in the air...(2/5)
I asked “do those other people truly not give a ***k? Or just care about different things?”
We chatted. I was reminded of something @MrAlanCooper wrote about recently re: individualists and collectivists.
This coach was very much in the collectivistic camp... (3/5)
We chatted. I was reminded of something @MrAlanCooper wrote about recently re: individualists and collectivists.
This coach was very much in the collectivistic camp... (3/5)
Advice to a friend dealing with their chaotic startup...
Startups are inherently chaotic. No chaos = no opportunity. Startups exist because there is uncertainty, and new things to learn. (1/7) #startup
Startups are inherently chaotic. No chaos = no opportunity. Startups exist because there is uncertainty, and new things to learn. (1/7) #startup
During a period of rapid growth, all things (structures, processes, etc.) eventually break. Some chaos is self-inflicted, and too much chaos can cause collapse / chronic harm (2/7) #startup
Agility is solving today’s problem, while not limiting your ability to solve tomorrow’s problem. There’s always a temptation to solve tomorrow’s problems.
There are good ideas everywhere, and opportunities everywhere. So focus is hard (3/7) #startup
There are good ideas everywhere, and opportunities everywhere. So focus is hard (3/7) #startup
Here’s a little thread about “feature factories” and what I’ve learned since writing about FFs a couple years ago.
At the end of the day it is about a *genuine sense of impact*. Problem solvers need that. It’s in our blood... (1/9) #design #ux #prodmgmt #agile
At the end of the day it is about a *genuine sense of impact*. Problem solvers need that. It’s in our blood... (1/9) #design #ux #prodmgmt #agile
When you start out, getting something/anything into prod feels like a win. And it is! But with time that novelty begins to fade. You realize that anything in prod that doesn’t add some high multiple of value is just dead-weight (psychically, and operationally) (2/9)
You also become more tuned into success theater, which is like kryptonite to puzzle solvers. It feels dirty and wrong. It feels insincere (3/9)
This is a pull system...we start something when we finish something else.
This is not a pull system. The team agrees upfront to a batch of work for the month. This is often rationalized because 1) “people will be lazy with the time constraint” and 2) it gives the team “something to shoot for”
#scrum, in theory, focuses on a sprint goal. The team is empowered to adjust scope to achieve the goal (vs. finish a predetermined set of stories).
So let’s take an org that is experiencing 50%+ drag due to technical debt.
You would think that would ring alarm bells everywhere, right? It would be all hands on deck fixing the issue, right?
Well... (1/13) #leanagile #devops
You would think that would ring alarm bells everywhere, right? It would be all hands on deck fixing the issue, right?
Well... (1/13) #leanagile #devops
“How could YOU ever let it get this way?”
“Well, WE’VE been warning YOU about it since.”
“But YOU never said it would be THIS bad!”
“We did. You’d ask for a plan. We’d give you a plan. You’d say no way. And then we’d settle on a band-aid like 10% time” (2/13) #leanagile #devops
“Well, WE’VE been warning YOU about it since.”
“But YOU never said it would be THIS bad!”
“We did. You’d ask for a plan. We’d give you a plan. You’d say no way. And then we’d settle on a band-aid like 10% time” (2/13) #leanagile #devops
Typically, someone was raising the alarm, somewhere. But it all got watered down...
the org was experiencing growth, hiring lots of people, launching new products. So much noise. Little signal.
“Oh, it’s just developers complaining...” (3/13) #leanagile #devops
the org was experiencing growth, hiring lots of people, launching new products. So much noise. Little signal.
“Oh, it’s just developers complaining...” (3/13) #leanagile #devops
Company Culture Is ...
- What you say, and how often you say it
- What, when, and how you celebrate
- The losses and missteps you acknowledge, and how you respond
- How you behave when the chips are down
- What you fight for at all costs
- The corners you cut
(1/4) #culture
- What you say, and how often you say it
- What, when, and how you celebrate
- The losses and missteps you acknowledge, and how you respond
- How you behave when the chips are down
- What you fight for at all costs
- The corners you cut
(1/4) #culture
- Who you hire, promote, and compensate, and who you fire
- Who you “smoke out” until they leave the organization
- The worst behavior you accept and the best behavior you reject
- The voices you amplify, and the voices you suppress
(2/4) #culture
- Who you “smoke out” until they leave the organization
- The worst behavior you accept and the best behavior you reject
- The voices you amplify, and the voices you suppress
(2/4) #culture
- When you encourage conformity, and when you promote diversity
- How you handle disagreements and differences in opinion
- How and where you spend your time and money
- What gets discussed out in the open, and behind closed doors
(3/4) #culture
- How you handle disagreements and differences in opinion
- How and where you spend your time and money
- What gets discussed out in the open, and behind closed doors
(3/4) #culture
When this happens, we’re in a pickle. In true pull-system fashion, the developer has pulled another card. Test finds an issue that demands developer’s attention. What to do? (2/11)
One solution is to say “hey dev, you can only be on two things at once...one of which is developing”. Seems reasonable...and keeps their bandwidth open to fix issues. (3/11)
Some #prodmgmt Qs for interviewer... (1/4)
- technical debt
- recent prod issues / reactive work
- direct access to customers
- attrition rate for PMs
- typical calendar / mix of activities
- last 5-10 prod decisions and outcomes
- details of decision making process
- technical debt
- recent prod issues / reactive work
- direct access to customers
- attrition rate for PMs
- typical calendar / mix of activities
- last 5-10 prod decisions and outcomes
- details of decision making process
- metric you must drive to be successful
- psych safety on teams
- dedicated #ux ?
- how team missions are crafted
- autonomy over roadmap ?
- deployment pipeline, ease of collaboration
- access to product usage data (tools?)
- current “big bet” and key unknowns
#prodmgmt 3/4
- psych safety on teams
- dedicated #ux ?
- how team missions are crafted
- autonomy over roadmap ?
- deployment pipeline, ease of collaboration
- access to product usage data (tools?)
- current “big bet” and key unknowns
#prodmgmt 3/4
- career development (conferences, training)
- incentive structure for team members
- amount of pre-committed work
- examples of PMs being reward for specific behavior
- details of approvals, sign-offs, roadmap reviews
- overall product “culture” (role of product)
#prodmgmt 3/4
- incentive structure for team members
- amount of pre-committed work
- examples of PMs being reward for specific behavior
- details of approvals, sign-offs, roadmap reviews
- overall product “culture” (role of product)
#prodmgmt 3/4
#kanban tips (1/3)
Model the work, not the “workers”. With team member magnets, checklists, and markers...the bottom design can more than adequately model the work
If work ever “moves left” (e.g. QA/demo passes an item “back to dev”), then the top dsgn breaks. It is all doing.
Model the work, not the “workers”. With team member magnets, checklists, and markers...the bottom design can more than adequately model the work
If work ever “moves left” (e.g. QA/demo passes an item “back to dev”), then the top dsgn breaks. It is all doing.
Another classic anti-pattern is team/individual lanes and “splitting” the work. The bottom option will probably catalyze the right conversations....though the top option with string can also do the trick. (2/4) #kanban
A compromise if teams want their own card for some reason... is a hybrid board with “epics” (larger chunks of work), and all of their related cards.(3/4) #Kanban
“How does #ux work with #agile” ?
Step 1: Read the Agile Manifesto for Software Development agilemanifesto.org
Step 2: Read the Principles behind the Agile Manifesto: agilemanifesto.org/principles.html
Step 3: For a modern twist, check out Modern Agile: modernagile.org
1/3
Step 1: Read the Agile Manifesto for Software Development agilemanifesto.org
Step 2: Read the Principles behind the Agile Manifesto: agilemanifesto.org/principles.html
Step 3: For a modern twist, check out Modern Agile: modernagile.org
1/3
...you’ll quickly notice there is no mention of Product Owners, Sprints, User Stories, Story Points, Scrum Masters, Demos, Jira, etc. And no mention of #ux, #datascience, #businessanalyts #devops etc.
There is one key thing though... 2/3
There is one key thing though... 2/3
Heard (again) that #design and #ux is somehow incompatible with #agile (which to most, means #scrum).
..that ppl can’t always jam their work into little increments
..that MVPs suck because they’re never improved
..that work can’t always be boiled down into a “ticket” 1/n
..that ppl can’t always jam their work into little increments
..that MVPs suck because they’re never improved
..that work can’t always be boiled down into a “ticket” 1/n
