“Agile development” is used to describe a wide variety of development practices. Claiming that one follows an “agile” development methodology is easy. But declaring that your practices are “agile” is just about as useful as declaring yourself the winner – saying you are the winner doesn’t make it so. Thus the question is, how can one ensure that what is called “agile development” by some company actually delivers what is expected?
On a surface level I believe it is rather easy to agree with the Agile values. Working in a small company, whether or not the right things are done comes down mostly to a question of self-discipline: there is a number of time-consuming and less exciting things that have a high payoff, but are not done because each person (this includes you, reader) has a preferred way of working. In most cases this good: second-guessing oneself is hardly productive. But in order to actually benefit from best practice one must not only be aware of it but also try to implement it as best possible – blindingly obvious, but somehow frequently ignored.
McDonald et al. (2008) make an interesting reference to Auguste Compte’s Law of Three Stages from 1830. The law proposes that a scientific discipline progresses through three stages: theological (belief-based knowledge), metaphysical (philosophy-based knowledge) and positive (based on scientific reasoning). The authors (each with SW development background of at least 20 years) propose that the Agile movement and manifesto represent a move from belief-based practices towards the second, philosophical stage. This is interesting because it implies that they see Agile (with a big A) is still more as a philosophy than a full methodology – or more importantly, that doing Agile well requires that you pick and define an overall framework within which you apply the Agile principles.
In a post on his website, Scott Ambler asks five questions to help determine whether a team is Agile:
- Is the team is doing developer regression testing, or better yet taking a test-driven approach to development?
- Are stakeholders active participants in development?
- Is the team producing high-quality, working software on a regular basis?
- Is the team is working in a highly collaborative, self-organizing manner within an effective governance framework?
- Is the team improving their process on a regular basis?
Some further questions
I think these are very good questions to identify whether the Agile principles are used in developing software. But if you are thinking about implementing Agile practices, you ought to also be able to answer further questions about the underlying process:
1. What are you doing to detect, predict and prevent defects? “Regression testing” is not an answer: what part of your testing is automated? What is the role of practices such code reviews, test scenario development and design validation in your process? Who is responsible for quality assurance and how are defects tracked?
2. How do you manage and communicate requirements? Who talks to the stakeholders? How do you disseminate the information? How do you track fulfilled and unfulfilled requirements? How do requirement changes influence planning and scheduling?
3. How are you ensuring that quality and security concerns are addressed and that lessons learned from previous projects are remembered?
These are just a few process-related questions off the top of my head.
Why can’t you answer?
If you can’t answer, or aren’t doing one or more of these practices, ask why not. My answer to “why not?” is that this is a result of a lack of appreciation of whatever the unimplemented best practices could bring, such as: automated testing, active stakeholder participation, better scheduling or controls, self-organization or process improvement accountability. While these are best practices, that does not mean that adopting them is always in the personal interest of the participants of the software development process. For example:
1) Active stakeholder participation may not be valued because it is considered to be customer interference rather than a method of increasing the focus on customer value, or it may not be valued because a consultancy may prefer to have a costly billable change process.
2) Better scheduling or controls may be seen as overhead and micromanagement by developers.
3) Increasing accountability for mistakes may be uncomfortable and thus seen as undesirable.
To me, the key question is how can we can raise the perceived value of these practices in order to create the internal motivation to implement these processes more stringently – and hence hopefully realize the benefits of best practice in our organization?
For example, let’s look at why TDD might not be valued.
Regression testing / test-driven development may not be seen as valuable because of beliefs such as “the real work of development is implementation” and “quality is achieved by molding software into shape by correcting defects” (McDonald et al. 2008). What could be done to create the internal motivation to implement TDD?
One part would be to examine these beliefs and examine the benefits of defect prevention via TDD. In particular, it may be that the negative impact of the ripple effect of flaws on dependent functionality and the cost in customer satisfaction are underestimated.
Second, there is a larger question of whether quality ought to take precedence over other potential priorities – because focusing on quality does not mean following best practices only when they are convenient, and throwing them out when the going gets tough. Would you trade intangibles such as quality over tangibles such as lines of codes or number of features or maintaining a release schedule? A quality-oriented organization ought to choose quality over features or schedule and be confident that this will still lead to a better result than prioritizing features or schedule.
Third, there ought to be an increase in emphasis on the test and quality assurance results as a deliverable. Are your test results a deliverable, and do you actually deliver them? Can you make them a deliverable? By making it clear that the results of an intangible activity are still deliverable and are visible work will increase their perceived value. An internal report may be less important than a report going to the customer (even if the report is an aggregate) and will likely help shift the emphasis from an internal, optional activity to a deliverable, required activity.