Happy Birthday Agile

It’s twenty years since the Agile Manifesto was created in Snowbird, Utah. There’s obviously been lots of people posting about whether it’s still relevant, whether it should be revised, and so on, but I think it’s still important and applicable.

It starts with: “We are uncovering better ways of developing software by doing it and helping others do it.
It doesn’t claim to be definitive; “We are uncovering” means we still have room to learn and improve how we do this. There are many “flavours” of agile, including Heart of Agile and Modern Agile, and some organisations develop their own take on agile (but “hybrid” agile-waterfall monstrosities don’t count in my book).

The next few lines (i.e. the rest of the manifesto) seem to be problematic for some people because they don’t fully understand “we value the items on the left more” – the manifesto’s authors even spell it out by saying “while there is value in the items on the right” and yet some people still think “Agile means we don’t do documentation”.

The first of these, “we have come to value: Individuals and interactions over processes and tools” is one I’ve see many organisations fail to grasp. It’s a long-running joke in the community that “installing Jira” equals “adopting agile”. I’ll refrain from ranting about Jira because the point is that any tool is not the way to become agile – it’s about people. I remember another coach saying “If a company doesn’t understand that it’s all about people then they don’t deserve agile”! 🙂

The next line, “we have come to value: Working software over comprehensive documentation“, is the one I see people misunderstand most – I wonder if that’s because so many people hate writing documentation? If you think about the two extremes, neither is ideal: documentation without software is clearly not a useful product, but also software with no documentation is rarely desirable (a simple tool with no user interaction might just about be ok, but even then anyone trying to fix/enhance the code is likely to benefit from some docs). That’s why we value working software more than documentation but not instead of.

I think the third line is easier to appreciate if you’ve ever worked on a waterfall project where we’re expected to blindly follow the documented specifications and hit deadlines, even if it means delivering something we know to be wrong. By valuing “Customer collaboration over contract negotiation” it means we would rather work with our customer, e.g. show them demos (or better yet give them something they can use) and get feedback early and often. If you don’t work with your customer and respect them, then how can you expect to keep them as a customer? (Ignoring monopolies/cartels, obviously; add banks to the list of rants I’m avoiding in this post!)

The final line, “Responding to change over following a plan” is closely linked with the previous one – in an ever-changing environment like software development there is always going to be change, whether that’s feedback from the customer “course-correcting” the direction of the product, or how the team works together (e.g. coming out of a retrospective), or the tools/technology that we’re working with. To ignore those changes is to say that we can’t learn anything during a project; I can’t think of a single instance where that’s been true, even working on tightly constrained legislation/standards-based projects – there’s always something discovered along the way. However, just like documentation, that doesn’t mean we work without plans – we need to understand where we’re heading and how we think we can get there… but we also need to revise the plan when things change. We need a roadmap (i.e. a destination and options for getting there) rather than a single route set in stone … but that feels like a future post 🙂

Onboarding

A couple of the teams I’m coaching had new people join them recently, and I was asked to be part of their onboarding. There is well-organised content covering the company and the technical aspects of the teams’ work, but what should I cover as their coach? I could explain Agile and Scrum principles, values and practices, but would that help the new team members understand what’s expected of them?

Instead, I paired with one of the experienced team members and we put together a “cheat sheet” with links to some key resources, e.g. where to find the group’s product roadmap. We covered how but also why the teams do things, for example, “how do teams know that they’re building the right thing?” – we also need to understand why it is important to get feedback on what’s being built, and why shorter feedback loops are preferable.

Given the new team members are being bombarded with lots of new information we wanted to give them an overview and some examples, but also some pointers so they can remind themselves and discover more … and the best way to learn how their team works is to ask their team! As their coach, I’m always happy to answer questions and discuss other ways of doing things, but I’m especially happy when teams learn from each other and run experiments to find improvements; I’m hopeful that having the new team members question their teammates will lead to them considering alternative approaches.

Agile means no documentation, doesn’t it?

Somehow this myth persists: Agile means we no longer have to produce any documentation, right? Sorry to disappoint you, but that’s just not true.

If we revisit the Agile Manifesto and read it carefully, what it says is “we have come to value working software over comprehensive documentation“. It says there is more value in working software, but it does not say that there is no value in documentation – there is some value in documentation, and more importantly there is value in the right documentation.
Continue reading “Agile means no documentation, doesn’t it?”