ScrumMaster offers tips on how to play in a winning dev team

John Scumniotales

Scrum is a software development process most commonly associated with agile software development projects. The name “Scrum” derives from how the different phases of a project overlap, with the entire process handled by a cross-functional team across the different phases, similar to a game of rugby, where the whole team acts as a unit, passing the ball back and forth. Often described as “a process skeleton”, Scrum methodology breaks development work into ‘sprints’ (two-week chunks) and the team then works together to determine which ‘user stories’ (requirements) from the ‘product backlog’ make it into each sprint.

Scrum also includes a set of predefined roles, which include the ScrumMaster, who maintains the processes and acts like a project manager, the Product Owner who represents the stakeholders, and the Team which includes the developers.

John Scumniotales, currently the vice president of research and development and application lifecycle management (ALM) products at Serena Software, was the first dedicated ScrumMaster back in the mid 90s. Scumniotales worked on the Smalltalk IDE product at Easel Corporation, where Scrum was incubated under Jeff Sutherland, along with assistance from Ken Schwaber. Computerworld’s own resident ScrumMaster, Lorraine Pauls Longhurst, recently caught up with Scumniotales during his visit to Australia to present a series of “Agile in the Enterprise” roadshows on behalf of Serena.

You were involved in creating Scrum, what is your connection with Jeff Sutherland and Ken Schwaber?

Back in the early 90s I was working at a company with them called Easel Corporation in Burlington, Massachusetts. I reported directly to Jeff Sutherland and my team was building a tool that was targeted at the client server/object-oriented space. We knew that we needed some kind of a rapid, incremental approach where we could build out some features, validate they were correct and then organically extend the growth and the product offering. There was a lot of market pressure — we wanted to get something out quickly, so again that lent itself to an incremental model.

So time-to-market is partly what initiated it?

Time-to-market and incorporating stakeholder feedback were some of the drivers that forced us to take the incremental approach. We recognised if we were going to build something fast, we had to build testing in, and we had to have the product manager or customer rep embedded in the team, so we created a collaborative team result.

How did you come up with some of the more structured rules to Scrum, things like the 15 minute meetings and that kind of thing?

The daily stand-up meetings are what you are referring to. Fifteen minutes or less — in fact 15 minutes is the max. Again it was communication; the process relies on direct communication with team members over formal documentation.

Thinking back to my time as a product manager, I was always pressuring the developers to get as many features into the release as possible.

The healthy tension between development and product management. . .

Yes, of course. How to do you think Agile would have helped in that kind of scenario?

In Agile, the product owner (or product manager) engages with the whole team during sprint planning. They come in there with the user stories for that sprint and the team collaboratively produces estimates — “Here is our capacity, and you can put whatever work you want the team to accomplish within that sprint, but there is only so much the team can do”. It becomes very visible, as opposed to a product manager dumping a 200-page requirements document on the team and saying ‘I need it in six months’.

I found that when the developers attempted to get more done than was possible, the quality would suffer. How does Scrum address this?

One of the critical success factors for agile is applying what is called a ‘test-first’ approach. When we define the user stories — again the user stories are defining the requirements for what is going to be built in the sprint — a critical element is the acceptance test. In order to consider a user story as completed within a sprint, the product owner has to declare that the acceptance criteria have been met.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark