Posts

Agile Retrospective: fire extinguisher or mop up (30 - 60 minutes)

Image
Do you have a list of things decided or agreed in previous retrospectives that still haven't been moved forward. It's easy in a sprint to focus on today's problems, and forget about what we said yesterday. I've certainly been guilty of this. Apart from keeping a retro log of all the actions that are decided in a retrospective, it can be useful once in a while to revisit things that have been discussed and agreed previously, but are still outstanding. This retro allows teams to reflect on the problems and decision that were made over the past few months, and decide whether they're still an issue - and if they are, what to do about it. Setup Draw a fire extinguisher, and surround it with empty sticky notes On another section of the board, draw a bucket and mop On sticky notes, write a short summary of decisions / actions agreed in previous retrospectives that are still outstanding. Stick these around the bucket and mop. Instructions Ask the team - "are there any ...

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter Eight: Priorities

Chapter Eight: Priorities 80 percent of a product's value is found in 20 percent of its features, so build those features first and deliver them to your customers as fast as possible Quick Summary You want to start delivering to your customers as soon as you possibly can 80 percent of the value is in 20 percent of the features - the trick is building the 20 percent first To prioritise the backlog, ask yourself which items have the biggest business impact, mean the most to the customer, and are the easiest to complete Main Points To get started with Scrum, the first step is putting together a backlog and a team. Initially, just get a week's worth of backlog ready. Gradually build up the backlog until it holds everything that could possibly be included in the product. The trick is deciding what to work on first. 'You want to start delivering value to your customers as soon as you possibly can.' Product development has repeatedly shown that 80 percent of the value is conta...

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter Seven: Happiness

Chapter Seven: Happiness Teams can quickly triple their productivity by understanding what will make them happier and focusing on one small improvement each sprint Quick Summary Triple team productivity over just a few sprints simply by asking them what makes them happier and acting on it Quantify happiness - be scientific about it and compare it to actual performance. Happiness is a predictor of future performance. At the end of each sprint, use a 'retrospective' to identify one small improvement that will make the team happier, and figure out how to measure success in the next retro. Main Points 'People aren’t happy because they’re successful; they’re successful because they’re happy'. Not only does happiness predict future performance, but performance improves even if people are only a little bit happier. Therefore, teams should ask themselves the following questions at the end of each sprint. 1. On a scale from 1 to 5, how do you feel about your role in the company?...

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter Six: Plan reality, not fantasy

Chapter Six: Plan reality, not fantasy Plans almost always describe a fictional reality, so only plan for the next increment of value and estimate the remainder of the project in larger chunks Quick Summary Estimates of work at the beginning of a project range from 400 percent of the time taken to 25 percent of the time take (as plotted on the cone of uncertainty) Humans are terrible at estimating, but good at comparing the size of one task to another Use planning poker to estimate tasks, and at the end of a sprint you'll know your sprint velocity (the pace at which your team gets through work) Main Points Projects tend to accumulate documentation as people cut and paste and throw in boilerplate. This leads to thousands of pages outlining requirements, compliance, reports, phase gates and quality assurance. Buried among it all somewhere is what actually needs to be done. Capture these on sticky notes, and estimate how long each will take. Then prioritize the work. People will say e...

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter Five: Time

Chapter Five: Waste is a crime Waste can be minimised by teams tackling one project at a time, not delaying bug fixes, and preventing people from working more than forty hours a week Quick Summary Teams should tackle one project at a time to limit the amount of efforted that is wasted switching focus Teams should fix problems when they arise - if bugs are dealt with straight away they can be fixed in a fraction of the time Don't let team members work more than forty hours a week - they will actually get less done  Main Points The main causes of waste at work are multitasking, work in progress, not fixing problems when they arise, working long hours, and various forms of unreasonableness such as setting unreasonable goals and expectations. In particular, studies have shown that humans are terrible at multitasking. The same is true of teams. If a team works on two projects simultaneously, 20 percent of their time is wasted on switching contexts. Working on five projects simultaneousl...

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter Four: Time

Chapter Four: Time Working in sprints allows a team to deliver something quickly for customer feedback, while the the daily "stand-up" allows teams to communicate efficiently. Quick Summary Break your work into small chunks that can be completed in a regular, set, short period (2-4 weeks)  At the end of each short period or "Sprint", have something that's done and can be demonstrated to stakeholders  One meeting a day - get together for fifteen minutes and identify how to speed things up Main Points There are two main elements of how a Scrum team works - the "sprint" and the "daily stand-up". A sprint is a time box of a set duration (e.g. two weeks). It also has to be consistent - you don't do a one-week sprint and then a three-week sprint.  At the end of the sprint, the team needs to deliver something that can be used by the customer. A key part of helping to team achieve this is the daily "stand-up". this is a 15-minute meetin...

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter Three: Teams

Chapter Three: Teams A good team can outperform a bad team by a ratio of 2000:1. They do it by being transcendent, autonomous and cross functional. Quick Summary The best teams have three key characteristics: transcendent, autonomous and cross functional Organisations should focus on improving team performance rather than individual performance, it has much more impact Once teams grow larger than eight they take dramatically longer to get things done Main Points Talented individuals outpace their peers by a ratio of 10:1. But the fastest teams outpace slow teams by a ratio of 2000:1. So there is a much larger difference in team performance than there is in individual performance. Furthermore, when a team grows larger than eight, its performance dramatically decreases . Groups made of three to seven people require about 25 per cent of the effort of groups of nine or twenty to get the same amount of work done. The brain can't keep track of what everyone is doing, so we slow down as w...

Book Chapter Summary | Scrum: The Art of Doing Twice the Work in Half the Time (New York, 2014) by Jeff Sutherland - Chapter Two: The Origins of Scrum

Chapter Two: The Origins of Scrum The Scrum development process draws on the findings of a 1986 Harvard Business Review paper, which looked at how product development teams worked in some of the most high performing companies Quick Summary Great teams are cross-functional, autonomous, empowered with a transcendent purpose Look outward for answers - complex adaptive systems learn from their environment Follow the principle of Shu Ha Ri - learn the forms and rules, then introduce innovations, before living the forms and rules effortlessly Main Points The Scrum development process emerged from the findings of a 1986 Harvard Business Review paper. The paper concluded that the traditional waterfall approach to product development was fundamentally flawed. Instead, the world’s most productive and innovative companies had teams that were cross-functional. The teams also had autonomy to make their decisions, and shared a transcendent purpose bigger than themselves. Managers were servant leader...