Agile embedded software development
The customer team works with the development team to produce a release plan, which is a series of iterations with critical dates identified. Each iteration in the release plan is made up of a set of stories. Stories are written on note cards to facilitate rearrangement during the planning meetings. The stories are estimated by the developers and are treated as independent. Stories are estimated in relative, but unit-less numbers. So the easiest story usually is assigned a single point and more difficult stories are estimated relative to that easiest story. So a five-point story is five times as difficult as a one-point story. The team estimates how many story points it can complete in an iteration, this estimate is known as the team's velocity. The stories grouped such that the sum of the estimates of the stories in the iteration do not exceed the teams estimated velocity. Figure 3 represents a release plan. Each iteration is made up of a stack of stories.
Click on image to enlarge.
As mentioned earlier, after a few iterations the team will develop its velocity, which is the total of the points of stories actually completed by the team in an iteration. The teams' velocity is the critical metric that provides feedback on the team's measured progress. Figure 4 shows a team's velocity tracking chart.
Click on image to enlarge.
If the estimated velocity was optimistic, as it usually is, that optimism is checked by the actual track record of the team. Optimism is good but the business needs to know is the plan is realistic. Figure 5 shows and burn-down chart which is used to monitor project progress.
Click on image to enlarge.
The velocity tracking and burn-down tracking can provide an early warning system for schedule problems, and this early warning gives the team management time to take corrective actions, such as reducing scope, adding people, extending the date, or possibly canceling the project. In this chart there is a new batch of requirements introduced in iteration 5. The velocity showed that the project was likely to be late, so in iteration 8 scope was reduced to 175 point and further to 150 points in iteration 9.
The most practical variable to control is project scope. With the behavior of the system having been broken down into stories, there are small bits of functionality that may be removed and rearranged in the plan. This is a highly visible planning process and this visibility can be used to remove higher-cost and lower-value stories. No one wants to cut scope, or delay the project, but knowing that the plan is in jeopardy is critical business information.
The nature of agile planning is that long term plans are less precise with more uncertainty than the short term plans. This sounds pretty natural. (What are you doing next weekend? What are you doing four months from this weekend?) The upcoming iterations in the release plan are more detailed and the iterations that are farther out have less precision. As time goes by the plan becomes more complete and the confidence in the plan improves.
Impact on the organization
Agile development involves more than just technical issues. The iterative nature of Agile impacts the whole development organization. Companies that view Agile as just solving technical problems will probably fail at agile adoption. The most successful adoption of agile happens when management and development are both interested in solving the problems of late projects, inaccurate estimates, and low quality. Specifications, schedule dates, and plans cannot be thrown over the wall to development. Management and development must work together to steer the project to a successful delivery within the constraints articulated through requirements, resources, and dates.
To steer a development team, a customer team is needed. A product manager usually leads the customer team with support from test engineers, product specialists, or systems engineers. When there is hardware/software interaction, having hardware engineering represented on the team is also needed. The hardware engineers often help identify the hardware integration stories needed to realize the product.
Agile teams embrace communications. The often use these practices and meetings to keep the team on the same page:
- Iteration Zero -at the beginning of a new release
- Periodic release planning—as needed
- Iteration review—every two weeks, usually immediately followed by iteration start.
- Iteration start—every two weeks
- Daily standup meeting—every day, fast
Questions at the daily standup:
- What did you do yesterday?
- What do you plan to do today"
- What is in your way?
During the standup meeting, people stick to the quick agenda and may offer to stay after to discuss issues further. Staying after is optional, respecting everyone's time.
During the iteration review meeting, the previous iterations stories and acceptance tests are reviewed, and velocity recorded. Teams also do a iteration retrospective. The team answers these questions:
- What went well?
- What problems did we have?
- What should we do differently?
Teams build continuous improvement into their regular development cycle.
We've done a quick overview of Agile Development. You probably recognize many of the practices of Agile Development. Agile is not new, some of these practices have been around for decades and have been very successful. Developers, business stakeholders, and end users should see improved schedule performance and product quality. Developers should feel the accomplishment of regular feedback of iterative development, TDD, and spend a lot less time chasing bugs. Business stakeholders should see improved predictability and visible fact-based management data.
James Grenning is the president of Renaissance Software Consulting Company. He trains, coaches, and consults worldwide. He has more than thirty years of software development experience, both technical and managerial. James’ mission is to bring improved technical and management practices to development teams. As his professional roots are in embedded software, he is leading the way to introduce Agile development practices to the embedded world. James was one of the original extreme programming coaches and trainers. He is one of the authors of CppUTest, a unit test harness for C and C++. He is currently writing a book on applying Test Driven Development to embedded C. James contributed Planning Poker to the Agile Management practices, an estimation technique that has taken the Agile world by storm. He is one of the 17 visionaries who drafted the Manifesto for Agile Software Development in February 2001.
There are some other very good references on agile development practices.
- Beck, Kent, Extreme Programming Explained
- Cohn, Mike, Agile Estimation and Planning
- Cohn, Mike User Stories Applied
- Martin, Robert, The Principles, Practices and Patterns of Agile Software Development
- Martin, Robert, Clean Code
- Book: Test-Driven Development for Embedded C
- Papers: http://renaissancesoftware.net/papers.html
- Blog articles: http://renaissancesoftware.net/blog
- Extreme Programming
- Feature Driven Development (FDD)
- Crystal Clear
- [LARMAN] Larman, Craig and Basili, Victor, Iterative and Incremental Development, a Brief History, IEEE Software, June 2003 Cover article
- [AGILEMAN] http://agilemanifesto.org
- [AGILEP] http://agilemanifesto.org/principles.html
- [GREN-TDD] Grenning, James. Test-Driven Development for Embedded C, Pragmatic Bookshelf, 2011 (www.pragprog.com/titles/jgade)
- [GREN-ET] Grenning, James, Test-Driven Development for Embedded C, Why Debug?, ESC-324, San Jose 2011
- [GREN-XU] Grenning, James, Testing Embedded Software with Executable Use Cases, ESC-244, Boston 2011
- [GREN-DES] Grenning, James, Object Oriented Design for Embedded Software Engineers, ESC-209, San Jose
- [BECK1] Beck, Kent, Test-Driven Development, Addison Wesley, 2002
- These and other papers by James Grenning can be found here http://renaissancesoftware.net/papers.html