This post serves as part of study on the effectiveness of the DO-178B certification in achieving correctness of implementation and safety guarantees in the presence of incomplete requirements, feature creep and complex technology stacks, also known as your typical software project.
If you are currently; or in the past have worked on DO-178 projects, it would be appreciated if you would be so kind as to take part in a survey about the state of DO-178 development.
One of the challenges in defining a more agile DO-178 process, is proving that the process is actually agile. Proving it conforms to DO-178 is easy, there is an entire specification written for that, but agile…hmmm.
So what is agile?
What a question…the software development world is a buzz with agile this and agile that, but ask any practitioner of agile software development this question, and you’ll invariably get a different answer from each and every one of them.
So to ask the question, lets first frame what I mean with agile. In my mind, agile can be seen to exist on three tiers, let’s call it the agile pyramid if you will.
Tier 1- Philosophy
First tier is the agile manifesto, where it all began off course. The manifesto states:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The agile manifesto also talks about twelve principles of agile, but I think the above four statements captures the intention well enough.
Now the manifesto sounds great and all, but it doesn’t give you much of an example to work with on how to run an agile project. Fortunately shortly after the manifesto Kent Beck lead a software project that has been studied quite a bit, and gave rise to Extreme Programming (XP). But extreme programming was a little bit too extreme for some, and besides, project managers still didn’t have much of a clue about how this agile thing works exactly anyway, which leads us to our next tier in the pyramid.
Tier 2- Project management
In order to formalize what agile software development is exactly, legions of consultants sprang up to teach these projects managers and their programmers. What came forth was the leading agile development methodology, Scrum, but also Kanban.
Ok so scrum is a daily ritual of scrum masters, stand up meetings, user stories, time limits and velocity tracking. Oh and Kanban boards.
So what is the difference between Scrum and Kanban? Well, not much, except Scrum could be described as the anal retentive cousin of Kanban. For where scrum has roles, time limits, velocity tracking, daily meetings, scrum masters etc, Kanban has none, just a board and a team. (Ok I might just have started a religious war, don’t take this stuff too seriously).
Tier 3- Best practices
So Scrum and Kanban relies on certain agile best practices to really succeed, and if you really get down to it, this can become a very long list. I’ve listed the most important ones for my purposes (agile DO-178), but there are many more:
- Continuous integration
- Continuous deployment
- Pair programming
- Regular code refactoring
- Velocity tracking
- Feature driven development
- Test driven development
- Behaviour driven development
Ok so back to my initial question, at what point can it be said a team is agile? Is it only necessary that the spirit of agile is followed (agile manifesto), or only when the entire pyramid is in effect?