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.
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.
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.
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!