Author: beckycarter

Posted in Scrum

Scrum Implementation Examples

Posted on by beckycarter

Scrum in Software Development

FBI (1)

Starting point
  • FBI had paper based document storage systems in 2010 (1, page 2 – 18) 
  • 3 paper copies were needed for everything; one for approval, one to be stored locally, and one to be hand indexed for input into the database

“This method was so antiquated and porous that it was blamed in part for the Bureau’s failure to “connect the dots” that showed various Al Qaeda activists entering the country in the weeks and months before 9/11″

Previous Attempts
  • The Virtual Case File (VCF) system had $170 million and 3 years spent on it but didn’t work and was never used 
  • A further attempt was called Sentinel which was budgeted at $451 million and 4 year timeline
    • One year late $405 million had been spent and it was estimated to need another $350 million and 6-8 years to finish
  • Way people were working for these previous attempts was wrong (waterfall was being used)
Scrum success
  • A proposal was then made to finish the most challenging half of the Sentinel project in a fifth of the time with a tenth of the budget, bringing development in house and reducing the number of developers from 220 to 40
  • The 1,100 requirements were prioritised so that the most valuable would be done first
  • It took 18 months to get the database system deployed, and a further 2 months to deploy it to entire FBI

Scrum not in Software Development

EduScrum (1, page 204-211)

context
  • Used in a school in the Netherlands, specifically a Chemistry class
  • Students in the class are divided into teams which all have the same goal of learning a new topic
HOW
  • The class pull out a Scrum board at the beginning of each lesson with their backlog
  • Each team selects the story pointed tasks it thinks it can get done in that lesson, based on velocity
  • They have a definition of done (and fun) which includes everyone in the team understanding the topic, so they must work as a team regardless of how easy they find the topic
  • Each sprint is 5 lessons, at the end of which there is a test on the topic 
  • They have a retrospective at the end of each lesson to learn how to work better
  • The students are totally self-organising, including setting themselves homework
  • Teacher helps when he spots a blocker, and tests the team randomly if they move something to done that everyone understands
RESULTS
  • By using Scrum not only do the students learn the topic, but also how to work together as a team and use each other’s strengths 
  • The curriculum results for this chemistry teacher have jumped more than 10% in a year by using Scrum and his students track above average for their grades

Culture

New United Motor Manufacturing Inc (NUMMI) vs Toyota (1)

NUMMI
  • The NUMMI Plant was closed in 1982 and GM management thought it had the worst workforce in America
  • People drank on the job, didn’t show up
  • People sabotaged the cars (e.g. putting a coke bottle in the door to rattle and annoy customers)
TOYOTA
  • Toyota reopened the plant 2 years later with the same workforce and was almost immediately producing high quality cars like they were in Japan
  • Don’t hate the player, hate the game

Quality

Car Manufacturing (1, page 98 – 99)

  • From The Machine That Changed the World by Dr James Womack
  • Toyota, Honda, and Nissan (Japanese) spent an average of 16.8 hours making a luxury car with 34 defects per 100 cars
  • Mercedes-Benz, Audi, BMW (Europe) spent an average of 57 hours to make a car and they had 78.7 defects per 100 vehicles
  • Toyota used Andon cord – when a problem was spotted the production line was halted and the problem fixed so that it wouldn’t occur on any more vehicles
  • Europe had quality checkers at the end to fix the problems

“the German plant was expending more effort to fix the problems it had just created than the Japanese plant required to make a nearly perfect car the first time”

References

  1. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
Posted in Library

‘Scrum: The Art of Doing Twice the Work in Half the Time’ Review

Posted on by beckycarter

Holiday Read

This is an easy read about the origins and principles of Scrum, with no complex theory to focus on. There are also some interesting stories of Scrum being used in non-software development environments. 

This book is one that should be on the must read list for all involved in Scrum. It isn’t expensive, it isn’t taxing, and how better to fully understand Scrum than to read from one of the co-creators about how they came about creating Scrum. 

Not just Scrum!

That being said, this book does not stick to the explicit content of the Scrum guide and does talk about complimentary practices, for example story points. My version of this book was published in 2015 and there have been updates to the Scrum Guide in terms of wording as well as opinions on complementary practices that could spark a lively debate with what is written in this book. So even though this book is written by the co-creator of Scrum you may find yourself pausing at certain points to think and maybe disagree. 

Should I read it?

If you are looking to just pass the PSM I because you have been told you have to but you don’t care about Scrum, this book won’t help you pass. If you are new to Scrum and want to learn a bit more about the why and how it can bring value, read it. If you are an old hand at Scrum and have the Scrum pillars tattooed on your heart but haven’t read this book, this is a great refresher to help take a step back and see Scrum at its fundamentals and most importantly, why Scrum. 


Library
Estimation
Posted in Scrum Events

Sprint Retrospective Real Examples

Posted on by beckycarter

Pixar (1)

Notes Day is a day in which employees tell management how to make Pixar better. No visitors allowed and everyone must attend.

‘we have a problem and we believe the only people who know what to do about it are you’ 

page 282

Structure

  • People submit discussion topics in advance 
    • Go through them (pick ones which you can imagine 20 people talking about for an hour) (1, page 283)
    • Schedule sessions and let people sign up for it themselves  (1, page 284)
  • Start the day off by a intro speech
    • John Lassiter gave an example of being thankful for the feedback that he personally received and reminder how important honesty is and not to feel attacked personally
  • First session was within departments to warm everyone up being candid with people that they worked with regularly before having to do it around strangers
  • Subsequent discussion sessions scheduled that people submitted and signed themselves up to in advance of the day
    • Executives and directors did not join these sessions (to allow safety) and addressed their own issues together separately
    • Each session has exit forms to be filled in to capture the discussions
    • The exit form included the final line of ‘who should pitch this proposal (i.e. a volunteer) (1, page 286) 
  • Social event afterwards
  • Afterwards volunteers who signed up to pitch the proposal presented them to the execs who immediately began implementing the ones that made sense, or earmarked to do at a later stage when it was more logical (1, page 292)

Reasons for success (1, page 293)

  • Clear and focused goal
    • They used the fact that it was costing too much and something needed to be done to hit specific financial goal
  • Championed by the highest levels of the company 
  • It was led from within, no outside consultancy running it
    • The commitment was contagious 

References

  1. Creativity Inc. by Ed Catmull

Explore more


Library
Agile Games
Posted in Scrum Events

Sprint Review Real Examples

Posted on by beckycarter

Pixar (3)

Pixar use regular meetings every few months called Braintrust Meetings to inspect progress made on a film, talk through what works and what doesn’t, and how to adapt the film to improve (i.e. similar to a Sprint Review).

‘put smart passionate people in a room together, charge them with identifying and solving problems, and encourage them to be candid with one another’

page 86-7

Structure (1, page 94)

  • Film screening 
  • Lunch together in a conference room (to gather thoughts) 
  • Director will give a summary of where they think they are
  • Feedback begins

Feedback (page 93)

  • Braintrust notes, then, are intended to bring the true causes of problems to the surface – not to demand a specific remedy (page 93)
  • The director (as mirrors the PO role) is able to change whatever he/she wants from the feedback
  • Feedback is given as constructive criticism (page 103) 
    • “The writing in this scene isn’t good enough” (just criticism) 
    • “Don’t you want people to walk out of the theater and be quoting those lines?” (more of a challenge and shows you want the same things) 

References

  1. Creativity Inc. by Ed Catmull

Explore more


Library
Agile games
Posted in Library

‘The Everything Store’ Review

Posted on by beckycarter

Holiday Read

Where is the Scrum?

This book is not about Scrum, it doesn’t mention it as far as I can remember, and is not something to read to learn about how to implement it.

But.

There is something about the visionary that is Jeff Bezos that gets me thinking about Scrum. It is talked about that people who work for Bezos frequently burn out because the pace of working there is high and the pressure intense. This isn’t the part that made me think of Agile as it doesn’t seem conducive with the principle that ‘Agile processes promote sustainable development’.

No, it was the part where the writer says that if you ask anyone in the company about Amazon’s values or ambitions, they can tell you exactly the same message that Bezos believes. No confusion through the grapevine. No two departments pushing on either side of a swing door to get it to open. When one side pushes harder, so does the other and the door does not move. They all are following the same vision, the same goal. Bezos comes across in the book as the kind of boss that can be disobliging and stubborn in his ways. But his headstrong nature enables him to cut through the bureaucratic obstacles that we all come across in our product development and see what is true value. The customer. He is laser focused on their needs and will stop at nothing to make sure they come first. Sure, he gets it wrong sometimes, but he isn’t afraid of that.

One example from the book that I think a lot of us can relate to is when there was a hiccup over the emails that Amazon sends for abandoned baskets. We have all received those types of emails. But this hiccup related to automated emails being sent when customers had been browsing for personal, intimate items that they did not want to be reminded of by an email. Bezos argued that these emails shouldn’t be sent at all, regardless of product type, as he questioned the value to the customer. Even once he understood how much revenue Amazon makes from these emails. Didn’t matter. Customer comes first.

So what can we learn from this book?

I don’t think this book teaches much, if anything, that we can take to build successful Scrum teams. To me, Amazon appeared as a culture that would terrify me personally as a Scrum Master, with the safety and trust in teams buried underneath something more sinister and oppressive.

The learnings in this book are more about the value of a solid product vision, and the courage to pursue the customer need. This is a theme running throughout the book, driven by Bezos’ drive for ‘The Everything Store’ to be achieved. You can feel the passion from him in every decision that is discussed.

‘ I would define Amazon by our big ideas, which are customer centricity, putting the customer at the center of everything we do, and invention’

page 424 , quote from Bezos interview by 60 Minutes, the CBS News program from December 2013

Amazon: a leader in software development

Amazon is brought up frequently as a company that iterates super fast and is skilled at identifying holes in the market, seizing them quicker than any other could. I myself use it as an example company with their famous ability to deploy every 10 seconds, or whatever the latest record is. The fact that as a book company they looked for their own market disrupter and brought in the e-Reader to replace their own business before someone else did is another story I tell in teaching.

The book has good examples of their innovation that provided the background to those famous stories I had been missing and helped me stop misusing the company as an example without a proper understanding of the facts.

Amazon does move fast. If it sees a gap in the market appearing, or new trends arising it pounces on them and invests heavily to corner the market. Examples of this are the e-reader as the new way to books, and video stores being replaced by online DVD rentals and then streaming. But Amazon didn’t come up with the ideas entirely itself as I previously thought. Most of the examples in the book are about how it invested and bought companies in these emergent industries and that then boosted them with their own development strength. They then won battles in owning the market partially through vicious sales techniques and bullying, not purely on their prowess with product development.

The best example of something that organically came out of Amazon itself is AWS. That is a much more pleasing example of an initiative that started internally powered by their own need that they then grew to be something the world would thank them for. So I think I will be using this example instead.

Recommendation

I would recommend this book to anyone interested in learning a bit more about how the big businesses work, or anyone who has a general interest in where the technology we know so well came from. Product Owners would probably benefit more than Scrum Masters to read about the growth of a product from inception, through challenges, and finally to market success which is the core of the book.

The book is written by someone who is not an Amazon employee, but instead a journalist who has followed the company over the years. It is not a page-turning thriller, nor a personal recounting of events, so I will admit it took a little more drive from me to pick it up. But I am glad I did as understanding how one of the most successful product-driven companies in the world operates is surely something worth knowing.

Explore more


Library
Which direction?
Metrics
Posted in Scrum Add-ons

Creating a New Product Backlog

Posted on by beckycarter

Gathering Requirements

Trawling for Requirements (1, page 43)

Imagine gathering requirements as like fishing. You don’t want to catch every single fish in one haul as the processing of that would mean that some fish would go off. Focus on catching the big fish first by using a wide net, then later you can use a finer net to catch the smaller fish. This is the same with requirements as with the big requirements you can use them to understand the product direction better.

Building the Initial Backlog Techniques

Idea Generating Workshop (2, page 50)

  • Use the liberating structure, 25/10 Crowd Sourcing
  • Ask the room to use the ‘What’s the most important feature this product needs to be successful?’ question
  • The output of the session can be used by the Product Owner to form the initial Product Backlog

User Story Mapping (4)

Impact Mapping (3, page 86)

Technique for connecting PBIs back to the goals they are intended to meet.

Impact Mapping

References

  1. User Stories Applied by Mike Cohn
  2. Fixing Your Scrum by Ryan Ripley and Todd Miller
  3. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  4. User Story Mapping by Jeff Patton

Explore more


Refinement
User Stories
Posted in Product

Design Studio Workshop

Posted on by beckycarter

What

This workshop is a team activity to design the UX for a product/ feature with any team members regardless of design expertise.

Who

  • 5 – 8 people recommended 
  • Larger than 8 could be wise to run parallel sessions

Supplies

  • Pens 
  • Pencils
  • Felt-tip markers or similar
  • Highlighters (multiple colours) 
  • Sketching templates (can be blank sheets of A3 divided into 6 segments) 
  • A1 self-stick easel pads
  • Dot stickers 

Process

  1. Problem definition and constraints 
    • Ensure everyone is aware of the problem you are trying to solve
    • Everyone understands the assumptions 
    • Everyone knows the users you are serving
    • The hypotheses you’ve generated
    • Constraints in which you are working
  2. Individual idea generation (diverge) 
    • Give each person a sketching template
    • If people find prospect of a blank page daunting optionally add a step whereby everyone writes the name of a persona/ pain point in each one (can repeat) and spend 5 minutes doing this
    • Give everyone 5 minutes to generate 6 low-fidelity sketches of solutions
    • These should be visual articulations, not words
    • If you can draw a square, a circle, and a triangle you can draw any low-fidelity diagram
  3. Presentation and critique 
    • 3 minutes per person
    • Go around the table
    • Each person holds up their sketches and presents them to the team
    • Presenters should state who they were solving a problem for and which pain point they were addressing and then explain the sketch
    • Each member of the team should provide critique and feedback to the presenter
    • Feedback should be focused on clarifying the presenter’s intention – no opinions allowed as they get people defensive and provide little clarity
      • How does this address the persona’s problem?
      • I don’t understand that part. Can you elaborate?
  4. Iterate and refine in pairs (emerge) 
    • 10 minutes
    • Each pair has an A3 sheet
    • Pair up (it is a good idea to pair up with someone with similar ideas if there is someone)
    • Each pair will be working to refine their ideas
    • Goal is to pick ideas that have the most merit and develop a more evolved, more integrated version of those ideas
    • Get more specific here, more details
    • Once time is up do the Present and Critique section again
  5. Team idea generation (converge) 
    • 45 minutes 
    • The team must converge on one idea 
    • The goal for this idea is to be the best for success an to be the basis for forming an MVP and running experiments
    • Use the easel pads or a whiteboard for the idea
    • Sketch components and workflow
    • Will need to compromise and pare back features 
      • Any ideas that don’t make the cut this time go into a parking lot to make it easier to let go of ideas
    • Put the output of this in a visible central place 

References

  1. Lean UX by Jeff Gothelf, pg 52 – 57

UX
Personas
User Interviews
Posted in Product

User Interviews

Posted on by beckycarter

Who to Interview

How many customers should I test with? (2, page 144)

  • Focus groups lead to participants not being fully honest 
  • Interview between 5 and 8 is a good balance

How to recruit in target market? (2, page 148)

  • Refer to personas created to help with writing screener questions 
  • Ensure to cover all of the segmentations you used forming your target market
  • Use conferences/ networking events

Starbucks User Testing (2, page 151) 

  • Low cost and immediate
  • Harder to screen for the customers that you actually want (demographic)
  • “Hi sir, do you have 10 minutes to share your feed back on a new website in exchange for a £20 Starbucks card?
  • More success found in shopping centres than Starbucks as people tend to have more time to kill

How to Interview

In-person, remote, and unmoderated user testing (2, page 145)

  • Moderated tests have the customer perform the test on their own, but recorded for the moderator to view afterwards
  • In-person allows richer data collection (body language)
  • Remote – be aware of technology issues of screen sharing 
  • Unmoderated can product a quick turn around as providers already have users lined up ready 

Question Guidance

Open vs Closed Questions (2, page 158)

  • Open usually begin with why, how and what 
  • Closed questions limit the customer’s possible responses (e.g. to yes or no)
  • Tip to write the questions down in advance to check they are open

Non-leading Questions (2, page 158 – 160)

  • Be careful not to tell the user how you would like them to respond, e.g. ‘how would you prefer it to be sorted? By date?’  
  • Be ok with long pauses and don’t help them as it will invalidate the test. Real users won’t have you to help them.
  • Don’t predict what the customer will say out loud and try to recede into the background to get the most honest feedback

Measuring Importance and Satisfaction (2, page 59)

  • A bipolar scale goes from negative to positive (i.e. satisfaction)
  • A unipolar scale is a matter of degree (i.e. importance)
  • More than 10 choices is overwhelming
  • Fewer that 5 will lack granularity
Unipolar Example
  1. Not at all important 
  2. Slightly important 
  3. Moderately important 
  4. Very important 
  5. Extremely important 

Bipolar example 
  1. Completely dissatisfied 
  2. Mostly dissatisfied 
  3. Somewhat dissatisfied 
  4. Neither satisfied nor dissatisfied
  5. Somewhat satisfied 
  6. Mostly satisfied
  7. Completely satisfied

Product Market Fit Question (Sean Ellis) (2, page 231)

  • Do not invest in trying to grow a business until after you have achieved product-market fit
  • This questions helps you assess if you have achieved product-market fit
  • Survey users and ask:
    • “How would you feel if you could no longer use product X?
      • Very disappointed
      • Somewhat disappointed 
      • Not disappointed (it isn’t really that useful)
      • N/A – I no longer user (product X)”

Follow-up Questions (2, page 157)

  • ‘Echoing back’ is a useful technique – e.g. ‘I see you clicked that button. Could you tell me why?’
  • If user asks question, ask another question rather than replying with yes or no

The Data

Make sense of the data (1, page 103) 

  • Look for patterns 
  • Place outliers in a parking lot (outliers could form their own pattern with more data collection so don’t bin them) 
  • Verify with other sources (do people inside the office agree/ customer support staff seeing the same trend) If not your sources could have been skewed 

Feedback Table (2, page 162)

Feedback Structure (2, page 162)
  • Group into feature set, UX design, and messaging
  • Ask valuable and easy to use questions
  • Get overall scores to compare to next wave when improvements have been made

Regular Cadence

TIP – randomly schedule users on a routine basis so that you always have some ready to test with, rather than panicking (2, page 150)

Continuous Learning in the Lab: Three, Twelve, One (1, page 99)

  • Three users, by Twelve noon, once a week
  • The regular cadence ensures that you ‘test what you’ve got’ so that there is no deadline pressure
MONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAY
Start with the recruiting process
Decide what will be tested		Refine what will be testedRefine what will be tested
Write the test script
Finalise recruiting		Testing day
Review findings with the entire team		Plan the next steps based on findings
Three, Twelve, One Sequence (1, page 99)

References

  1. Lean UX by Jeff Gothelf
  2. Lean Product Playbook by Dan Olsen

Explore more


Personas
User Testing
User Stories
Posted in Product

UX

Posted on by beckycarter

UX Principles

Two Elements of UX Design (1, page 115)

  • Great UX design = Usability + delight
  • Usability = can customers use your product?
  • Delight = do customers enjoy using your product?

Olsen’s Law of Usability (1, page 113) 

'The more user effort required to take an action, the lower the percentage of users who will take that action. The less user effort required, the higher the percentage of users who will take that action.'

Gestalt principles (1, page 136)

Principle of proximity – the brain perceives objects that are closer together as more related than objects that are farther apart

Principle of similarity – the brain perceives objects that share similar characteristics as more related than objects that don’t share those characteristics

Visual Hierarchy Design Principle (1, page 136)

  • The brain assumes larger objects are more important and smaller objects are less important 
  • Elements with high contrast (e.g. items that ‘pop’) are more important 
  • Position also affects visual hierarchy (e.g. for people who speak English the top left is the most important as that is how we read) 
  • To determine visual hierarchy squint at the page you will be able to identify the most important design elements

Principles of composition (1, page 137) 

  • Unity – does the page or screen feel like a unified whole or a bunch of disparate elements?
  • Contrast – is there enough variation in colour, size, arrangement, and so forth to create visual interest?
  • Balance – have you equally distributed the visual weight (position, size, colour etc) of elements in your design?
  • Use of space – how cluttered or sparse does your design feel? Ensure there is enough white space so that it doesn’t feel crowded.

UX Components

UX Design Iceberg (1, page 116)

UX Design Iceberg (1, pg 116)
Conceptual design (1, page 117)
  • This is the core concept you are using to design your product 
  • E.g. uber’s is based around a map
Information Architecture (1, page 120)
  • How the information and functionality should be structured 
  • Findability – how easy it is to find what the user needs (test this) 
  • Sitemaps are tool used to define the structure
Interaction Design (1, page 123)
  • Specify user flows 
  • What actions can the user take?
  • Including error messages and slow response flows
  • Flowcharts are a tool for mapping flows 
  • Wireframes are tool for testing
Visual Design (1, page 129)
  • Colours/ font/ graphics have emotions for user
  • Style guide used to ensure consistent feel 
  • Layout grids used to ensure consistent alignment of the design (e.g. divide the desktop screen by 12 sections which is then used to put all the nav options/ content boxes in line with) (page 133)
  • Mockups used to test this 

References

  1. Lean Product Playbook by Dan Olsen

Explore more


Personas
User Testing
User Interviews
Posted in Scrum Add-ons

Product Backlog Refinement

Posted on by beckycarter

Overview

Definition: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

Length: “Refinement usually consumes no more than 10% of the capacity of the Development Team” (1)

People: Product Owner, Development Team

Outcome: Product Backlog items become more transparent through refinement and the top items are deemed ‘Ready’ for a Sprint (i.e. can be ‘Done’ by the team within one Sprint)

Benefits

Product Backlog Refinement Benefits (2, page 103, Mastering Professional Scrum)

  1. Increased Transparency – adding details for what you plan to deliver, and your progress
  2. Clarification of Value – outcomes of what you are trying to achieve become clearer, and helps the team to build the right thing
  3. Breaking things into consumable pieces – increases flexibility for the team to meet ‘Done’ in a Sprint
  4. Reduction of dependencies
  5. Forecasting
  6. Incorporation of learning – gained learning is incorporated into the product

Facilitation Techniques

Fishbowl collaboration (3)

  • Three – five people collaborate around a whiteboard (the fish in the bowl)
  • Others in the room may observe but are not allowed to speak
  • If someone from outside the bowl wishes to speak they can dive into the bowl which bounces out one of the fish already in the bowl
  • People can leave anytime if they are not finding it valuable
  • This technique keeps the conversation small and productive

Three Amigos and BDD

  • Backlog Refinement is attended by someone to represent each discipline in rotation (i.e. Three Amigos of Product, Development, Testing)
  • Behaviour Driven Development is used to focus the conversation on the behaviour of the User Story
  • See my talk notes

References

  1. The Scrum Guide
  2. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  3. User Story Mapping by Jeff Patton

Explore more