A bit more Scrum lore

When we created Scrum back in the early 90's, we sequestered ourselves in an office park in Burlington, Massachusetts sufficiently protected from the blustery New England winter. We were trying to build something different. And we knew we had to do it in a different way. Jeff Sutherland had already discovered some previous art on new product development (Takeuchi and Nonaka. The New New Product Development Game. Harvard Business Review, 1986). In this paper the authors used scrum (among others) as a metaphor for new product development. They discuss how like in a rugby scrum, the product development team moves toward a goal. Well perhaps the authors played or watched a different version of rugby than I was familiar with! A rugby scrum is brutal. Opposing teams come together fight each other to influence the progress of the ball. Ears are bitten. Fingers are broken. While there needs to be "healthy tension" in product development, I winced at using "Scrum" as a name and metaphor for the method we were building. I got over it and got on-board with Scrum.

So, what about "Sprint". I knew my team needed to deliver incrementally. Incremental development had already emerged as an effective approach for software development. And, I knew my team had to move fast. So, we started sprinting and used "Sprint" as name of what we called our increment. In the early days, we adopted a 30-day sprint. It seemed about right and was convenient and memorable planning interval length. We established some rules to protect the team as well. While we embraced the notion of changing requirements, we pushed back hard on changing the contents of the sprint and had our product owners only make these changes on Sprint boundaries.

We didn't have "User Stories" back in the day. But we did have the backlog and backlog items that comprised all the known work that the team needed to complete. I still remember building the first backlog. It hurt. Here I was, a relatively junior software development manager tasked with leading a team in the development of a new strategic product for Easel Corporation. I had to coordinate both the product and project management for a product that we barely had a vision for. I concluded quickly that a Gantt chart was not only impossible, but a gross waste of time as it would be changing as fast as I could build it! But I knew I had to capture planned work, and get my team focused on the most important stuff. And that’s where the backlog came from. I just started documenting the backlog items with priority, risk and effort, and using that backlog to drive the sprints. And yes, I actually used a tool to do this. Borland Quattro Pro! A fine character mode spreadsheet that has been left in Microsoft's dust.

We made lots of refinements as we moved through Scrum's very first sprints. Synch-Steps and the metronome to name a few. There were lots of contributors as well. Here was the team:

  • Deb Abberton - Software Developer
  • John Dove - VP of Engineering
  • Gerd Eisenmann - Software Developer
  • Laural Ginder - Quality Assurance
  • Joe Kinsella - Software Developer
  • Jeff McKenna - Consultant
  • Don Roedner - Product Marketing Manager / Product Owner
  • John Scumniotales - Software Developer / Scrum Master
  • Jeff Sutherland - VP of Technology

All of these people played some part in the creation of the first Scrum. Jeff Sutherland took the work we did at Easel and worked diligently with Ken Schwaber and others to commercialize Scrum and evangelize its use. Its widespread adoption and success are certainly a result of their persistence and hard work!

https://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/?sh=ca639e87782e


Comments

Post a Comment

Popular posts from this blog

Be agile about agile!

The democrats and republicans are doing a fine job of "fire-bombing" the centrists in both their parties (I grabbed that quote from an article "It's not easy being George" in this month’s Vanity Fair). And, as I scan the agile groups and blogosphere, it seems the methodologists are doing it as well. Some of us take the "extreme" in extreme programming too literally, and others are holding on to some of agile developments long disproved stigma for far too long. My approach always has been (and hopefully always will be, unless of course I turn out like my father, which all of us eventually do...) a pragmatic one. There are many things I love about Scrum and agile - driving elaboration and development off the backlog, test-driven development, burndown charts, and much more. And there are a some that I could do without (self-organizing teams, developers and testers are interchangeable, ... I blog on these later). An agile approach needs to be tailored to y...
Read more

When Do You Need Agile Product Portfolio Management?

Image
First, let’s define Agile Product Portfolio Management. Agile Product Portfolio Management is a dynamic approach to managing a company's suite of products. It involves continuously evaluating and prioritizing products based on shifting market demands, customer feedback, and business goals. It integrates principles of Agile methodology - such as flexibility, rapid iteration, and cross-functional collaboration - into portfolio management. The focus is on adapting quickly to changes, making swift decisions based on current data, and ensuring that resources are allocated efficiently to maximize product success and overall business value. It's about maintaining a balance between long-term strategic vision and short-term market realities, ensuring the product portfolio remains relevant and competitive.  Agile Portfolio Management is needed when your business and product line achieve a size, complexity, and maturity where decisions can no longer be locally optimized for individual pro...
Read more