Get the slides by sending a blank email to: firstname.lastname@example.org with subject line: AuthorityPower or download them here.
If you tell people what to do they don’t take responsibility for their actions. Responsiblity can not be given, responsibility can only be taken.
– A person only have power over you if you give them that power, it’s your choice.
– The last power you have is the power to choose.
1. Positional power bases
– Reward power: if you think someone can give you something positive.
– Coercive power: if you believe the other can do something bad to you.
– Legitimate power: you believe that the other person has the right to have a power.
E.g. parents and children.
– Information power: you have power over someone because you have access to certain information.
– Associative power: someone has power because they have access to certain people.
2. Personal power bases
– Expert power: if you think someone know what they are talking about
“Studies say people will believe any bullshit, as long as the study begins studies say…”
– Referent power:the power to change people based on their personality
If you wan’t to get better at helping your teams as a scrum master, you should work on are the personal power bases. You improve your expert power by continuous professional development and your referent power by contious personal development.
How to increase your referent power:
One way is to understand the concept of rank:
– Rank is the sum of your priveleges. Rank is what you can get away with.
– Rank has two parts, one is the part you feel inside and the other is the part of how other people view you as.
– The experience of one’s rank is fluid and changes depending on context.
– Differences in rank can influence how we view an interact with each other. It is often a key issue in understanding conflict situations.
There are three types of ranks:
– positional situation rank: position in hierarchy, specific expertise, seniority etc.
– social rank: race, gender, religion, age, class, sexual orientation, education, appearance
– personal rank: based on confidence, emotional intelligene, inner strength/resilience, influencing skills, respect of peers
Be aware of your rank and the signals you send out.
– talk positively
– give credit and appreciation to others
– accept responsibility, speak in a definitive way, commit to things
– be honest, tell the truth
– respect others
Avoid low rank indicators
– humble bragging
– avoid fillers (like), a great retorical skill is to be able to be silent. If you don’t know what to say don’t say anything 🙂
The first step to increasing well-being, and thus your referent power is becoming aware of your competencies and of the potentials in yourself.
Core skills and competencies
– Rational: our thinking skills. Your ability to abstract things, to understand things.
– Physical: related to the physical senses and to our sensory experience to our bodies
– Spiritual: you are believable to others when they feel that you believe deeply and strongly in something.
– Emotional: how well do you understand your feelings? How often do you get hijacked by your emotions?
– Social: how good are your social skills? how good are your interaction skills?
Skills and competencies exercise
Make a radar chart. In the middle is zero where you feel totaly uncomfortable, and the other side of the edges is something you feel really well about.
As a manager never tell someone what to do. Instead make it clear to people what’s needed and why it’s needed, then give people the space and opportunity to take responsibility. Responsiblity can not be given, responsibility can only be taken! If someone steps up and takes responsiblity, support them in every way possible to help them be successful in their job.
A team is not defined by working at the same unit or at the same project, a team is defined by believing in the same things.
“Just because it’s done, doesn’t mean it’s right.”
Product Discovery session at DevJam, together with their customers they ask the following questions:
– Frame – why are you doing this, what does success look like 3-6 months from now
– Simple personas – to talk about who the product is for
– Trying to make interesting product guesses – this could be putting things in a backlog, but putting things in a backlog does not need to mean you are making interesting choices
– Stories, arranged from left to right in a design interaction way, and top to bottom in some kind of decomposition (story mapping)
– A product developer at DevJam first and foremost care about the product, second they care about maybe their skill. It’s like a guitarist in a band, unless you are a solo player you are part of something bigger than yourself and people come to see the band and not the guitarist.
– We are measuring the impact we are having, and not the progress we are making. Without progress you will have no impact, but if you think progress equals impact you are fooling yourself.
Sketching is a great way to break the chasm between development and discovery.
See also David Hussmans upcoming book “Products over process”.
1900 – Projects – Certainty – We just have to get it done, and then we will be successfull. Parameters: Time, Scope and Budget, and that’s what projects and project managers we’re revarded on (even if what was delivered was a piece of junk)
2000 – Process – Less certain
2010 – Product – Uncertain. Parameters THING, TEAM and TECH.
Context and continuum: (Where does your product sit?)
Two sides: (Not Should we use Scrum or Kanban)
* Uncertainty, things are unknown, dynamic, learn and experiment
* Certainty, things are known, static, construct and build
Product and team models:
– One product, one team
– One product, many teams
– Many products, many teams
Riffed of the Agile manifesto
– Measuring impact over Counting Story Points (Context and impact, who are we doing what for)
– Validated Learning over Getting Things Done (On the kanban board the column to the right is not “done” but “validated”.)
– Learning over Commitments
– “Too Big” over “How Big?”
One product, many teams
Scaling product development:
– more product learning, not more process
– don’t conflate scaling and spreading and don’t accidently increase process
One product, many team mappings
– Two axes: 1) Product, Market, Uncertainty 2) Structure (process, architecture…)
More riffs from the Agile manifesto
– Product Developers over Software Engineers
– Story maps over Epic Stories
– User Experiences over Single stories
– Customer journeys over Iteration Buckets
– Product Learning over Technical Constraints (you intentionally take on technical debt, not accidently. You can’t strive for zero technical debt)
– Learning faster over Getting More Done
– Discovery (KPIs) over Delivery (Pts)
Focusing on delivering stories instead of a user journey is like getting a list of groceries at the end of a sprint instead of a small meal.
How do we blend discovery and delivery? What can we learn outside of production?
Most of the time when we are talking about agile stuff we are talking about a delivery cycle. A better name for grooming is discovery. We as a team can choose before we start a sprint if we should focus more on delivery (getting more things built) or on discovery, trying to figure out what to build. As a developer, how well can you absorb customer empathy? How well can you tell stories? How brave are you to talk about things that aren’t programming?
Cross team validation tools, what can we learn outside the code?
Mixpanel is a web based tool that helps measure how users use your product
What do they need to learn in production? How wrong were they (product arrogance).
This is a summary of the presentation “How doing the little things well makes the big things possible” that Jeff Patton gave at YOW! Nights, Agile Sydney in august 2016. This is a link to the slides of this presentation that was given at another time but I guess most of the slides are intact.
The presentation covers 9 simple things that make hard things easier.
1 – Show me what you’re thinking
– when we externalize our thinking with words and pictures, we detect differencies
– shared understanding and alignment are the objectives of collaborative work
– shared documents are not shared understanding
– good documents should work like a vacation photo, looking at them makes you remember details about the discussions
– agile user stories have a simple lifecycle (3C’s, coined by Ron Jeffries, Card, Conversation, Confirmation)
– It doesn’t really matter what you put on the card, it’s the conversations that are important
– if you replace conversations with documents, you’re stopped using stories
– many organizations put the information from conversations into JIRA and then send it to developers who tries to understand what to build by reading. It’s no wonder that the software doesn’t match the expectations
– effective story conversations build shared understanding
– the best documents use words and pictures to help recall our conversations, the don’t replace conversations
– the next time you have a conversation at work, move it to the whiteboard or grab a stack of sticky notes
2 – Flare
– Flare is about getting everyone involved contributing with ideas and together consider everones ideas. It’s not about having one persons idea win, but about as a group collaborate to get new insights.
– Stanford’s Design Thinking Process (Emphatize, Define, Ideate, Prototype, Test) talks about flare in the ideate and prototype phases. See Stanford’s Virtual Crash Course in Design Thinking for more information on the Design Thinking Process.
– GameStorming is also about flare in the exploring phase when you try to get everyone to collaborate.
– A Design studio is one approach to get the whole team ideate. The way it works is that the group agrees on the problem they are trying to solve. Then people go off and spend some time independently sketching on ideas. The next step is for everyone (not just UX or UI designers, but everyone!) to meet and share their results and the group tries to find the best ideas (not the best sketches). See the Google Venture video where Jake Knapp talks about their design studio approach. Jake has also written the book Sprint that goes into the design studio approach in more depth.
For more info about design studio see Jeff Patton’s Design Studio Recipe and his Design Studio Quick reference.
– deliberately widen your field of choices before making a decision. When arguing, stop, take a few minutes to sketch your ideas and then make time to hear each others ideas.
– the best idea isn’t mine or yours but it’s a little bit of everbodys ideas
3 – Shut up
– stop talking and let the model do the talk
– Tom Wujec noticed that talking doesn’t help in collaboration, see his TED Talk “How to make a toast”.
– talk less: reorganize simple models to help describe your ideas without all the discussion. Replace brainstorming out loud with silent brainstorming.
4 – Focus
– set goals, then use pace-keeping signals to stay focused on them. Jeff showed an example of how they used coffee muggs with messages written on them (“Sold”, “Too much detail” etc.) that were used to keep the discussions in a work meeting focused.
– save document creation and maintenance for later
– focus on specific outcomes. Keep checking in on those outcomes and “time out” when the team drifts
5 – Time box
– Use the Pomodoro technique to keep pace
– Time-box small and large activities. At the end of a time-box, stop, reflect and ask if you can satisfice (is it good enough for now)
6 – Un-invite someone
– The ideal decision making group is dinner-conversation sized (2-4, maybe 5 people)
– Use different strategies for different sized groups
– 2-4 people, set goals, time-box and keep pace
– 5-11 people, add a facilitator and structure the workshop
– A dozen or more: break into small groups, then integrate results
– Crowds don’t collaborate. To make decisions fast, keep groups dinner-conversation sized
7 – Get out more
– Go where people work and let them teach you how and why they do things
– Having one person with your team is not a substitute for going out to the users, meeting users builds empathy
– Don’t wait for permission to go see the users
– Notice the difference that make a difference (some stories might not be needed when you actually see and understand how people work)
– The best solutions come from passionate, motivated people. Empathy is the most powerful and positive motivator
8 – Act
– Tom Chi from Google X talks about rapid prototyping Google glass at TedX and in this presentation he says “Thinking is overrated. Doing is the best kind of thinking” or as Jeff titles it: Stop debating and act.
– JFDI (Just *** Do It)
9 – Take 5
– If you’re doing it right, this stuff is really exhausting. Get out, get coffee, close your eyes, and take 10 deep breaths
It’s doing the simple things well that makes the tough stuff possible
This post is a summary of the talk “Letting go of Agile: Where agile thinking steers us wrong” that Jeff Patton gave at Agile Tour Vienna in 2015. Presentations and slides from the conference can be found at the Agile Tour 2015 github. The pictures in this post are screen shots of the presentation and they are all drawings made by Jeff Patton.
1 – Software development is about changing the world
Software development is about changing the world to the better for our stakeholders (users, customers, their business etc.), it’s about solving real problems that people have. Great software enables people to accomplish things in a better way than before, or things that wasn’t even possible without the software. When creating new software it’s essential to understand the problems that our stakeholders have. The best way to get a real understanding of peoples problems is to take the time to sit together with them in their own working environment to understand what makes people sad, upset or angry. From this we come up with ideas (new products, features or enhancements) that could solve these problems. Whether the software we build is successfull or not depends on if we have solved the problems our users have, or as Jeff says “What ever people were doing before that sucked, they can do it differently now”. This is what we call outcome, and this is measured in how people change their behavior.
The effect of the product in the business is called impact and is measured in e.g. ROI (Return Of Investment) or change of market share.
Working software is NOT the primary measure of progress for your users, your customers or your business, the primary measure of progress should be outcome and business impact, and Agile is not enough to achieve outcome for users and impact on business.
2 – Outcome and impact is measured AFTER the software is delivered
The annoying thing about outcome is that it happens after the software is released, it can’t be measured in a sprint or in a sprint review. It might even take a long time after the software is released as described by the Pirate metrics AARRR by Dave McClure. AARRR stands for Acquisition, Activation, Retention, Revenue and Referral
3 – Core product team
To understand the needs of the different stakeholders of a product and to be able to come up with great ideas you need to have more than just a product owner (product manager) that is responsible for this work. Marty Cagan suggests that you have a team of people with the roles product manager, UX and lead engineer and he calls this the core product team.
The product manager is responsible for making sure the product is valuable, the UX person makes sure the product is usable and the lead engineer makes sure that the product is built in a feasible way. Atlassian calles this team “The triad” and Spotify sometime referers to this team as the “The trio”. This team is together responsible for the outcome and impact of the product and the team does this by orchestrating collaboration amongst the different stakeholders.
4 – Traditional agile development takes too long time to evaluate an idea
Nordstrom is an example of a company that used to do traditional agile development and it looked something like the following picture:
The process for Nordstrom was to first create a business case with an estimate of cost and potential income for a product to get an ROI estimate. The next step (if the ROI was positive) was to initiate a “sprint zero” in order to create a backlog and update the estimates. After that the product was developed in a series of sprints until released.
The problem with the above process is that it takes quite long to evaluate a product idea. Concidering that our ideas are correct approximately 20-30% and we are wrong about 60-70% of the time it’s very wasteful to go through this whole process in order to evaluate a product idea. The process is really a “Paid to build” cycle and it should not be used before you know that the product idea is worth building.
5 – Discovery or “Pay to Learn”
What Nordstrom started doing to ensure they were only building the “right” products was to create a “Pay to learn” cycle as illustrated below:
This process starts with a hypothesis (a guess) that need to be evaluated in order to know if it works. The process follows the Lean Startup Build – Measure – Learn steps. This is Discovery work and the focus is to learn fast. This youtube video from Nordstrom Innovation Lab shows how their discovery process works.
6 – Continuous discovery and delivery
Discovery and delivery are two types of thinking that complement each other. In Agile the discovery part is invisible, and making that kind of work “slows down” the delivery velocity. Allthough these are two separate tracks we want the same team to work on them. As a developer, getting involved in the discovery work is about getting interested in what is the right thing to build and not just passively accepting stories in a backlog.
If the whole team is involved in both discovery and delivery work the team will get an “ebb and flow” rhythm where the focus changes between the two. When focus is more on discovery the delivery velocity goes down and vice versa. If you don’t look at the whole picture (both Discovery and delivery) the team will look unpredictable since the delivery velocity will vary a lot depending on where the focus of the team is.
7 – Summarizing points
– Organize teams around product vision
– Build customer empathy and understanding
– Test before you invest
– Balance continuous discovery and delivery
– Stop celebrating delivery and start celebrating learning and genuine product outcomes (these are true measurements of progress)
Marty Cagan gave this very inspiring talk called Great Engineering, Failed Product at the Craft 2015 conference. The talk is about the huge difference there is in how the best companies produces products compared to how most companies produces products.
The root causes of failure (the process used in most companies):
1. Ideas: comes from two sources: Customers or sales
2. “Biz Case”: informal or formal
– how much money are you gonna make
– how much money is it gonna cost
3. Roadmap: comes from focus on higher value and desire for predictability
4. Requirements: – someone is responsible for gather requirements and document them for engineering
5. Design: user experience design
6. Build: enter engineers, this often the very first appearance of the agile implementation
7. Test: some companies even use “hardening” phases where all bugs are fixed. Having testing sprints being different than development sprints is madness.
8. Deploy: the final step
The above is anything of agile, this is basic waterfall!
What’s wrong with this process?
1. The source of ideas – the best source of idea is not included in the process. The customer and the executives of the company don’t have the knowledge of what’s possible with the technology. Also none of us knows what we really want with a technology product before we have had a chance to play with it. Consistently the best source of new ideas are the developers! The reason for that is that the developers work with technology every single day and know exactly what is now possible to build. The chrime in most companies way of working is that the developers aren’t even invited to the party where they need to be. Another great source for ideas are collected data. Platforms enables our customers to use our products in ways we didn’t imagine, and this is one the best selling points for public APIs. (For more see the article The Power of Customer Misbehavior or the book with the same name). At eBay the best innovation came from creating an environment where the customers could use eBay in ways no one had anticipated and then observing the customers being creative.
If you’re only using your developers to code, you are only getting half the value.
2. Business Case Fallacy
Business cases if you them right are actually useful. Unfortunately most companies to them to create roadmaps. They are supposed to answer the two questions how much money will we make and how much money will it cost. The problem is that you have no clue at this stage in the process since we just have ideas and they could be good, but probably not. It’s also at this stage when a product or project manager comes to the developers and says we are concidering doing this feature, how long would that take you. The smart answer here is: GO AWAY! This is where story points or t-shirt sizes came from, which in this case is a stupid compromise since we really don’t have enough information to estimate either cost or revenue.
3. The Roadmap
This is the biggest difference between the best companies and the others. Most companies thinks their job is to follow the roadmap and do the things in order of the roadmap. The best companies knows that it’s not. The problem with a roadmap are the two inconvenient trueth with a product: 1) at least half of the ideas that we build and deploy to our customers are not giving our customers any business value or the product is not usable, 2) the ideas that actually are good might take a long time to get to work inte product, might take several iterations to get the details right. Time to market is meaningless, time to deliver real value is really what we are after. A roadmap only helps us with time to market. Companies using roadmaps sees them as commitments and does not know how to handle the actual case of ideas beeing bad and not working or good ideas taking longer than expected to deliver value. A roadmap is actually dooming your team to get items out in your product that most of them don’t work or need more attention to get to work.
4. The Role of Product owner
Good product owner or product manager should have very deep knowledge of your customers and their users, they also have to have a good understanding of the data of your product, they need to understand your business, they need to understand the constraints of your product. In a modern team a product owner or manager is not the one who goes and writes requirements. User stories really aren’t very meaningful.
5. The Role of User Experience Design
Most organizations don’t staff the user experience design they need to. Most companies use some external agencies that give you mockups and wireframes. Companies like Amazon, Netflix and Google hires user experience design as fast as possible.
We need a team of missionaries and not a team of mercenaries. In the process described above, no one in the process get’s to add any ideas to the product development. Definition of insanity is doing the same thing over and over again and expecting different result, and the above process is insanity!
When Agile started to take form in early 2000 there seemed to be hope that developers demanded the insanity to stop and for them to get more involved in the process. But now it seems like the business people has outsmarted most of the developers by allowing them to have their standups etc. as long as you follow the roadmap 🙂
The most important thing to change is to invite the developers to the ideation phase, not once every quarter, but every day! In good organizations, product owners, user experience people and engineers sit side by side and solves problems. That is what being Agile really means.
The problem is that most organizations talk about projects and not products. They optimze for a process leading to a final deployment with a party. You don’t wanna think in terms of projects with issues that should be resolved. You wanna think in terms of results. Outcome and not output. An outcome would example be: decrease the time it takes for a new customer to actually go live from 10 days to 10 minutes. A good team is given objectives like that and are expected to figure out how to solve it.
The process above is the slowest most expensive way of validating an idea as opposed to Lean startup that is the fastest cheapest way to validate an idea. Two most is not fast evaluate a Minimum Viable Product (MVP).
Continuous Discovery and Delivery
Lean startup is about separating the good ideas from the bad, but not in months but hours or days. This is what Product Discovery is all about and the output is validated ideas. The four questions we want answered during product discovery are: 1) will the customer actually buy this (or will they choose to use it), 2) can they figure out how to use it, 3) can we actually build it with the time and skillset that we have and 4) can our stakeholders support it (does it work in the market with regards to law etc.).
Instead of roadmaps use product visions that states where you intend to take the product in the next 2-3 years. From the vision use objectives (OKR – Objectives Key Result) and the whole idea is to drive the team from results. Visions applies to the whole company and objectives to a specific team. The purpose of discovery is to run a number of rapid MVP tests. An MVP is a missunderstood concept but the real meaning is an experiment that gives you insights on your ideas, it is not a product. If you treat your MVP as a product you are wasting valuable time to get your ideas validated quickly. Use the terms MVP test or MVP experiment to underline that it is not a product that you are developing. A good time will do 10-20 MVP experiments each week. The ideas that are good, those are the ones that actually makes it to the product backlog. It’s from the product backlog that the real software is delivered from with all the engineering aspects needed for a product. The purpose with the MVP experiments is to get a Produc/Market Fit.
1. Shared documents aren’t shared understanding
2. It takes more than words to tell a story
3. Stories are about more than what to build
4. The whole story is bigger than a developer can build in a couple of days
Shared documents aren’t shared understanding
Specifying in writing doesn’t work well. When we share and sign off a document we might believe we understand allthough we have different interpretations. Kent Becks insight on the subject was that we should stop exchanging documents and start telling stories so we can figure out a solution together.
The original idea of a story was simple: use it to fascilitate a conversation.
Stories have a simple lifecycle: card -> conversation -> confirmation (Ron Jeffries coined the 3 C’s in Extreme Programming Installed).
It takes more than words to tell a story
Stories get their name from how we use them, not how we write them
With a shallow discussion we might all take away something different.
When we externalize our thinking with words and pictures, we detect differences.
When we combine and refine, we at something better.
Afterward, when we say the same thing, we actually mean it.
What you record during conversations works like a vacation photo, it helps you and others remeber the conversation. Documents should work like vacation photos, i.e. they should help you remember your discussions.
Effective story conversations are about building shared understanding. The best documents use words and pictures to help us recall our conversations, they don’t replace them.
Stories are about more than what to build
Talk about who does what, and why. Talk about the outcome, not just the output.
Focus discussion and collaboration around who will use and benefit, and how they will “later” after delivery.
The whole story is bigger than a developer can build in a couple of days
A Story Map helps organize discussion about user’s experience with our product. Build story maps in small collaborative groups.
Use story maps to understand your product or feature’s experience. Use mapping to break down big stories and to help find small viable solutions.1.
1. Tell stories, don’t just write hem.
2. Use simple visualizations to anchor the stories you tell.
3. Tell the whole story
Effective stories connect everyone to the purpose of your product.
For even more information on this subject read the book User Story Mapping: Discover The Whole Story, Build The Right Product by Jeff Patton