Digital

Why Agile?

June 6, 2014 by Jono Ellis No Comments | Category Digital Public Services, mygov.scot

Why Agile?

To a lot of people, Agile is just a fad, a new approach to software development that keeps post-it makers and whiteboard marker manufacturers enjoying the good life. It may work for start-ups, Google and Facebook type organisations but it won’t work here. It’s a passing fad like Six Sigma, Total Quality Management (TQM) or Quality Circles.

To others, there’s no better way to develop software – or to run most kinds of projects or operations for that matter. Why not build only what customers really want rather than everything specified? Do people really know every detail of what they want 18 months before a system is built? Can you predict how every sub-system will interact in advance? Why have creative people working in isolation from each other? Why leave testing until the last minute? Why not tackle the hard bits early? Why repeat routine rudimentary tasks when you can automate them?

As you might guess, I’m strongly in the second camp.

I’m not going to tell you what Agile is – there are lots of great books written on the subject and some excellent web resources that you check out here that can explain it a lot better than I will. If you’re interested, you can read here about some of the techniques we’ll be applying over the next few months. What I’ll write about is why we are using Agile.

Software development

Software development is a creative process. Too often people think of software development as similar to building a house or a manufacturing plant, where an architect creates a design for different trades to implement sequentially, or where a product runs through a conveyor belt of sequential processes of analysis, design, development, test and release.

It doesn’t work like that.

In software development, without constant inspection measurement and change, you’ll end up with lots of requirements built, but not necessarily the ones people need or want.

Software development is more like Research and Development (R&D). It requires space for experimentation, prototyping and continuous feedback. This seemingly free-spirited side that people see in Agile projects (discussions at whiteboards, user testing, use of new technologies) has to be coupled with rigorous engineering practices, automated testing, lean continuous improvement techniques, commitment to the team and batch size management (I’ll explain that one another time).

Prototypes

Ideas need to be assembled quickly. In manufacturing R&D, this has been done really successfully for a long time by companies like 3M and Toyota, where cross-functional teams work together to come up with prototypes and work them through to production.

The prototyping process isn’t a single shot at glory. It’s an iterative process based on feedback. Get customers to tell you if they would like an idea, what they might pay for it and what they don’t like about it.

Prototypes are built, tested, changed and retested, tweaked and retested. A prototype may be really well-received by the customers, but feedback from production specialists may indicate it’s not economical to build. The prototype is reworked and tested again.

Valuable information

This may seem wasteful to some. A lot of ideas fall by the wayside – a lot of work isn’t “used” – it’s an inefficient use of labour. Why not design up front and build? It’s because information is valuable.

Building the right thing is better than building the wrong thing well. A lot of new ideas are introduced and bad ones removed before moving a prototype to production. A lot of the best features come from seeing something in action and thinking it can be done better.

While the kernel of the original concept may have come from market research, a rival’s product or maybe a brainwave from an engineer, the product produced is a result of the creative genius of the team (including users) working together. In mygov.scot we want to use that creative genius.

We want to harness the ideas and skills of diverse people. These include end users (lots of them), Scottish Government strategists, developers, user experience designers, content authors, business analysts, technical architects, testers, representatives of government bodies, infrastructure specialists and others like security specialists, and digital publishing experts.

Agile techniques provide us with the means to bring all of the ideas and talents of these people together to build a great product. We’ll start by having cross-functional, co-located teams with a flat structure. We’ll make all of our work visible so that people can discuss it, share ideas and add to the intellectual property being assembled.

Testing

We’re going to test our ideas as early as possible and as often as possible – both technically and functionally. We’ll start shedding bad ideas quickly and harvesting good ones. We’ll create a large panel of volunteers to give us feedback on what we’re building. If you’d like to take part send us an email: OSSD@scotland.gsi.gov.uk

We’ll be testing fortnightly as this’ll keep informing the team of what’s required and continuously train our sights on the target. We’re going to test out our architecture early too by building a part of the system end-to-end in our Alpha, (this is the equivalent of our production manager testing the economic viability of producing our prototype).

We’ll apply a discipline to our development that gives us the comfort to apply changes cheaply – this’ll be achieved through automated testing practices, continuous integration and continuous delivery. These practices will enable us not just to get development feedback, but to get our products into the hands of the wider market sooner and verify they work.

Going forward

Don’t think that we’re going to continue applying marginal improvements of diminishing value to small areas of the mygov.scot platform. We’ve got a roadmap of features we want to build based on the value we think they’ll give to users. We’ll assess what value we get from improving a feature against adding a new one and will move on. To go back to the R&D analogy, we won’t keep working on the same prototype – we’ll get it manufactured and move onto the next product.

We’re excited about what’s ahead and ready to start building. Keep coming back here to see what’s happening.

Tags: Transformation

Comments