Agile Development is a complete failure with O365

By Leon Bro

I’ve been an independent contractor for much of the last 15 years and I’m so old that I was already a manager when the Agile Manifesto for Software Development was published. As one of the early adopters of Agile I have been really excited seeing so many New Zealand teams finally embracing Agile approaches to work.

But it’s just not working with O365!

That’s a big call, but if you are hoping to hear a story about why waterfall methodologies are still the bees knees, this is the wrong blog post. Waterfall is even worse.

Here’s the problem.

Lets say a client needs a killer app and we’ve decided agile/scrum is the way to go. There’s going to be some sort of project scoping exercise, requirements gathering, roles will be filled, requirements gathered and formed into a backlog. Sprints will begin with developers picking out the user stories they want to work on, then build and release to the client. Client tests, developer moves to the next story.
For a lightweight methodology that’s a lot of work, so some of us working in the O365 space have started doing something different.

Finding the Solution.

Lets say a client needs a killer app. I meet with the client and get a picture of what they are trying to achieve.

I pick some components out of the O365 suite and form a solution. I show the client (and it can be as soon as the next day), they have a play, ask for some changes and I do them. We carry on with this cycle until they are happy, then we focus on adoption.
As Steve Jobs famously said “People don’t know what they want until you show it to them”. Normally I wouldn’t even talk to a Mac owner let alone quote the founder, but he has a point and it’s at the heart with my beef with how most companies approach Agile.
It assumes the client knows what they want and is capable of articulating this to a team of developers at the start of a project.
What we have been doing in the O365 space is figuring out what the client actually wants then using prototyping to confirm our assumptions. It’s fast, it’s cheap, and being built with out of the box cloud components, it’s scalable and maintainable. But none of those things compete with the advantages of a building a solution that’s been constantly modified through the development process by a client that has had a chance to understand to see what they need.
Or in other words. Agile is just not flexible enough. There’s not enough feedback built into the process.
The haters are going to hit back with comments like “You can’t do that on a big project”. My last two big projects were intranets where vendors had quoted 7 figure estimates. I delivered both on five figure budgets, so yes, you can use this approach on big projects
My other favorite is “How are the testers going to test without a requirements document or user stories?”. Well there not, because there are no testers. The client tests each time I release an iteration. In the process they are getting trained and because they are so involved with the process adoption is also guaranteed.

There are of course other reasons to think my approach is madness, but I’ll leave you to tell me about these in the comments section 🙂

Or of course – come and chat to myself at www.dwcnz.co.nz in Auckland late April – lots of brains to pick and great discussions to be had!

 


Comments

  1. Shannon says:

    We’ve seen lots of jobs in the past year or so that have not ended up with a satisfying product for the customer because their IT partner was stuck on using an Agile approach. Providing the customer is willing to put the effort in at their end to maintain momentum, your approach is spot on Leon

  2. Debbie says:

    I would challenge this thought further by saying in many cases there is often NO need for development – it is not about CONFIGURATION, as much as EDUCATION, choosing the tools and learning how they can work for a team..

    and it is NOT one size fits all, or a template will work for everyone, – and most certainly iterative, rather than waterfall.

    Means different uses for different teams of people, different stages of maturity throughout the org at any one stage….