Guest post from Jeff Sutherland, co-creator of Scrum and CEO of Scrum Inc.
In case you missed it, earlier this month VersionOne broke record attendance (5,000 registrants) for our AgileLIVE webinar series. Jeff Sutherland keynoted the event with a focus on “doing twice the work in half the time” with agile and Scrum principles.
Jeff must have said something right because the attendee questions flooded in. Since we ran out of time to answer all of them on the live webinar, we asked him to answer the most common questions right here for you to learn and share. If you find these helpful, please download the full recording of AgileLIVE: “Getting to Done – The Power of Scrum.”
Q: Do we need some initial design done before we engage a developer?
A: The designer should be part of the team. How much design needs to be done should to be worked out in the team before coding begins? This question is similar to, “Do we need a tester before we can ship?” All people necessary to get to Done need to be on the team working as a team.
Designers struggle with this concept when they are not cross-functional and tend to work across teams. At Scrum Inc. we put a design expert on one team even if they have to help other teams.
Q: How is Story definition effectively managed? Is Story definition considered part of a Sprint?
Getting user stories or product backlog items in a ready state takes place during the previous sprint in product backlog refinement. The Team and ScrumMaster should expect to spend about 10% of their time working with the Product Owner to refine the stories for the coming sprint during the current sprint. We have tried to make this clear in the Scrum Guide at scrumguides.org.
Q: We know that Scrum can be applied outside of coding software. What generic term would we replace “Working Software” with in the Agile Manifesto for efforts that are not software development efforts? Working Deliverables?
Joe Justice leads our agile hardware practice. He uses this wording:
“The Agile Manifesto applies to all industries. When we read it and its 12 principles, and switch each mention of “software” with “customer visible value,” we have an elegant methodology that applies to all business.”
Q: We are applying agile and Scrum methodologies to marketing efforts (with adjustments for marketing). Have you ever worked with or witnessed agile in other areas beyond software? Do you think it works?
One of the driving motivations behind publishing my new book, “Scrum: the Art of Doing Twice the Work in Half the Time” was to show how effective Scrum could be in all industries. In fact 80% of the examples in the book are non-software related.
My company Scrum Inc. is a business services organization and we Scrum everything: marketing, finance, sales, and content creation. Many of the companies I work with use Scrum in marketing. Sometimes the marketing Scrums are better than the development Scrum teams.
Q: What are some of the approaches you recommend for getting to consistent story points, especially across teams?
Getting consistent story points across teams is not important. What you want to look at is acceleration across teams. Teams will estimate in ways that makes sense to each individual team.
However, Scrum Inc.’s Chief Product Owner Alex Brown has conducted a number of experiments. He found that dropping similar backlog items into different teams’ backlogs can give a Product Owner a pretty good idea of point variability between teams. He then estimates how long it will take to complete an epic that is being worked on across multiple agile and scrum teams.
For non-agile organization’s looking to transform, LeSS and SAFe might be good places to start. However, these prescriptive scaling frameworks can eventually become a major impediment as the organization’s agility matures. LeSS is closer to Scrum principles. SAFe adds extra overhead.
We talk about the basic components of scaling in our Scrum@Scale online courses at scruminc.com. There we describe where SAFe and LeSS might be useful. We also point out that scaling agile needs to fit the organization and its goals. A company like Spotify would not use prescriptive frameworks. Large companies we work with that start with SAFe soon find they need to change the organization and eliminate waste, which moves them beyond SAFe. Dean Leffingwell points out that SAFe is a starting point.
Scrum is fractal and based on Object Oriented Architecture. It was designed to scale. In fact, the first scaled Scrum pre-dates the Agile Manifesto by many years. It was similar to the approach Spotify uses today