The Art of Agile

10. November 2016

In this article, etventure’s Head of Product Gregor Ilg will take a closer look at the buzzword “Agile” – and de-mystify Agile in a business context.

Agile development has been around since the 90s, and became popular shortly after the turn of the millennium, when the Manifesto for Agile Software Development was formulated and signed by Kent Beck and 16 fellow software developers.

We love Agile at etventure – but we also understand it can create stress and confusion. If it is not applied properly, agile development can easily turn into chaos!

What is Agile?

As its name implies, Agile was created to provide agility in software development – and significantly improve product decision making by involving subject matter experts at all stages.

Before Agile

Before Agile, software development approaches placed an emphasis on predictability:

  • Define a detailed set of business requirements and functional requirements
  • Write a detailed functional specification
  • Secure signoff from the various business stakeholders
  • Commence development – which might take many months to complete

This traditional approach still has merit at times. But its main strength – predictability – is also the biggest weakness. It relies on the assumption that all necessary information (about the customer, the technology stack, the API, the frontend devices, the business model, etc.) are fully known when planning a software development project. In today’s fast-paced environment, this is rarely true. So a less rigid approach is needed – especially for long-term projects.

The Agile Ethos

Agile focuses on two key assumptions:

  •  Meeting user needs is the most important outcome in development – to reach product/market fit
  • Product/market fit may or may not be aligned with the initial specifications – and ultimately can only be achieved by iterating based on feedback

As a result, Agile is effective at producing highly usable and continuously improved software – that meets user needs exceptionally well. Another benefit of Agile – even at a very early stage of the production cycle there will be an assessable, potentially shippable product. No need to wait until the very final, completely polished release to find out what works for the user and what doesn’t – or to generate value and revenue. Finally, Agile also opens up opportunities for creativity and innovation during development.

Recognizing the Art

Imagine Francesco del Giocondo approaching Leonardo da Vinci in 1503 with the following assignment:

“Mr. da Vinci, we bought a nice house and would like to add some flair. So, could you please create an 77 x 53 cm oil painting of my wife Lisa – to beautify our hallway. Please make sure to only use the colors red, green, orange, blue and black. I would expect you to be painting 8 hours per day for the next 52 weeks. Please start with the background at the top of the painting. Then create the face, the body – and the hair should be painted last. Also please give me the specific details of your approach in writing beforehand – including a clear description of the final result, and schedule the following milestones: head, face, body, hair.”

This rather silly example highlights how traditional software development places constraints on developer creativity. If da Vinci had been given this brief, would we have the masterpiece that is “Mona Lisa”? Unlikely.

Of course everybody is looking to create a software masterpiece, but all this talk of artistry and freedom is likely to cause distress with your finance and procurement departments!

Managing Corporate Expectations

Everybody has heard of the project management triangle: “Fast, Good or Cheap. Pick Two!” This corresponds to the following questions that every business needs to answer:

  • How much will it cost?
  • How long will it take?
  • What is the scope?

With the classic approach it is assumed that only two of these variables can be optimized at the cost of the third. As it is more or less impossible to answer all of these questions accurately before starting a project, most traditional software development projects turn out to be somewhat disappointing. More often than not at least one of the three initial targets will not be hit.

The main problem is that “Scope” is defined as a combination of feature set and quality. With Agile it doesn’t have to be this way – as high quality does not automatically correspond to a previously defined feature set. In fact, if you remove the variable feature set from the equation, suddenly you will start producing software that includes the most valuable features – and hitting your targets  in quality, time and budget.

Scope

In Agile development, rather than creating a long list of features in a specification, a prioritized product backlog will be prepared with user stories – which highlight specific needs of your users. Updating the backlog on a regular basis by prioritizing those user stories – ranging from “must have” to “nice to have” – is fundamental to managing your Agile budget. Development then occurs in “sprints” – which are quick bursts of activity that produce working software based on backlog priorities, within clearly defined release cycles of 1-3 weeks.

User story example: “As user I want to be able to put a selected item into a virtual cart so that I can purchase all my items later at once.”

How this user story is implemented – the button color, the best copy, positioning, animations, etc. –  will be defined along the way based on user feedback, UX Design decisions and tech suggestions.

The idea that the exact feature set is not fully known at purchase time can be a bit jarring to your procurement team. However, keep in mind that Agile delivers a working product to you at each sprint. The scope can be adjusted throughout the development process based on the findings from previous sprints. Features will be added in subsequent sprints – until you are satisfied that the product meets your needs, or your budget cap is reached. You are involved at every step, and if you need to make changes they will be incorporated in each successive sprint.

Budget

Every business has a budget – and Agile development must work within budget constraints.

One excellent approach to Agile budgeting is to set a not-to-exceed budget and a target  – in terms of what should be achieved within what timeframe. Target and not-to-exceed budgets should be clearly communicated and agreed on at bid time, so that your vendors have clear goalposts – and can advise what is achievable within the budget constraints.

Risk

With Agile, your risk goes down – because you’re provided with working software early within the project with regular updates, rather than at the end of a lengthy development cycle. So even if you part ways with a vendor after one or two sprints, you will still get software you can use.

Given Agile’s iterative and transparent approach, you have ongoing visibility on what is being built – and the ability to test hands-on and provide feedback. Communication is key with Agile. The sprint team consists of cross-functional team members that constantly share their individual expertise – no silos! This mitigates another key risk of traditional development – gaps in requirements, that aren’t uncovered until late in development, resulting in a last minute scramble and “bolt-on” features.

Conclusion

Agile development will deliver exceptional results for your business. If managed well, Agile also provides excellent value – and mitigates risk. As you are provided working software for your review, you can also “pivot” and take advantage of unforeseen opportunities – without blowing your budget.

Finally, your finance and procurement teams still have the necessary business levers they need to keep vendors in check, while your developers have the latitude to artfully design excellent solutions for your business.

To achieve this it is absolutely mandatory that you trust your product development experts to make the best decisions along the way, based on a clear target – rather than budgeting and signing off every single feature before kickoff.

If you’re new to Agile, consider engaging an experienced partner to help guide you through your project – and you’ll be delighted with the results.


You have a question or an opinion about the article?
Share it with us!

Your email address will not be published. Required fields are marked *.

* Required field

Autor

Gregor Ilg ist bei etventure als Experte für Organisationsdesign und -entwicklung verantwortlich für alle Themen rund um die neue Arbeitswelt. Gemeinsam mit seinem Team entwickelt und betreut er sowohl die kontinuierlichen Transformationsprozesse innerhalb von etventure als auch das projektbasierte Change Management für Kunden verschiedener Branchen.

Read all articles