Agility can be great (even though for many neurodivergent people, it’s the opposite of great). But when teams go through the motions to be “Agile” they often end up overcomplicating the work, adding stress to interactions, and achieving less agility.
If your agile processes are “working”, then over the next iteration (typically 1-4 weeks):
⬜ You have a clear understanding, as a team, of the value you’re working to demonstrate. (Note that this is not a promise or a commitment, but a shared purpose, direction and intention.)
⬜ You have a clear understanding, as individuals, of the actions that will generate that value. You know what to work on (and think about) when you’re not in meetings or with clients.
⬜ You don’t feel alone – you have teammates to communicate with and collaborate with, and resources you can use, as you move forward to advance project objectives.
⬜ You are working at a comfortable, sustainable pace.
⬜ Your team is improving every week – you continually do things a little differently to help improve quality, productivity, collaboration, or other outcomes.
None of these things require meetings (or “ceremonies”) – just communication and inclusion. We should always be asking ourselves and our team members: what’s the easiest, smoothest, least intrusive way of building this shared understanding and maintaining it every day?
When teams work with agility:
⬜ Everyone understands the overall goal and the next increment of value to demonstrate.
⬜ Everyone has clear things to do to contribute to that value.
⬜ Each person (and the team as a whole) works at a sustainable pace.
⬜ Nobody feels alone. There’s a group of collaborators to share the work with.
⬜ The client or project champion has visibility into the work and is happy with progress.
⬜ There’s an opportunity to rest, reflect, and adjust every week or two.
⬜ It’s not ridiculously hard to adjust to changes in scope, tools, or personnel.
But I regularly see “agile” teams flailing… unhappy… in constant panic mode, with stress that just won’t end. They are very busy and always seem to be scrambling to show their client or project champion some kind of value… with the feeling that they have to defend their existence. They have a nagging sense of confusion and impostor syndrome may be creeping in. They can tell you exactly what tasks are on their JIRA boards, but they can’t tell you why those tickets exist or how their task is contributing to overall project value. They have lost sight of the forest (value) because they have planted so many trees (tickets).
For these teams, the Scrum process and Agile ceremonies may be adding layers of stress and bureaucracy rather than helping the team work sustainably to consistently drive value. They are “doing Agile ” but have actually made themselves less agile… less able to flow and adapt and respond to changes in scope, tools, or participants.
Agile methods first emerged in response to the slow, painful, unsatisfying, unhappy practice of software development. It was really depressing to spend months building software, only to have customers and users complain how bad it was when they got it (especially when you developed exactly what they specified). It felt isolating to have to figure out how to deliver a piece of the software without any input from other engineers, and it was distressing when others were blocking your work and you had to convince them to listen to you. The whole endeavor was inefficient, and people were often tense and stressed.
The realizations in red (in the 90s) led to the Agile Manifesto items (2001) in blue
We’re applying processes and tools without really examining why we need them
So let’s prioritize…
Individuals and interactions over processes and tools
- Why this is part of the Agile Manifesto: Since the beginning of time, development teams tend to get hung up on the details of using tools (e.g. MS Project, JIRA, kanban boards) rather than why the tools are there in the first place: to make sure people are getting the information and context they need – on a regular, routine basis – to make continuous progress on the team’s overall deliverables.
- What we should do in 2022: Focus on information sharing, context building, and working arrangements that help people get work done. This applies to interactions within the team as well as interactions with the client.
We’re doing a lot of work that doesn’t actually contribute to our goal
So let’s prioritize…
Working software [ie. tangible stuff that’s valuable] over comprehensive documentation
- Why this is part of the Agile Manifesto: Software development in the 1990s was documentation-heavy. I even remember, in 2018, throwing away a few hundred pounds of paper (in about 20 4” binders) containing requirements and design documents for a really big software project that we did between 2002 and 2004. Often, development teams wouldn’t even produce software that matched the documentation because we’d learn about what was feasible and what was not as we were doing it. Everyone tended to deliver software that the business needed a year or two ago. We didn’t learn together and co-create the software.
- What we should do in 2022: We provide value in the form of information, shared understanding, and working software (which may be in the form of quality controls) – that’s it. Anything we produce that doesn’t directly contribute to making these things happen shouldn’t be done.
We’re unable to deliver something we don’t know how to define or describe yet
So let’s prioritize…
Customer collaboration over contract negotiation
- Why this is part of the Agile Manifesto: Because deciding what you’re on the hook to deliver at the beginning of a project – and exactly what the deliverables are going to look like – is dangerous. You and the customer rarely have enough understanding of the problem (or of each other) to get it right.
- What we should do in 2022: Establish shared accountability. (Note: this is rare. How many times has a customer been on your team and just as accountable to the project champion for the end result as you are?) A workaround is to set expectations with the client that we are discovering the shared understanding together, and we will get as close to the desired deliverables as we can, given the fact that we are embarking on a process of learning together.
We’re unable to commit to a plan when we might learn that our plan isn’t feasible
So let’s prioritize…
Responding to change over following a plan
- Why this is part of the Agile Manifesto: As you learn about what’s possible, what’s not possible, and what the client actually values… plans will change. Instead of establishing a timeline that won’t end up working out (and that will cause you a lot of stress when you start deviating from), just start with the understanding that your Gantt Chart and your intermediary milestones will probably not be achieved when you think they will – or maybe even at all.
- What we should do in 2022: Always keep the final goal in mind, but revisit and adjust the plan as you learn more every week. Iterate!
