To me, Agile is a mindset and philosophy, based on the Values and Principles of the Agile Manifesto with an emphasis on the humanistic aspects of creative knowledge work. Individuals, teams and organisations can become Agile in their mindset irrespective of the set of practices they use.
Unfortunately there is a lot of what I call “tragile” out in the marketplace – individuals, teams and organisations who have seen others getting some benefit and wanting the same for themselves, without being prepared to make the shift to a growth mindset (see Carol Dweck’s work) and highly disciplined practices that are needed to achieve the benefits.
My personal experience is that one in maybe ten organisations we deal with are truly open to adapting their thinking and then putting in the hard work to actually apply the new ways of thinking. Agile practices change the way we do a lot of the work in product development – they are based on the idea that it’s fundamentally impossible to know everything about the customers’ needs at the beginning of an initiative and there needs to be a built-in learning cycle which allows for adaptation and evolution of the product during the development process. They are well suited to domains and initiatives where there is uncertainty about what the real problem is and where the resolution to the problem is uncovered rather than known in advance – most knowledge-worker environments have these characteristics.
Effective application of the Agile practices requires a highly disciplined approach from all members of the team, starting with a serious commitment to collaboration and communication across all team members and key stakeholders.
The myths and dysfunctions which have resulted from so many “tragile” implementations have done lots of harm in the marketplace, but this has been true of most improvement initiatives in software engineering over the last 50 years. I still see lots of bad procedural code written in OO languages, people paying lip-service to the new way of working but not being prepared to actually change their way of working despite knowing it is not ideal.
To address some of the common myths around requirements:
- Agile has no requirements – the reality is that any initiative has to start with clarity in goals and objectives and Agile projects are no different in this regard. Where Agile differs from predictive/sequential projects is in the level of detail needed when – in a predictive project the premise is we need to know the full detail in advance because the cost of change is so high (civil engineering projects generally fall into this category). In an Agile project we start with a prioritised list of needs or capabilities (user stories are a common tool for expressing this list) and elaborate them in detail on a just-enough, just in time basis. We anticipate that as the work continues we will learn more about the real needs and about the acceptability of the solution approach and are prepared to change the items in the list in response to this learning, hence not elaborating the detail on everything early as we believe a lot of the understanding will change and there is a high risk of wasted effort from too much detail too early. See my blog post on the topic.
- Agile does no design/architecture: This is a myth perpetuated by lazy developers who want to “build code like free-form poetry” (to quote my friend James King). The reality is there are some design aspects which need to be identified early in the project – what Philippe Kruchten calls the “architecturally significant non-functional requirements”. Any initiative which doesn’t have clear architectural guidelines from a very early point is setting itself up to fail. In Agile projects we try to defer making expensive to change decisions until as late as possible (keeping our options open) and we use the term “last responsible moment” a lot. Please note – there is a big difference between “last responsible” and “first irresponsible”! Another characteristic of good Agile practice is making architecture real as soon as possible – architecture is not a set of Visio diagrams or a PowerPoint deck, it’s a slice of the product built and proven to meet the important functional and non-functional needs of the product.
- Agile doesn’t scale: If you accept that Agile is a mindset rather than a branded set of practices (Scrum is a framework, it’s not a methodology and it’s a framework that is deliberately lightweight in terms of telling people how to work) then scaling becomes a challenge of finding the right combination of practices, techniques, tools and communication approaches to support the level of scale you need – I have worked with teams doing effective agile development across multiple countries, and on some very large products. They need to supplement the practices which a small co-located team would use with additional practices to tackle coordination across multiple product aspects or across different timezones but they are certainly able to be agile in their thinking.
I taught a Volere (Mastering the Requirements Process) class last week and we had a lot of really healthy and valuable discussion around how the concepts embodied in Volere are applicable in Agile projects and came to the conclusion that there is no contradiction between the great ideas James and Suzanne have put into Volere and the application of agile thinking and practices on product development.
Please don’t be fooled and distracted by the tragile development out there – Agile practices implemented in a disciplined way with an adaptive/growth mindset result in great outcomes for development teams, their organisations and most importantly for their customers.
What is your understanding of Agile?
Post by Shane Hastie