There are many ways to approach a software project. Each process and technique has benefits, but not all of them are right for every product design. In the same way that every piece of software is unique in some way, each project requires a certain amount of planning and design as well.
The approach that suits the desired outcome the best will yield much better results, and under a set of criteria that can lead to better performance from team members throughout the process. In this video, watch as we explain one of these important methods for developing software.
Video Transcript:
Agile methodology
Agile is a very different type of process. It is adaptive. The very idea of agile development is that the processes and the product are expected to change as a result of feedback.
It is also collaborative. The idea is that you have a group of individuals coming together to produce an outcome. They are going to talk and they are going to change things as they go and they are going to optimise. They are empowered to ask questions. They are empowered to try and do things better. So it is a very different type of project. They’re not just there to do a very narrowly defined task. If they can think of a way that the thing they’re doing now is going to affect something two pieces of the process down the road, they’re empowered to say, “hey, I’ve got a worry or I’ve got a concern that needs to be addressed”.
What is agile methodology good for?
Agile allows you to pivot around issues. There is the example of a competitor entering the market. Under agile, you will typically be doing frequent releases of smaller parts of your software. It allows you to make a change. If you put something out and it doesn’t get much take up, you know that you can make a change and potentially reinvent the entire product. There is the example with Email Samurai becoming Content Samurai. We thought it was going to go one way but we built it in an agile fashion, so the end result was drastically different from what we envisaged originally.
It increases your speed to market. Part of it is that desire for feedback. It looks at how you constrain and narrow the scope of your project to produce something that can go into the market and start to get real feedback. If someone will buy your work, or buy a subset of your work; think of how nuts they’re going to go for the whole product.
It spreads your revenue more evenly across the project. But it spreads it in such a way that you can walk away at any time. You’re running through your process iteratively so you’re continuing to come back over it. Every time you do a delivery, you’re at a spot where you’ve got some value delivered into the market, but if you chose to, you could walk away then. You’ve got more value there than if you hadn’t done that release. So you’ve made a net benefit. But at the same time you’ve conserved the other 90% of your budget. You could walk away then. Maybe it was a failed experiment, but you’ve only spent 10% of your money.
It is highly visible when it comes to processes and outcomes. Typically speaking, and I’ll come to this when I touch on Kanban, it will make sure that people are aware of everything that is occurring. You’ll know what the status of things is. You’ll understand where people are engaged in the process and it visualises things very nicely.
Downsides to agile
Agile methodology requires, much more so than waterfall, active engagement from all members. That particularly has a focus on, when it comes to software development, clients. In an agile project versus a waterfall one, I speak with Tania once a day to work on the Typsy product. That is something where we need to remain actively engaged. That can be really difficult from a client’s side. Having someone available to answer questions and have that feedback loop can be a reasonable overhead, so that is a downside.
Flexibility can lead to a misalignment of ideas and miscommunication. If you’ve got a lot of change going on and the team members are not good at coping with change, then you can end up with different people on different pages, not understanding how the process is supposed to work. You get errors that way. You end up with people thinking they’ve done the right thing and it ending up not being the case.
The continuous nature of development can feel like progress isn’t being made. You’re doing all of these small deliveries, so sometimes you can feel like we’ve been going for ages but my full vision hasn’t been realised. You can end up feeling negatively about the project just because you haven’t had that big bang you were hoping for at the end.
You can easily see that the process in which software is created can have a huge impact on the actual type of software that results. The approach of breaking things down into elements that are useful on their own, but designed for a greater picture, means that the development team has to have strong enough communication and common interaction to follow through with updates. This is unique for a project that sets goals which can never be revisited. In this example, we’ve looked at terms that allow for numerous updates, but have to be broken down into projects that can easily be released.
Do you know what kind of software project you are working on? If you’re not sure about the right approach to your next development, give us a call right away.