There’s little wonder that more and more companies are trying to shift to agile. Waterfall is the Great Filter of software development, limiting teams’ ability to thoroughly explore solutions to a problem. But on the flip-side, going agile is unfortunately very hard.

So many little factors make up agile success. Agile requires the full buy-in of the organisation to respect how the methodology functions. It needs routine planning and retrospectives. It needs time to establish itself within the day-to-day operations of the organisation.

Most importantly, it needs the right kind of mindset – which means always being switched on to possible improvements and warning signs to your current system.

Early agile software implementation warning signs

Is any of this familiar to you?

  • Your manager is booking meetings that overlap with your developer stand-ups.
  • Some team members think stand-ups are optional.
  • No feedback - good or bad - during your retrospective.
  • You don’t have a feature roadmap to success - or you did, but you abandoned it.

Some of these things might seem harmless on their own, especially if they only happen once or twice. But allowing these things to happen means exposing yourself to risk. Too much risk, and you’re going to have a bad time.

Thinking that stand-ups, retrospectives and evaluations aren’t compulsory is a Waterfall way of thinking. While your agile process can technically survive without disciplining these processes, can you be sure you can’t do better? To really thrive, agile software implementation requires constant checkups – or it wouldn’t be called “agile”.

5 core principles to keep in mind

  1. A motto I use: “Be thorough. Be ambitious. Be precise.” Agile doesn’t mean abandoning greater goals. Challenge your team to not blindly accept, "It was what was written on the ticket", and instead empower all members of the organisation to give their feedback. Ask, "Can we do better? Is it outstanding?"
  2. Remember to always work with, and for, a purpose. Not having a purpose makes it hard to have and keep a clearly defined scope. When the scope of work is vague, the outcome is usually an express ticket to Mediocre-ville.
  3. Avoid partial results: it only increases the risk of double handling the workload, which further delays and adds complexity to a solution.
  4. Don’t forget that agile was designed for flexibility. It should be ok to re-evaluate requirements, revise a design after it has been implemented, and refactor surrounding code to make a new feature more performant – at any stage of the development cycle.
  5. Sometimes all the planning in the world isn't enough when facing challenges to implementations that yield lofty compromises. It takes a lot of courage for a large organisation to be open and understanding of situations and appreciate both the developer and end-user.

At Objective, we have the opportunity to use spikes to explore new technology for bespoke features. Our retrospectives identify use-cases of existing features that we can export to the new technology. This keeps the work interesting and improves the skill base of the team, all in the same process.

At the end of the day, it is results that matter. From software maintainability to customer satisfaction and support. Getting the best results possible means taking the time and dedication to fully commit to the process you’ve started. Making sure your team internalises the right mindset is the key to achieving the outcomes you want.

Interested and experienced in agile? Check out our job listings, and be a part of a team that lets you develop in the way you want.