Enabling Hyper-productivity
Published on Nov 18, 2015
Flow. Every team wants to get there, but many working with iterative development can't quite make it.
MORE DECKS TO EXPLORE
7 Strategies to Write a Speech with Ease
84668 views
WHY WORK WITH ME?
20270 views
Techno Teaching
26960 views
Dance at Work
18698 views
Key Ecommerce Questions
25203 views
Brand name development using the FREE PIZZA method (a bad idea)
10598 views
10 ways
45195 views
TXLA Wrap-up 2015
9450 views
How to make a portfolio
17014 views
Writing Your Book: The 5 Most Helpful Habits
19290 views
Kathy's Kitchen
5880 views
To Be Curious
25883 views
PRESENTATION OUTLINE
ENABLING HYPER-PRODUCTIVITY
TOOLSETS AND METHODS FOR AGILE TEAMS AND PRODUCT OWNERS
As first presented at ScrumClub Immobilienscout24 2013
A Breif outline of the problems teams face and their impacts
A Breif outline of the problems teams face and their impacts
WHO AM I? I AM @MISS_ _HALEY
- Massive nerd
- Passionate about agile
- CSM & CSPO
My name is Amber, and I'm about 34% MIscellaneous stuff like cooking and reading,
32% Internet nerd - I love web technologies and new services. I specialise in UX thinking and UI/Interaction design..
But most of all I am an Agilist.
Trained CSP, i work here at IS 24 as a Scrum master and Agile coach, and have also been Product side with Scrum as a PO.
Find me on twitter posting random things of interest..
32% Internet nerd - I love web technologies and new services. I specialise in UX thinking and UI/Interaction design..
But most of all I am an Agilist.
Trained CSP, i work here at IS 24 as a Scrum master and Agile coach, and have also been Product side with Scrum as a PO.
Find me on twitter posting random things of interest..
PROBLEM:
UNSTABLE VELOCITY
Velocity or Throughput wobbles are a major problem for product owners, managers and teams alike. With low predictability comes the classic problems that occur between stakeholders of project and developers; the "when will it be done?" question.
Unstable Velocity/throughput instability can also indicate problems in understanding the the 'why' or 'what problem are we trying to solve' element of work.
Unstable Velocity/throughput instability can also indicate problems in understanding the the 'why' or 'what problem are we trying to solve' element of work.
PROBLEM:
EMERGENT REQUIREMENTS ON EVERY STORY
The Pie in the face! When using agile or iterative development it's generally understood that the concept of emergence, as it relates to requirements, will occur.
As more people interact with the team and with the product, more ideas and improvements will be forthcoming.
We also understand that change in technology is constant, and at a moment notice we could have a major disrupter turn up that will challenge all preconceived notions
BUT
The structured occurrences of emergence indicated above should not be happening on every story. This uncertainty has an impact not only of the quality of work, but the motivation of the team producing the work. Constant rework that brings no value to customers is a sign that there are chunks of vital information missing on start, or strategic elements that have not been finalised, or critical dependencies have not been uncovered.
As more people interact with the team and with the product, more ideas and improvements will be forthcoming.
We also understand that change in technology is constant, and at a moment notice we could have a major disrupter turn up that will challenge all preconceived notions
BUT
The structured occurrences of emergence indicated above should not be happening on every story. This uncertainty has an impact not only of the quality of work, but the motivation of the team producing the work. Constant rework that brings no value to customers is a sign that there are chunks of vital information missing on start, or strategic elements that have not been finalised, or critical dependencies have not been uncovered.
Photo by jimmyweee
PROBLEM:
DISTRACTIONS
Essentially, there are two main types of distractions: visual and auditory. A visual distraction by definition is where some movement in the range of your vision causes you to interrupt your train of thought or current activity. The most common form of this in an office is movement that is observed, often with peripheral vision, and causes the observer to stop what he or she is doing.
Studies have shown that when you're distracted from what you're focussed on, it can take 10 to 20 minutes to get back on track mentally.
Multiply this times the number of given distractions in a given day, times the number of affected employees, times the number of workdays in a given year, and you have major roadblocks to efficiency.
When we work in software there is a hidden Third type of distraction: anything you're working on that's not part of what the team has committed to.
Studies have shown that when you're distracted from what you're focussed on, it can take 10 to 20 minutes to get back on track mentally.
Multiply this times the number of given distractions in a given day, times the number of affected employees, times the number of workdays in a given year, and you have major roadblocks to efficiency.
When we work in software there is a hidden Third type of distraction: anything you're working on that's not part of what the team has committed to.
Photo by quinn.anya
PROBLEM:
BUGS
Self explanatory really ;-) The segway from Distractions to bugs is not by chance.
Bugs are mainly caused the following:
1. Specified wrong
2. Build wrong
3. Tested wrong
and 4. Hidden dependencies.
I see this more as a chain effect, with the first two conditions symbiotically linked.
With wrong or unclear information, teams can't help but be set for a larger than normal chance of failure. When we get to the testing component if acceptance criteria or use cases are not followed then the potential for missing something critical rises, but the true kicker here is hidden dependencies: this will guarantee that more rework is needed
Bugs are mainly caused the following:
1. Specified wrong
2. Build wrong
3. Tested wrong
and 4. Hidden dependencies.
I see this more as a chain effect, with the first two conditions symbiotically linked.
With wrong or unclear information, teams can't help but be set for a larger than normal chance of failure. When we get to the testing component if acceptance criteria or use cases are not followed then the potential for missing something critical rises, but the true kicker here is hidden dependencies: this will guarantee that more rework is needed
Photo by Bhavna Sayana
PROBLEM:
PRODUCT OWNERS AND MANAGERS STRUGGLE WITH TECHNICAL STORIES
The big key word here is domain knowledge.
I often hear PO "my teams have to write the stories"
Or
"this work is too technical for me"
Often the technical environment is far more complicated than first realised.
How to cope with the interdependecies of highly technical or back end stories?
Couple this with time constraints and managing stakeholders; actually making your dreams reality gets blocked and stifled.
I often hear PO "my teams have to write the stories"
Or
"this work is too technical for me"
Often the technical environment is far more complicated than first realised.
How to cope with the interdependecies of highly technical or back end stories?
Couple this with time constraints and managing stakeholders; actually making your dreams reality gets blocked and stifled.
Photo by Giovanni Toso
QUALITY IN:QUALITY OUT
Photo by Pink Sherbet Photography
Untitled Slide
ADDS FOCUS
- Removes detail oriented information gathering away from the team
- Works as a permanent PO buddy
- Runs the estimation and grooming sessions
- Owns ensuring the PO's priorities are reflected in the backlog
- Responsible for training material and sessions.
The intention here is not to replace a PO but to understand the strengths and weaknesses on both sides.
A backlog owner cannot make business weighted decisions about priority, unless empowered to.
They also do not have the power to stop or change sprints.
These decision points are always resting with the Product Owner.
A backlog owner cannot make business weighted decisions about priority, unless empowered to.
They also do not have the power to stop or change sprints.
These decision points are always resting with the Product Owner.
Photo by Joanna Bourne
MOVING PAST BDUF:THE CHALLENGES
- Understanding the concept of "Just enough, Just in time"
- Unknowns are actually ok!
- Writing user stories without getting technical
- Letting go of the how, & focusing on the what
- Domain knowledge for other software specific skills e.g. UX, UI design
Like any big change it will take patience and hand holding.
It will take the SM and the PO colab on Story writing coaching and estimation games, and expectation setting.
make sure you have your handoff points sorted, what escalation actions need to be in place, who is in charge of what type of communications.
The point is: none of these hurdles are insurmountable.
It will take the SM and the PO colab on Story writing coaching and estimation games, and expectation setting.
make sure you have your handoff points sorted, what escalation actions need to be in place, who is in charge of what type of communications.
The point is: none of these hurdles are insurmountable.
Photo by Claremont Colleges Digital Library
ALWAYS START WITH WHY!
FOR CRYING OUT LOUD.
This seems so obvious but it is one of the most unexplained aspects of agile development.
Why we are even doing this in the first place?
This is more about communication than metric gathering but having some validated data always helps.
Get inputs last release, the multiple guys complaining on the phone..
Then communicate this out to the team.
Why we are even doing this in the first place?
This is more about communication than metric gathering but having some validated data always helps.
Get inputs last release, the multiple guys complaining on the phone..
Then communicate this out to the team.
Photo by tansengming
STORY MAPPING
CREATE A BIG PICTURE FOR RELEASE PLANNING
Quick quiz:
Who of you has a clear big picture of all the feature and function groups of your product?
Who knows about Story Mapping?
Who uses it?why do you use it?
Story mapping is a system overview. It's a lean way of doing BD/BRUF...
and a tool to validate the features of your MVP..
and a way to ensure you focus on the right things that bring value to your business and users now..
and a release plan.
Its big and visual, and it's hard to forget about parts of your product if you have one of these in your team area.
Who of you has a clear big picture of all the feature and function groups of your product?
Who knows about Story Mapping?
Who uses it?why do you use it?
Story mapping is a system overview. It's a lean way of doing BD/BRUF...
and a tool to validate the features of your MVP..
and a way to ensure you focus on the right things that bring value to your business and users now..
and a release plan.
Its big and visual, and it's hard to forget about parts of your product if you have one of these in your team area.
GET OUT OF THE BUILDING!
TALK TO THE PEOPLE WHO USE YOUR PRODUCT!
If you want to truly get value in development it means escaping the confines of the office
Find your users.
Get out and make contact.
discover what they need, how they use your product (keep an ear out for completely out of the box usage scenarios! This could lead to new products of markets), their pain points and how critical they are.
Because truly excellent products don't nesseccarily DO everything; they solve a specific problem, and they do this well.
Face to face is always good as you can build mental maps of the types of users you have and their demographic.
Find your users.
Get out and make contact.
discover what they need, how they use your product (keep an ear out for completely out of the box usage scenarios! This could lead to new products of markets), their pain points and how critical they are.
Because truly excellent products don't nesseccarily DO everything; they solve a specific problem, and they do this well.
Face to face is always good as you can build mental maps of the types of users you have and their demographic.
Photo by Photo and Co
SEND OUT A SURVEY
UNCOVER HIDDEN USERS AND DEPENDENCIES
Another method for understanding your user base and their pain: leverage electronic tools.
Use tools like Fluid surveys, survey monkey, to gain deeper insights abut how your product is used.
Use point of context tools like Get Satisfaction, or User Voice to get indepth on the spot feedback about problem areas of your offering.
The bottom line here is as the largely unknown creator of Work Simplification, Allen Morgensen once very sagely said
"work smarter, not harder"
factoid: most people thought that was Scrooge McDuck.
Use tools like Fluid surveys, survey monkey, to gain deeper insights abut how your product is used.
Use point of context tools like Get Satisfaction, or User Voice to get indepth on the spot feedback about problem areas of your offering.
The bottom line here is as the largely unknown creator of Work Simplification, Allen Morgensen once very sagely said
"work smarter, not harder"
factoid: most people thought that was Scrooge McDuck.
Photo by DaveCrosby
THINGS TO REMEMBER
But it also needs love. and attention
it is a living breathing piece of documentation.
it is a living breathing piece of documentation.
Photo by Hot Grill
FLOW MAPPING
ATTACHING STORIES TO EVENTS AND DECISION POINTS
Blog post: Mike Lowery : Evolving the story map
http://nomad8.com/evolving-the-story-map/
Flow mapping is a flowchart on steroids.
http://nomad8.com/evolving-the-story-map/
Flow mapping is a flowchart on steroids.
THINGS TO REMEBER
Think of how your END user travels thru the system, the roles and system interactions that get triggered by events.
This is inteneded to be small picture thinking. A detailed view on a single user journey
Attach your stories about these interactions to the parts of the map.
Rememeber to find a cool way to mark done. just like the story map.
This is inteneded to be small picture thinking. A detailed view on a single user journey
Attach your stories about these interactions to the parts of the map.
Rememeber to find a cool way to mark done. just like the story map.
D.O.R.
ON YOUR MARKS.... GET SET....
It is critical that the team understands what is being asked for in order to maximise value delivery.
If you as POs introduce PBI’s that are not ready to be worked on or PBIU’s that contain ambiguity, waste occurs. Waiting time = waste. emergent requirements go up.
BUT this is not Big analysis. This is a simple sanity check to make sure that you have uncovered the most important things like:
- Do we need infrastructure?
- Do we rely on effort outside the team?
- if we interact with data; does it need any kind of validation?
And most importantly: ARE THERE ACCURATE AND ACHIEVABLE ACCEPTANCE CRITERIA.
You can make it as exhaustive or as simple as you like but understand that you might not have to actually DO all the things on this list.
As long as the conversation has been had that says "nope we don't need it." Or "omg we are 3 servers short" the the DOR has done its job.
a little bit goes a long way to increase quality and productivity.
If you as POs introduce PBI’s that are not ready to be worked on or PBIU’s that contain ambiguity, waste occurs. Waiting time = waste. emergent requirements go up.
BUT this is not Big analysis. This is a simple sanity check to make sure that you have uncovered the most important things like:
- Do we need infrastructure?
- Do we rely on effort outside the team?
- if we interact with data; does it need any kind of validation?
And most importantly: ARE THERE ACCURATE AND ACHIEVABLE ACCEPTANCE CRITERIA.
You can make it as exhaustive or as simple as you like but understand that you might not have to actually DO all the things on this list.
As long as the conversation has been had that says "nope we don't need it." Or "omg we are 3 servers short" the the DOR has done its job.
a little bit goes a long way to increase quality and productivity.
Photo by Digital Vision.
RESPONSIBILITIES
this is a way to leverage the strength of a BA.
they are accustomed to speaking and uncovering hidden requirements. they have one foot in Analysis and one in solution
so what this role does is channel smaller bite sized chunks of the traditional BA into quality stories that have depth and detail.r
they are accustomed to speaking and uncovering hidden requirements. they have one foot in Analysis and one in solution
so what this role does is channel smaller bite sized chunks of the traditional BA into quality stories that have depth and detail.r
Photo by noii's
SOUNDS GREAT!
ERM... HOW DO WE DO THIS?
start small. Try one thing. Inspect and adapt.
If you try the Ba approach start by making the BA your PO shadow.
If you try the Ba approach start by making the BA your PO shadow.
Photo by CarbonNYC
INTRODUCING THE BACKLOG OWNER!!
SO HOW COULD A B.A HELP?
This roll was first introduce by an Agilst Shanan Holm, and refined in later role interation By Mike Lowery agile coach.
Find Shanan on twitter @shanan
Find Mike's excellent blog posts on https://nomad8.com
This was initially a way to cope with scrum web development that had a waterfall PM over the top, and later a PO with huge time constraints.
Find Shanan on twitter @shanan
Find Mike's excellent blog posts on https://nomad8.com
This was initially a way to cope with scrum web development that had a waterfall PM over the top, and later a PO with huge time constraints.
Photo by Nina Matthews Photography
Add a B.A. into the mix
Try adding the role of Backlog Owner
