Scrum

Scrum data points on how to increase Velocity

This past week I had the good fortune to be trained on Scrum@Scale, a framework for scaling Scrum, by the creator of Scrum himself, Jeff Sutherland. It's not a prescriptive framework like some of the others. It's built on true Scrum and it reminded me how a lot of the problems companies face is because they aren't even doing basic Scrum right. So when they do scale, they scale up a broken system. If you start with garbage, you get more garbage.

What's great about training with Jeff is that he has so much scientific data and case studies to back it all up. Several of these studies have proven that you can double velocity (you read that correctly!) by using Scrum patterns for teams.

Here are some of the patterns for doubling velocity:

  • Co-location
  • Small teams
  • Stable teams
  • Dedicated teams
  • T-shaped team members
  • Daily Scrum
  • Interrupt buffer
  • A Ready backlog
  • Fix bugs found within a day
  • All testing completed inside the sprint

All of these have data points and studies and research to back it up. I'll cover just a couple below.

The Impact of Agile Quantified. Rally Software Development Corp. 2015

Dedicated Teams

Let's look at one of the patterns, dedicated teams. A study by Rally Software (before they were bought) showed a huge increase in productivity when team members were dedicated. Teams that had members 50% dedicated produced around half as much as when teams had members 95% or greater dedicated.

Small Teams

http://www.qsm.com/process_01.html

If we look at Brook's law on cost and time to deliver based on the team-size there is a huge difference. Look at the team size of 10 people vs 6, vs 4 and the cost they incur. The Team Size of 6 was able to deliver in twice the time of a team of 10 or 17.

Swarming & Context Switching

Let's just look at one more - swarming, and focusing on one or more projects. 

 Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.

Weinberg, Gerald M. (1992) Quality Software Management: Systems Thinking. Dorset House, p. 284.

Working on 5 projects at the same time can yield up to 75% waste - that is a lot! Most people have what, an average of 3 projects? That's still 40% loss! This loss necessitates more people to make up the difference. Save money, use fewer people to do the work in a less time.

There are many more studies and patterns that increase a teams's velocity and reduce the company's cost, proving that implementing Scrum correctly is the only way to get ahead of your competition. As Jeff likes to say. "Change or die." Change the way you do work, or your competition is going to take you out.

Real World Examples of Project Status and Updates on an Agile Project - Webinar

Real World Examples of Project Status and Updates on an Agile Project - Webinar

I get often asked when I work with people or teach a class how to show real progress on an Agile project. Roadmaps, Release Burnup's, Velocity, how to answer questions on delivery. We build products for external clients using Scrum and will show people how we visualize progress sprint by sprint for our customers. Showing how velocity changes, roadmap, release plan changes and most importantly how customer feedback has affected the release date. This isn't hypothetical talk but real world experiences and conversations.

 

However, first I will start out with showing the old ways of doing things with Gantt charts. Why the traditional way doesn't work. Comparing the Green, Yellow, Red method and how it doesn't work. The roll that into the better, agile mindset of delivering questions like when will be done, what will we get and how we communicate good and bad news to our clients.

An easy way to Automate your UI Testing without the programming skill

An easy way to Automate your UI Testing without the programming skill

Scrum isn't easy, but it's effective. One of the things that teams struggle with is a way to automate their testing and learning techniques like Test-Drive Development or Behaviour-Driven Development.  Both which can be implemented in both the back-end and the front-end code.

One team, I work with also automates the UI testing. One tool they use and they include as part of their Definition of Done for each feature is building a test automation using...

Running an Effective Retrospective Meeting

ou want to run an awesome Retrospective meeting but you really don't know where to start. I've found that a true Retrospective is about learning from mistakes made during the sprints;  how to improve the team while increasing velocity where possible, and deciding what works and what doesn't.  All that made sense to me intellectually, but in reality, trying to accomplish these things sometimes, is not as clear.