Software Agility

For some years, Agile has been one of the premier methodologies adopted within the IT software world to bring new products and services to market quickly and efficiently, increasingly taking over from more traditional approaches such as ‘waterfall’.

Embedded systems development presents some particular challenges compared to traditional software development; projects typically involve many different contributors including hardware engineers, while embedded systems development can include additional stages, such as prototype manufacture, that may add weeks to a project schedule and enforce specific milestones. Chip design also involves highly specialised tools and generates large, binary digital assets.

All of these factors have made it difficult to use traditional software version management tools and processes such as Agile methods, but this is starting to change with modern tools that enable collaboration and provide visibility for the entire team.

Agile Explained

So exactly what is Agile? First introduced in the late 90s, Agile is well established in the software development world as a tool to accelerate time-to-market. It aims to emphasise the points below, while still appreciating the value of their counterpoints:
-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 and how they might apply to the world of embedded design.

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. This can be in the form of daily meetings, to review the current status of a project and to iron out issues before they escalate. Communications is best for understanding the idea behind, for example, a particular feature, then iterating and trying things out, while sticking within the broad vision of each project. This approach helps to engender more creative thinking, because people have an environment within which they can safely suggest ideas.

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% 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 better 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 a brief is agreed, the team 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 says 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 if 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.

The time to integrate work isn't a week before the deadline. Although it takes more investment in the embedded industry, shops adopting Agile methods strive for on-demand simulation environments that integrate and test the latest work from each team before manufacturing.

A strong software configuration management (SCM) system is invaluable in two ways. First, it provides visibility into how all the work fits together to deliver the simulator build. Second, it has to handle the heavy lifting for the unique (large binary) data that the embedded teams develop.



Getting It Wrong, Getting 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) systems 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. SCM 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 For Embedded Systems Isn't Unique

The game development industry hit many of the same roadblocks, yet many Perforce customers have been very successful with Agile methods. Game developers are successful with Perforce because the tool actually increases collaboration and communication, a key Agile principle. Perforce lets the entire team, no matter the discipline, to store and work with their data in Perforce.

The hardware engineers can manage their huge design files, the 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.

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.