When it comes to transitioning to agile, some changes are easier than others. The easiest change to make always involves the other guy or gal; or in the case of agile, when it involves the development team and not the rest of the organization.
If everyone in the organization does not understand how agile planning differs from traditional planning, organizational friction and frustration will result because expectations are different. Agile teams will be expecting and doing one thing while other parts of the organization will be expecting and wanting to see something else.
With agile, the challenge is to: Produce great customer outcomes in the shortest amount of time possible – using the least amount of effort – while creating a sustainable, rewarding, satisfying work environment.
Fundamentally, we’re striving to define, deliver, and profit – in a way that meets this challenge.
With agile traditional roles become overlapped. Development and Quality Assurance roles are oft-cited areas of overlap within agile teams. An area where agile introduces overlap and change that bumps into expectations outside of the development team is in defining the solution:
Capabilities are usually provided in the form of a User Story format, where each User Story is discussed with the team. And this is where the benefits of agile begin to emerge.
Benefit #1: We haven’t invested significant time and effort in elaborating requirements in detail, well in advance of when we actually need them. We’re elaborating our requirements on a just-in-time basis, adopting lean principles by avoiding generating a large batch of requirements inventory up front. This allows us to get to work faster and it reduces the cost of change later. We also strengthen our solution by waiting until the last responsible moment because this allows us to incorporate learning from other work performed up to that point.
Benefit #2: We have leveraged the most efficient and effective means of communication. As one of the twelve principles of the Agile Manifesto states, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” We aren’t wasting time generating documentation and handing it off – and risking misinterpretation as a result. Instead, the conversation and creation of mutually agreed upon acceptance criteria creates a shared understanding in the shortest amount of time and for the least amount of effort expended.
Benefit #3: The ability to exploit emergent innovation is enabled. Since User Stories describe the desired capabilities (intent) and not the full solution, the dialog between business experts and technical experts can yield unanticipated benefits. For example, I’ve been involved in situations where difficult-sounding, complex needs have been addressed elegantly – with an approach that simplified the problem in ways that were in full alignment with the business need. And the only way we would have gotten there was with a conversation with right people – those responsible for the implementation talking with those who desired the capability. We have to work longer and harder to achieve this in other ways. And more often than not, we miss the opportunity altogether.
Benefit #4: Motivation and involvement increases. When people own the solution – because they have input on shaping it – they are become more engaged committed. Defining and owning the solution – coupled with the self-organizing, self-managed approach to work – makes for a more rewarding, satisfying work environment that leads to greater productivity.
Does this challenge existing beliefs? You bet it does.
Most organizations want to optimize development by feeding the development teams with fully defined, approved requirements. They also want to fully utilize their “resources” (people) with functionally-specialized work: developers writing code and testers testing. If there isn’t enough to go around, more work is created and/or people are allocated to additional projects so that they are fully utilized. A box is put around the requirements and specification so the team has little more than directed TODO list (many times with a preconceived date on when work will be delivered) to execute on as fast as possible.
This creates waste and puts more work in process that impacts organizational productivity. When it comes to multiple projects, for example, delays are incurred in delivering high-priority projects because people are multi-tasking across projects. (Does your organization calculate the cost of task-switching people between projects?)
Optimizing around functional specialization is actually a sub-optimization. By maximizing functional specialties, we pay an organizational price as a whole in terms of producing great customer outcomes in the shortest amount of time possible.