Where do you sit as your Agile team's designated business expert?

Where do you sit as your Agile team's designated business expert?

"You're doing it wrong!"

If I had a dollar for every time I've heard an overbearing Scrum Master, misguided "Agile expert" or overzealous individual claiming to be an Agile coach say these or similar words, I'd be a rich man indeed.

What is right or wrong is often situational in Agile. The Scrum Master who insists that you must sit with the team may or may not be correct as to where you would be most effective. The idea that there is one and only one correct answer to the question of where you should sit is too simplistic.

Read More

Scrum Beyond Software

Jeff Sutherland led the team that invented Scrum at Easel Corporation in 1993 as a response to daunting request to replace all of the company's products with a single product -- within 6 months! In the couple of decades since this first Scrum team, the Scrum framework has become the most predominant Agile development approach in the world. Scrum has become so popular that there are frequent calls to apply Scrum beyond software. After all, why should the software development folks have all the fun? What I find interesting is that Scrum has in some ways come full circle. Sutherland writes in The Scrum Papers that Scrum was born of complex adaptive systems (ant colonies, flocks of birds, etc.), lean thinking (Toyota, Honda), knowledge management strategy (Takeuchi and Nonaka (The New New Product Development Game, HBR 1986) and Peter Senge (organizational learning). These disciplines, absent from most software development teams in the early 1990's, are now ubiquitous among those software teams practicing Agile development.

But, wait a minute! If these practices were rare in early 1990's software development, where were they? As Takeuchi and Nonaka's 1986 HBR article point outs, the best product development organizations in the world were using the seeds of Scrum to create... products!... such as copiers, cameras, engines. It's right there in article title:  "The New New Product Development Game".

Now, back to Agile... the Agile software development movement has sometimes forgotten that software is not always the whole product. While Takeuchi and Nonaka's exemplary products might make use of software, the product whole is a sum of its parts. Software alone does not make the product work.

Lean thinking (another Agile seed) would tell us to consider the whole value stream. The value stream considers everything that must happen along the way from the initial idea to the working product. Software is rarely the only item in the stream. The fundamental elements of Scrum (inspect, adapt, and transparency) and the practices (prioritization, planning, synchronization, review, retrospective) are not exclusive to the software development aspects of the value stream. In fact, the value stream could contain no instance of software development and Scrum could still add value.

What it comes down to is this:  Scrum is a team-based framework to develop complex systems and products. If this sounds like a fit for you and your team, give it a try. Software is optional.