Welcome back to On The Inside! This is part 2 of my Agile adventure at Allthings, a technology startup in sunny Dundee building a group project collaboration tool. If you haven’t read part 1 (which is all about diving into the deep-end!) then you can find it here. I’m trying to give an honest, personal, warts-and-all account of our journey. This time I want to to figure out if Allthings is ready for an Agile approach or not…
We’d just had our first successful release and the team were on a high. There was a lot of energy and more than a few high-fives, I wanted to act quickly and use this energy before it dissipated. The next step for me was to figure out if we should be taking an Agile approach. Was Agile right for us and what we’re trying to do at Allthings?
It’s not a forgone conclusion, although many people and blog articles will tell you that it is. There are many other successful alternative approaches.
You need to ask some questions to find out if Agile is right for your situation. Is the business willing, and able, to live with iterative and incremental releases? Does it have the level of engagement and communication necessary to make it work? How will Marketing and Sales cope with, small fast-release cycles? With the amount of change that is required it should come as no surprise that using an Agile approach is not a ‘one size fits all’ approach to software development.
Danielle Guillo put it very well in his recent blog post on Agile management:
It is perfectly possible to build some types of software using a repeatable template, removing creativity and innovation from the process. It’s even desirable on some occasions, say when there’s no tolerance for risk. Perhaps lives are on the line, or the desired solution is so well known that there is no need for the team to be innovative.
There’s no need to use Agile on a project it’s not suited for, just use a different methodology. It’s not like there is a shortage. The software industry has been coming up with new solutions to the problem of software development for decades. However, it’s still hard, and most projects still fail to either deliver what the customer wants or even something at all.
So what should we look for? How do we know if the project we’re about to start is suitable for an Agile approach? First, take a look at the types of project. Ralph Stacey, Professor of Management and author of Complex Responsive Processes in Organizations: Learning and Knowledge Creation, categorised projects by the technological risk and the understanding of requirements:
- Simple projects are those where the requirements for the solution and the technology needed to build it have been agreed before the project begins. Waterfall or another more formal process works well here.
- Complicated projects are those where either the requirements have been agreed or there is a certainty regarding the technology that will be used. Most software projects fall in here. Agile is a good bet for this kind of project.
- Complex projects are those where both the user requirements and the technology needed have not agreed. This is the Agile wheelhouse, the flexibility and feedback in an Agile process allows for the necessary exploration of the problem.
- Chaotic projects are those where there is no agreement about user requirements and the technology needed for control is unknown. This is the state of a typical ad-hoc software project. This usually means that it’s time to rethink how the project is being approached and governed.
We’re getting closer to a solution, but these aren’t the only factors you should consider when selecting your project approach. You should also look at:
Essentially, the decision to use an Agile approach comes down to the type of project you’re attempting, the team of people that are going to be working on the project and the environment they are going to be working in.
Back at Allthings, to get a consensus, I put together a presentation, gathered everyone in a room and gave them the same kind of information I’ve put here. Then I just asked the question, “Are we ready and willing work in an Agile manner at Allthings?”. The question was loaded and anchored by both the presentation and the energy after the release, but the answer was “yes!” as I’d hoped.
The real work of getting the business and technical sides of the project aligned starts now that we’ve agreed together we’re going to do it.
Then it was time for me to look at the backlog and the bug list and see how I could make some sense of it so that we could create rough roadmap to follow -not a plan to follow to the letter, but a sketch map of our intentions.
That’s what I’ll be writing about in the next installment of On The Inside…