For some years, Agile methodologies have been widely adopted within the information technology software world to bring new products and services to market quickly and efficiently, increasingly taking over from more traditional approaches such as ‘waterfall’. While it may have promised much, Agile has not been without its critics, who say that it does not live up to expectations, that users can become too bogged down in the processes and lose sight of the end goal. They also fear Agile projects become siloed into teams, rather than being visible to the organisation as a whole.
However, as an increasing number of companies are finding, Agile CAN deliver on expectations, if some simple principles are followed: what might be called “pragmatic agile”. Supporting tools also have a role, such as SCM (software configuration management). SCM can help ensure that a project remains visible to all the key stakeholders, while supporting Agile-related tactics such as Scrum.
Agile explained
So exactly what is Agile? First introduced in the late 90s, Agile methods are well established in the software development world as tools to accelerate time-to-market. They aim to emphasise the items on the left below, while still appreciating the value of the items on the right:
- Individuals and interaction – over processes and tools
- Working software (or product) – over comprehensive documentation
- Customer collaboration – over contract negotiation
- Responding to change – over following a plan
Taking these elements individually, let’s look at what they mean in practice.
Individuals and interactions – over processes and tools
This does not mean that there is not a place for processes and tools – of course, there has to be – but Agile is very much about people communicating with each other, ideally verbally and not just via email. A common communications element of Agile methods are daily meetings, or “stand-ups,” to review the current status of a project and to iron out issues before they escalate. In Scrum processes (see later), planning meetings provide an environment in which to understand requirements of the backlog and how to address them with collective support on the effort required. This approach helps to engender more creative thinking, because people have an environment within which they can safely suggest ideas.
So given this environment, how might tools provide support? As an example, a strong SCM system is invaluable in two ways. First, it provides visibility into how all the work fits together to deliver a working product. Second, it allows features to be developed in parallel across Scrum teams, or to move changes between sprints if work has not been completed as expected.
Working software (or product) – over comprehensive documentation
Whatever the project – whether in mainstream IT, games development or embedded software design – all too often, projects can become unwieldy, with the temptation to ‘over engineer’ and lose sight of the original goal and deadlines. Agile encourages teams to maintain focus on the outcome. This can mean delivering a working version of the software that may not have 100 percent of the features originally planned, but the product still has usable functionality. A central tenet of Agile is to take an iterative approach: it is more effective to deliver a product early and then continue to improve, rather than delay time to market.
One common Agile method is Scrum. Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Here’s a quick overview of the Scrum framework from the Scrum Alliance:
A Product Owner creates a prioritised wish list called a product backlog. The Product Owner is a proxy for the customer when determining features and priorities.
During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
Along the way, the Scrum Master keeps the team focused on its goal.
At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
The sprint ends with a sprint review and retrospective.
As the next sprint begins, the team chooses another chunk of the product backlog and begins working again
Customer collaboration over contract negotiation
In this context, customers can be internal colleagues, not just external. In any design process, there is always a danger that once a brief is agreed, the team then goes away and develops the prototype, only to find that it no longer meets the requirements of the ‘customer’. An Agile approach includes regular communication with the customer, to get his or her ‘buy-in’, so that once the product is developed, they know what to expect and have been involved throughout the development process. This can mean working with non-technical colleagues, perhaps in the product marketing department, on a level not experienced before.
Responding to change – over following a plan
Of course, solid planning is usually essential, however within that framework, Agile prescribes that it is important to be able to respond to change and be flexible. After all, when a project can take months or years to deliver, it is not surprising when market or customer requirements change.
Some deadlines, like manufacturing lead times, are hard stops in the schedule. Does that mean the project can’t respond to changing requirements? Quite the opposite. It means that, until the project hits that deadline, the team has to be as Agile as possible, embracing continuous delivery principles.
Agile – how SCM helps get it right
So far so good, but Agile can – and does – go wrong. Here are three pain points that organisations typically face and how version management (or software configuration management) system can help:
Latency – while the intention may be there, in practice it is easier said than done to prevent delays. One of the biggest bottlenecks can be retrieving source files from a repository or opening in dynamic views. Continuous integration (CI) can help address this, by ensuring that the software works at all times, not just as it is being released.
Far-flung teams – this is one that Agile didn’t see coming, at least at first. The movement emphasised co-location and collaborative programming, with daily-stand up meetings and shared workspaces. However, thanks to outsourcing, the need for differently skilled teams, particularly when building hardware and software products, and high-speed connectivity, vastly distributed development is now commonplace. Again, SCM can help support this, enabling distributed teams to keep track of what has happened and what is happening, collaborate with colleagues, but carry on working on their own projects.
Varied workflows – during the development process, multiple teams will be involved working on different elements and each team may have its own workflows. For example, the process used by the software development team is likely to be different to that used by the documentation team and the hardware design team. These teams will also be working on very different asset types – source code text files, large binary files for hardware designs or documentation PDFs. The best SCM systems should be able to handle all the different content types and workflows such that all teams work the way they want to and have visibility in all parts of the project.
Agile lessons from the games industry
The game development industry hit a number of the same roadblocks, yet many have been very successful with Agile methods, not least Perforce customers. Game developers are successful with Perforce because the tool actually increases collaboration and communication: a key Agile principle. SCM – or version management – lets the entire team, no matter the discipline, store and work with their data in a common repository.
Hardware engineers can manage their huge design files, while firmware engineers can work with their driver code, and the software developers can of course participate fully. Each team can work semi-independently, yet still make their work visible and useful to the rest of the shop early on. For example, a firmware engineer can always load the latest approved hardware simulator designs for testing.
Given that the cross-functional teams may not be at the same location and may use very different schedules and workflow, it is important to build communication into the tools and processes. The SCM system should lend itself to modern task management techniques, like task branching and pull requests. These processes improve quality and build communication into the way the organisation works.
Conclusion
Time to market has never been a more critical element of product development than it is today. Ensuring that products fit customer demand is what makes products profitable. Agile methods, particularly Scrum, offer a chance to address both challenges. A strong SCM tool is required to enable distributed, multi-skilled teams to fully exploit the promise of Agile methods.
