Individuals and interactions over processes and tools

Creating solutions is a team sport. Team members need to communicate with one another. They need to ask questions, discuss ideas, debate ways forward and support one another. Particularly with more complex problems, the ancient adage that ‘two heads are better than one’ still holds true. Of course, tools and processes are also important, sometimes critical. They can help teams be consistent, encourage the right things to be done in the right order and optimise repetitive tasks. In fact, without tools, some common agile practices like continuous integration or version control would be much harder. But, on balance, agile teams should get the people parts right first.

Working software over comprehensive documentation

The perspective of a software development team is that it exists to produce working software, that has been tested and delivers an expected outcome to the users to a desired level of quality. Good software should also be properly documented, of course, and poor documentation can diminish or nullify the value offered to the customer. For example, if the customer isn’t able to set up the software because they don’t understand the controls, they will not realise any value from it. Similarly, ongoing maintenance and further development of the software will require the relevant documentation.

Having said this, no matter how good the documentation, at the end of the day it is the software, or a working solution, that the customer needs. An important word in the Manifesto value is ‘comprehensive’. There can be a tendency in some teams to generate huge volumes of documentation in great detail. It is often as if there is a feeling of comfort in producing documentation – if we analyse and document everything, we won’t be caught out! Similarly, where a method permits tailoring (as many do), inexperienced or cautious project managers have a tendency to include more artefacts than required. Does an architectural prototype intended to help the customer understand how the interface might work really require a test plan and a support guide? Probably not. When it comes to documentation, as with most other elements of agile development, teams should aim for Just Enough, Just in Time.

This is just as true for non-software solutions. Overly focusing on the word ‘software’ can be dangerous, particularly for larger, more integrated solutions, or when trying to solve business problems with a holistic solution. Business analysts often work at higher levels of abstraction, where IT or technology is only one aspect of the solution, and may use models like POPIT™ (discussed in Chapter 3) to explore how people, the organisation or processes also need to be changed.

Business analysts may find that this value challenges some of their work within project teams, particularly with regard to requirements documentation. However, experienced business analysts are skilled in deciding the requirements approach, and this includes determining the artefacts that will best deliver the project objectives. To achieve this, the Lean principle of Just Enough, Just in Time should be borne in mind. The requirements should provide sufficient detail to allow working solutions to be created; there should be a much lighter touch for requirements that are not to be implemented within the current release.

Customer collaboration over contract negotiation

This value is based upon the premise that the people who know best what a system should do are the customers who will be using it. They will know what business outcomes they are trying to achieve, and, as your system takes shape, they will be best able to judge whether it looks like it will help them. Since most projects are complicated and have to encompass numerous requirements of different types and of varying complexity, it is hard to define exactly what those needs are in advance. This is the fundamental problem encountered when applying the Waterfall development life cycle, where requirements must be agreed and signed off before design and implementation begin.

Inevitably, at some point, there will be changes made to the requirements or an earlier misunderstanding about what is needed will emerge and require clarification. Under the Waterfall model, this would require a formal change request process to be followed, with all the consequential effort this would demand. Since this situation is common, agile teams like to pre-empt it with contracts that are less prescriptive and with high levels of engagement and collaboration with customers.

This presents many problems. Customers are often very busy or they may be located at different, or dispersed locations. There may also be different types of customer (explored in Chapter 7), all of whom may have a different perspective on the system under development. This is where business analysis can be invaluable. Business analysts are able to analyse and manage stakeholders and as they will typically hold knowledge of the business domain, can help the customer to better understand the potential the software will offer and the real business needs to be met. The level of collaboration is expected to be much greater on an agile project and, as a result, business analysts can expect to have a different kind of relationship with customers.

Responding to change over following a plan

This is probably the single most important element of agile software development; the expectation that things will change, and the adoption of processes, practices and principles that not only expect change but embrace it.

This is also the element of agile that causes the most angst, and challenges orthodox development methods the most. It is inherently logical to want to know what you can expect, when and for what cost. Most project management and systems engineering approaches aim towards delivering a certain set of things, on a certain date, with a certain amount of budget, in the hope that this will reduce risk. Senior stakeholders want to be able to make promises to others about what they can expect, and it seems perfectly sensible to want to be able to give them an answer.

In reality the only certainty is that things change: technologies, business strategies, competitors, personnel. Solution development methods that expect, anticipate and deal with change will be more likely to navigate those changes with the least impact and the highest chance of succeeding; that’s why agile teams value responding to change.

This does not mean that plans are bad. On the contrary, plans are essential, but they must be able to change when the environment that affects them changes.

THE 12 AGILE PRINCIPLES

The Agile Manifesto is supported by a set of 12 principles, drafted during the original meeting in February 2002 and finalised over the following few months. Table 2.2 shows the 12 principles, and briefly describes why they are important.

 

Table 2.2 The 12 agile principles explained

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.		The customer is the most important stakeholder, and what is most important to them is knowing that you will solve their problem for them. It is even better if they can receive something of value early.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.		Requirements change for all sorts of reasons. Agile teams expect this and anticipate it.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.		The best way to know if something is right is to see it in action. This helps to refine requirements for future releases, raises customer confidence in the software development team and offers the potential to realise value early.
Business people and developers must work together daily throughout the project.		Most projects are too complicated to assume that written down requirements will capture every detail. Being able to ask questions and clarify understanding throughout the project is essential – the best way to do that is face to face.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.		People build solutions, and people do better work when they are motivated, empowered and have the right tools for the job. The impact on quality and productivity caused by not doing this should not be underestimated.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.		While other forms of communication are important, for many things, face to face is by far the best.
Working software is the primary measure of progress.		It is better to measure progress in terms of the actual thing you are delivering, rather than other factors (like effort spent) since that’s what the customer really cares about.
Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.		People build solutions, and people don’t do good work when they are overworked, stressed or neglecting other parts of their life. Good agile teams don’t rely on a hero culture.
Continuous attention to technical excellence and good design enhances agility.		Delivering quickly is not an excuse for poor engineering. In fact, good design can make it easier to add new capability quickly.
Simplicity – the art of maximising the amount of work not done – is essential.		It is easy to make things hard, big and complex. Often, it is harder, but far more valuable, to make things simple.
The best architectures, requirements and designs, emerge from self-organising teams.		A self-organising team that is fully focused on the goal will offer more relevant answers than those imposed upon them.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.		No team is ever perfect and the environment it operates in is never static. The best teams identify regularly the adjustments they should make in order to improve.

The agile principles are largely self-explanatory, and although seemingly heavily weighted toward software development, in the main, may be applied to other types of project or solution. They embody the values in the Manifesto and provide concrete examples about how the values should be demonstrated.

The principles describe not only how an agile team works, but how its members should think, behave and feel. Compromising these principles, perhaps when changing a process to suit a particular project, can cause inconsistency and a lack of coherent focus; this will often lead to problems at a later stage.

AGILE APPROACHES

As discussed earlier, several ‘lightweight’ development processes existed at the time the Agile Manifesto was created; additional such methods have emerged since. They are now described collectively as ‘agile’ methods. Chapter 5 will describe some of the more popular methods in detail. However, in overview, the key methods are:

• Scrum: a very popular method that borrows its title from the rugby scrum, and uses it as a metaphor for the daily progress update meeting. Scrum has short iterations (sprints) that each focus on delivering working software, a tightly prioritised ‘backlog’ for both the sprint and the product, and specifies a ‘Product Owner’ role who sets the priorities.

• XP: the source of many popular agile practices, and the key founding method. A disciplined approach with high customer involvement, continuous planning, continuous testing and rapid delivery in very short intervals.

• DSDM: provides project governance and scaling around XP or RAD approaches. It has three main phases called pre-project, project and post-project and includes defined formal stages within the project phase. Fitness for Business Purpose is the primary criteria for delivery and acceptance of a system and MoSCoW is used for prioritisation.

• RAD: both an umbrella term for a range of agile and iterative approaches, and a method described by James Martin (1991) in its own right. RAD takes the analysis, design, build and test phases and repeatedly iterates through them developing prototypes and versions of increasing functionality.

• Unified Process (UP): an iterative and incremental framework, with several implementations including the RUP, OpenUP and AgileUP. A highly tailorable framework that takes a RAD approach that is architecture-centric and risk-focused. The phases of the UP are called Inception, Elaboration, Construction and Transition, and each has a different focus.

• Lean: originating in manufacturing in the 1970s, the principles of Lean were applied to software development by Mary and Tom Poppendieck (2003) in their book, Lean software development. Lean focuses on the delivery of value to the customer and on eliminating waste from the process.

• Kanban: an approach that originated in Lean manufacturing and has been further developed by David Anderson (2010). Kanban is based on workflow visualisation, typically on a physical board, addressing issues that cause problems, limiting the team’s work in progress and balancing the demands on the team.

There are many other agile methods in use today. This includes hybrid methods such as ScrumBan and numerous in-house customisations that individual companies have developed.

AGILE PRACTICES

Given the popularity and widespread adoption of agile, and the profusion of different approaches, it is not surprising that there are numerous agile practices and techniques. The Agile Alliance maintains a guide to these agile practices on their website. Some of the most commonly used practices are listed in Table 2.3 below and are explored throughout this book.

 

Table 2.3 Agile work practices

Requirements practices		• Backlog: a prioritised list of requirements or work items that is frequently updated • Definition of done/definition of ready: setting acceptance criteria for a requirement • Personas: a way of identifying and describing users of the system • User stories: a way of capturing requirements • Story mapping • Story splitting: breaking down stories that are too big • 3Cs: a way of structuring user stories: Card, Conversation, Confirmations
Estimation practices		• Planning Poker • Point estimates • Relative estimation • Velocity: a way of predicting how much work the team can do
Team leadership and organisation practices		• Iterations/timeboxing • Daily meeting (Scrum) • Burndown chart: a measure of progress in this iteration • Task board/Kanban board • Retrospective: a review meeting to identify things to change in the next iteration • Scrum of scrums: a way to manage multiple teams working on related projects
Software development practices		• Pair programming • Test driven development (TDD) • Behaviour driven development (BDD) • Refactoring
Testing and release practices		• Automated build • Continuous integration • Version control

CONCLUSION

This chapter has discussed the history and development of agile, and has described the values and principles at its core. Having originated from a software development base, the Agile Manifesto and principles have a strong software focus. However, agile may be applied to a much wider context and can be beneficial if used on other types of change project such as process improvement or skill development.

REFERENCES

Anderson, D.J. (2010) Kanban: successful evolutionary change for your technology business. Washington, DC: Blue Hole Press.

Beck, K. (1999) Extreme programming explained: embrace change. Canada: Addison Wesley.

Boehm, B.W. (1988) A Spiral Model of software development and enhancement. ACM SIGSOFT Software Engineering Notes, August. Available from: http://csse.usc.edu/TECHRPTS/1988/usccse88-500/usccse88-500.pdf [6 December 2016].

Cadle, J. (ed.) (2014) Developing information systems: practical guidance for IT professionals. Swindon: BCS.

Highsmith, J.A. (2000) Adaptive software development: a collaborative approach to managing complex systems. New York: Dorset House Publishing Co. Inc.

Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The unified software development process. Reading, MA: Addison Wesley.

Martin, J. (1991) Rapid application development. USA: Macmillan.

Poppendieck, M. and Poppendieck, T. (2003) Lean software development: an agile toolkit. Boston, MA: Addison Wesley.

Royce, W.W. (1970) Managing the development of large software systems, Proceedings of IEEE Wescon. Available from: www-scf.usc.edu/˜csci201/lectures/Lecture11/royce1970.pdf [6 December 2016].

FURTHER READING

Agile Alliance. Available from: www.agilealliance.org [6 December 2016].

Ambler, S. (2009) The Agile Scaling Model (ASM): adapting agile methods for complex environments, IBM Rational. Available from: www.webfinancialsolutions.com/wp-content/uploads/2011/10/Adapting-Agile-Methods-for-Complex-Environments.pdf [6 December 2016].

Ambler, S. and Lines, M. (2012) Disciplined Agile delivery. New Jersey: IBM Press, Pearson.

Hunt, A. and Thomas, D. (1999) The pragmatic programmer. Reading, MA: Addison Wesley Professional.

Interview with Jeff de Luca (2007) ‘Jeff de Luca on Feature Driven Development – interview April 2007’. Available from: www.it-agile.de/fileadmin/docs/FDD-Interview_en_final.pdf [6 December 2016].

Paul, D., Cadle, J. and Yeates, D. (2014) Business analysis: 3rd edition. Swindon: BCS.

The Agile Manifesto. Available from: http://agilemanifesto.org [9 January 2017].