Agile... all for one, one for all!
“Agile” was a new way of delivering IT software projects, born in 2001 from frustrations of developers at how many IT projects failed. It started as a set of guiding principles. The Agile Manifesto, at it’s heart focused on delivering and doing so regularly, and has grown into a robust set of project management practices that have revolutionised for the better how software projects are delivered.
What’s interesting is that these principles can equally be applied to many other non-IT areas and give great benefit. From this, Agile started to emerge as a huge global movement extending beyond software. Just google ‘Agile Finance’, Agile M&A’, Agile ….whatever your department is!’
From our own experience at Interfuze as Agile consultants this take up by other business areas can be attributed to the fact that Agile, done correctly, helps you succeed in today’s far more dynamic & complex marketplace.
That’s because the result of being Agile - ability to react to the unexpected, adapt to a changing market environment and respond to consumer needs quickly is needed by nearly all departments, not just technology.
Before Agile there was Waterfall
Before Agile, IT projects were delivered using Waterfall – breaking a project down into phases of requirements, then design, then develop, then test, requiring each phase be fully completed before the next is started.
This resulted in the classic IT project you may have experienced; requirements are gathered, nothing more is heard from the technology team before the result is revealed to the business months or even years later. Only then can they see if what is built is what was originally needed, which even if it is (and it never is) it very likely isn’t what’s needed now.
This gap of any business feedback from requirements to delivery is neatly captured by a classic cartoon, defining the frustrations of software development.
Agile processes address the problem illustrated above by breaking the project down and delivering work every couple of weeks to the customer, then using the feedback to adjust what is being delivered, either because requirements weren’t correctly understood or to adapt to changing needs in the marketplace. The first two weeks might have been spent drawing up the design for the ropes, the immediate feedback would have been ‘I didn’t want two ropes, I wanted one’. Phew, a misunderstanding quickly resolved before anything had been built.
Agile in software development
My own passion for Agile and DevOps was born after seeing the difficulties of waterfall software releases on a 30+ cross-continent developer project at Morgan Stanley where getting the 6 monthly update tested and released was a herculean effort and blossomed after moving to Aspect Capital where a colleague & I went ‘Full Agile.’
Taking a frustrated, untrusting business owner we broke down the software they needed into incremental deliverables, delivering real features into production every couple of weeks and turning the business owner into one of the development teams' greatest advocates. The whole project took 6 months but instead of having until then for a finished product he had useful functionality in production 4 weeks in with all the bells and whistles by project end 6 months later.
Seeing how taking an Agile approach transformed both the business / developer relationship and the quality of what was delivered made me a passionate advocate for Agile done well, along the way Atlassian’s JIRA and Confluence have always been a great side kick and invariably appears by my Agile side.
Agile for all business and teams
Here at Interfuze, we apply Agile methodology to everything we do. Agile is a mindset as much as a methodology, helping to you to identify the work of most value to the business that should be done first with more collaboration and transparency.
Here are some of the ways we have seen non-software businesses and teams benefit from Agile:
Speed to market
A common misunderstanding is that Agile lets you deliver work faster. Not true but what it does do is help break down a piece of work and identify the most valuable aspects and get those delivered. This gives you real value earlier than if you’d waited until the complete piece of work was finished before pushing anything out. These short cycles are called sprints, typically 2 weeks long, with the work to be delivered in the next cycle being based on feedback from the last as well as current market demands, which may be very different to those as project start.
Need a real example? Imagine you’re starting a marketing campaign. Instead of creating everything you need before putting out the first advert you have a high level view of the complete campaign but only work in detail on the first advert, doing just enough work to enable you to get that first deliverable, the first advert, done. You put out the advert and get feedback, using that feedback to work on the second advert. Your feedback shows that people are put off by the purple font so for the next advert you switch to green, as you haven’t actually started on the next advert yet that change of direction costs you nothing but you’re now likely to appeal to market better with your next advert.
This ‘just do enough to get feedback and do it in short cycles’ seems intuitive but is not often how we work.
A Trello board or JIRA is a great way to track the high level planned tasks and manage what it going to be delivered from one iteration to another, breaking the high level down into detailed tasks at that point.
Greater team satisfaction
True agile process empowers team members to be accountable for delivering their work and resolving issues and blockers, striving to improve as a team. This builds great employee satisfaction
Organisational transparency
Agile encourages transparency by identifying what tasks need to be done, by which team members and having these visibly available for viewing either on post-it notes or a project management platform like JIRA or Trello. This results in team members knowing who’s doing what, and to support others when there’s obvious blocks in tasks. Funnily while this might sound like micromanagement, but it results in far less managing. If you can glance at a board to see what your team are doing or how they are progressing you never need to ask.
Save money!
Who wouldn’t say yes to saving money for their business or organisation? By lowering risk, embracing change, having faster time to market, and involving stakeholders—businesses save money by building the right product rather than basing development on assumptions.
Need Agile for your business?
If your business is thinking of embracing Agile or need to reinforce it within your teams either from a tools or methodology perspective, I invite you for a free one hour consultation with myself or another Agile consultant in our team.
Just like the Agile principle, let’s start with a consultation to find out what’s the problem, what solutions are available immediately before getting into the deep end.