Should Business Apps Teams Follow the Agile Manifesto?

Welcome to the Amazing Apps show -- for Microsoft Business Applications builders who want to create amazing applications that everyone will love.

Hi, I'm your host Neil Benson. My goal on Amazing Applications is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks and create amazing, agile Microsoft Dynamics 365 and Power Platform applications.

Don’t forget to subscribe to the show so you don’t miss an episode in your podcast player, and follow Amazing Applications on LinkedIn where you’ll find show notes, links to resources, and you can comment on this episode and let me know what you think.

The question in this episode comes from Andreas Dutz, he’s a Business Development Manager at HSO from Bavaria, Germany. 

Andreas Dutz: "Have you defined what agile means? Are your teams trained in the Agile Manifesto and are your teams applying it today?"

Great questions, Andreas. Thanks for leaving me your question. By the way, you can ask your question on the Amazing Apps show by visiting customery.com and clicking on the Send Voicemail button. It’s a no-code/low-code voice application for podcast questions!

Just before I respond to Andreas’ question about the agile manifesto, I wanted to take a moment to recognise another German. Christopher Maisik, Consultant at M&P Solutions from Braunsweig took my Scrum for Microsoft Business Apps course last year and recently achieved his Professional Scrum Master I certification with Scrum.org. Well done, Christopher.

***

The Manifesto for Agile Software Development was published in 2001 as a result of a meeting of 17 thought-leaders in software development. 

Bob Martin brought together people who had formulated, presented or pitched new “lightweight” software development concepts. The group settled on the word “agile” rather than “lightweight” and instead of inventing a new methodology they published what they called a Manifesto for Agile Software Development.

At its core, it says that we value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customers and collaboration over contracts and negotiation
• Responding to change over following a plan

It also includes 12 principles:

1. Satisfy the customer
2. Welcome changing requirements
3. Deliver working software frequently
4. Business and developers must work together daily
5. Build projects around motivated individuals
6. Convey information through face-to-face conversation 
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development
9. Technical excellence enhances agility
10. Simplicity -- maximising the work not done -- is essential
11. The best architectures arise from self-organising teams
12. The team reflects and adjusts its behaviour at regular intervals

I’m summarising here, so if you are familiar with the Agile Manifesto you should go and read it in its entirety at https://agilemanifesto.org.

While I’m at it, I was criticised recently by an agile practitioner who took offense when I called it the Agile Manifesto. He said, you mean the “Manifesto for Agile Software Development”? As if shortening the name for convenience was a grievous offence worthy of waterboard torture (or waterfall-board torture) for anyone abbreviating the name of this holy text.

That’s one of the perils about becoming agile. There are a lot of fanatical agilists who take it far too seriously. Watch out for these crazy people. I’m a big fan of adopting an agile approach for building Dynamics 365 and Power Platform applications, but I like to think of myself as a pragmatic agilist. If I ever become one of those agile zealots, please slap me and banish me to manage SAP projects in Microsoft Project for the rest of my measly career. 

I have some issues with the Agile Manifesto.

Don’t you think it’s strange that it’s never been revised? It was developed in a single iteration and there hasn’t been any inspection or adaptation of it since. Agilist talk a lot about being adaptive. Responding to change. Reflecting on our experience and adjusting our behaviour. Do we really believe that the Agile Manifesto 1.0 was beyond perfection? If so, I bet it’s the only time that’s ever happened to a bunch of software developers. 

It was developed by 17 middle-aged white guys. How much better could agile software development be if the original authors had included women, people of colour, younger, older, and a few more non-American or anything other than-English-speaking voices. The group doesn’t meet the expectations we have today for diversity. Imagine how much better an Agile Manifesto would be if there was a diverse group of thought leaders occasionally updating it.

My last point about the Agile Manifesto is that it is very obviously software-focused. It’s the Manifesto for Agile Software Development. Today, there are agile teams building marketing campaigns, designing education curricula, building standard operating procedures for healthcare and inventing sustainable vehicles. Those teams are working on complex problems, transparently in full view of their stakeholders, collaboratively in the small teams that inspecting their work and adapting it in short iterations. We’d recognise them as agile. Even though a large part of the Agile Manifesto doesn’t apply. They are not delivering software frequently. They are using working software to gauge their progress.

Is it possible that our diverse committee of agile luminaries could also include people from diverse industries and domains that could maintain an agile manifesto applicable to everyone working on complex problems?

So that’s my rant over about the Agile Manifesto. It’s good but not perfect.

There’s a lot in there that I like, and I agree with Andreas’ assertion that Dynamics 365 and Power Platform teams should be familiar with it. But I’d stop short of ensuring we’re trained it or applying it word for word.

Instead, you could try running a workshop or a sprint retrospective to review and discuss the Manifesto for Agile Software Development. 

What elements does your team agree with and what to uphold?

Are there parts of it that don’t apply to your team or you could change to make them more applicable? For example, if you’re an internal team within a Microsoft customer organisation then contracts and negotiation might not apply. Instead, you’ve got departmental budgets and policies to contend with.

Are there new values or principles your team would like to introduce? Maybe you want to add a principle about building diverse teams that respect each other and hold each accountable. Maybe you want to include some principles about the customer or your product owner to set expectations and know what great product ownership looks like.

Sure, understand the Manifesto for Agile Software Development but understand that it was written at a point in time 20 years ago.

Make your own Manifesto for Low Code Application Development for your organisation and make it real for your teams.

***

That’s it for this episode.

Thanks for joining me. I really appreciate your comments and feedback. I hope you find this episode, and every episode useful. I hope you explore and expand your agile mindset. How could you bring more transparency to your work, your next project or your next business application? How could you work in shorter cycles, more collaboratively, welcoming change and working sustainably?

Don’t forget to subscribe in your podcast player and follow Amazing Applications on LinkedIn. 

Until next time, keep sprinting.