Part 1: Q&A with CEO Sam Minnée about Agile at SilverStripe

Guest blogger Sandy Mamoli is one of NZ's leading Agile advocates, a Certified Scrum Master and became New Zealand's first Certified Scrum Practitioner in October 2007. 

One of her major Agile initiatives was working on Sony Ericsson’s global enterprise website. She has also worked with organisations such as the BNZ (Bank of New Zealand), the ACC (Accident Compensation Company), NZ On Screen, the National Library of New Zealand and Snapper.

Currently she is working as an independent Agile Coach helping organisations become passionate about Agile and Lean principles and methods, and to be as Agile as they possibly can and want to be.

When SilverStripe approached me to help them take their Agile implementation to the next level, I was excited about the opportunity to work with this local Wellington business with employees from a wealth of different countries.

SilverStripe wanted to improve the way in which they deliver client projects, increase employee happiness and, in general, just do the best possible job. To achieve this, we decided to move away from the existing Agile-like approach and introduce Scrum, with its focus on client-driven iterations, early feedback and continuous improvement.

During the past six months I have been working with sales, management and delivery teams to help SilverStripe adopt Scrum right across the organisation, and to make it the core of everything they do.

In this three-part series, I will interview the CEO, a Scrum Master and a Developer. We’ll talk about their experiences including the biggest surprises, differences, and how they found the changes working out for them.

Today’s conversation is with SilverStripe’s CEO Sam Minnée.

Sam, what was the main thing you wanted to achieve? Did you achieve it?

Although SilverStripe has favoured an Agile approach over waterfall methods for some time, we wanted to introduce more structure around our development and project management processes. As we are now successfully running the bulk of our work with Scrum, I would say that we have achieved it.

What is different now?

Prior to the change, we had a different set of people for each project. Everyone would work with several different groups of people on several different projects. This made it easier to find resources for projects, but it was subtly killing the team's sense of ownership of a project's success. Despite it being painful (many people had to be moved onto new projects and be taken off old ones) we made the decision to re-shape our developers, designers, and PMs into four consistent delivery teams, that collectively work on all the projects assigned to them.

Now developers and designers are much more invested in the big picture of the work they do - it's not all up to PM’s anymore.

What are you more confident about now?

Teams have a much more accurate picture of a realistic amount of work, and so I'm more confident about our capacity.

Why did you choose to engage outside help and how do you think you benefited from working with a coach?

In short, we wanted a fresh perspective. We could read books about Scrum or send staff on training courses, but this would have only gone so far. It was difficult for the SilverStripe team to see outside of the way we run projects, and it's easy to say "oh, that's a nice idea, but it would never work in practice", when challenged to make more dramatic changes.

Sandy has helped introduce Scrum and other Agile techniques and principles to many different organisations and was able to provide assurance that we weren't going to go down an unrealistic path. The result was that we could confidently make more dramatic changes to the way we run our business.

What did you have to learn? What was the hardest to learn?

The biggest lesson was that a change in attitude is more important than the process. The process is designed to encourage the emergence of correct attitudes. One major shift for us was the notion of delivering production-quality software at the end of every Sprint. It is very easy to fall into the trap of leaving polish and testing for a "stabilisation phase" at the end of the project, or to enter into a massive piece of work that, like a jigsaw, is completely useless until the last piece is put in place. It didn't really seem like that big of a deal to us, but it subverts the whole process. At its core, Agile is about accepting that things aren't going to go to plan, and constantly being in a position to launch with what you have. Requiring a stabilisation phase or leaving mandatory features until the end mean that you introduce the risk that you are leaving a show-stopper dormant until then.

Would you recommend Scrum and Agile to others?

Yes, I would. I strongly believe that Agile techniques are much more likely to result in a successful project than traditional waterfall techniques. However, I would caution people not to assume that it will be a quick fix or a change limited to the development team. In particular, stakeholders need to find new ways to manage the risks associated with engaging in a software development project; you cannot expect that provided a detailed specification, a fixed timeframe and budget can be adhered to. It would be great if that worked, but projects approached in this way frequently fail. Instead, a team needs to keep focused on finding out the best way of meeting the project's high level business drivers within the project's constraints, as unexpected issues arise. That way you can ensure that business goals are met within the necessary timeframes and budgets.

In part two, I will talk to Scrum Master Aleksandra Brewer who works with one of the Agile teams at SilverStripe.