On The Inside: Is Agile The Right Approach To Take?

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:

“If your company is not open to change or trying new things or running experiments in order to learn, then, Agile is NOT for you.
.
If your organization is not interested in having happy employees by focusing on people or they aren’t willing to make an investment in tools or to look at simple measurements of customer satisfaction such as the Happiness Metric or Net Promoter Score, then, Agile is NOT for you.”

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:

Project size: Agile works better in small projects where you can provide small deliverables in very short periods of time in order to gradually build the final product. You can scale a big project into smaller parts and apply Agile to manage those parts individually, many people have still achieved success this way. The model of scale is in small autonomous units rather than large teams.
.
Think of scaling Agile teams similar to how doctor’s surgeries scale as opposed to roles in a factory. In a manufacturing plant, whole departments are created around specialising on a single function. To scale, you increase the size of the team doing this function.
.
In contrast, every doctor’s surgery is a small complete team where each member is able to do general practice but also covering a specialism for the whole practise. To scale doctor’s surgeries, you don’t hire more people with the specialism you already have but, instead create a whole new complete practice.
.
Customer / stakeholder availability: Agile approaches require high collaboration with the stakeholders as a source of requirements as opposed to a big document from a requirements-gathering stage. The output of the team will only be as good as the inputs. If your customers can’t commit the time or aren’t willing to participate, then Agile is probably not for you. However, It is possible to use a customer proxy as a single input to the team rather access to the customers directly. That very talented person would work to present all the stakeholders’ viewpoints and requirements as a single input to the team. This is sometimes called the ‘product owner’ role.
.
Project team: in Agile, the team is empowered and self-organized in order to accomplish tasks.They work in a truly cooperative environment where leaders collaborate with team members to produce the deliverables in an incremental way. Does that sound like where you work? It’s important to consider if the team is collocated or geographically dispersed in order to evaluate the organization and communications difficulties you may face. It’s possible to have standups over conference calls but it would be easier if everyone was in the same room.
.
Project estimation and planning: The iron triangle can’t be broken. If your management expects all the features to be delivered on a single date 6 months down the line, then Agile isn’t for you. If someone tells you they have a way to do this be very suspicious. Be upfront with your customer, are they willing to continually negotiate on delivered features and/or delivery dates? If the answer is no then the knives have to come out. Use a change control process to force a contract change or a rejection of any ideas that the customer comes up with during the project.
.
Organization’s experience of an Agile methodology: if your organization is new to Agile concepts it will take more time and effort to adopt those processes before they can be applied to a project. If that is the case, you may start talking about Agile and promote its use among your teams.

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

 agile