Simultaneous work and an Agile Approach

There are ways to divide the work up using an agile approach.  This can get complicated for distributed teams but for teams that are on the same site the challenge is greatly reduced.

We once worked on an embedded development project for an electronic control unit on a vehicle. Actually, we have done that on numerous occasions,  however, this was an instance we did things radically different. 

The Product

This project required specifications be written that described the specific system interactions of this electronic control unit and the others on the vehicle.  There are many embedded components on the vehicle all connected together through a number of serial data links.   The product was complex and configurable for many applications.  The specifications defined the expected systems interactions, failure modes (possible system failures and expected responses) as well as fall back modes if the product had an internal failure as well as parameter driven configuration settings. For example, in some vehicles the input data may originate from a sensor directly connected to the embedded component, in other types of vehicles the input may come from one of any of the data links.  There were more than 120 specifications that would need to be written.

Specification and Development Parallel

The tight schedule and available talent meant that it would not be possible to run the project using the company’s typical approach.  It is just not a workable solution to until the specifications were complete before starting to develop the product.  The company employed an iterative approach to the development, but the iterations previously were on a larger scale.  There was no time for that approach.

In this project, in the early 2000’s, and the company or the people working there had not heard of agile.  We decided to employ a just in time approach to the specification building and product development in general.  The list was prioritized by critical feature to be able to operate the vehicle, making complete vehicle integration and testing possible. 

 The Teams

There were two teams, a small group of system knowledgeable to create the specifications or the product based upon the prioritized list.  The first team produced specifications just in time for the development and testing of the product.  This is an example of pipelining iterations[1] of the work.  In this case, the specifications were written and reviewed using and agile like approach, and delivered just in front on the development work which also took on an agile flair.

Breaking the work into two Agile teams

Two-way information sharing

Each subsequent development and test loop produced questions regarding the specifications.  The graphic does not show this interaction though it was significant. After the first set of specifications, the developers and testers would have questions to gain a better understanding of the expected behavior.  Those questions were answered in real time by those that worked in the specifications.  There was plenty of informal communication between specification team and the development and test team as they were all collocated.  Those questions generated refinements in the specifications (subsequent iterations) developing the product and the specifications not exactly simultaneously but certainly in parallel.

 Conclusion

There are many ways to meet the objectives of the project.  It all begins with the talent and motivation of the team, coupled with the willingness to adapt to the circumstances and balancing objectives – not capitulation and corner cutting.  My experience is corner cutting seems to solve the problem now, but creates many more issues at the future date.