You are on page 1of 3

Iterative Development - Release More Often

Iterative development is a methodology / paradigm of software engineering that has been around far longer than a lot of
people in IT are aware of, due to the wide spread adoption and project Norm of the Waterfall methodology. Whist there
are certain projects I would definitely choose Waterfall over Iterative Development for Breaking the full scope of a
project down into smaller functional chunks that can be released earlier to customers has many advantages over the typical
Big Bang Waterfall delivery approach.

Much older, far less known "Spiral" Iterative Software


Development model
And Then Came: Agile
Unless you have been living in a cave for the last 5 years, you will have no doubt came across the Buzzword that is: Agile.
Agile is iterative software development, most commonly coupled with two techniques: Scrum & Kanban to help organise
Agile teams with simple to follow processes and light weight project controls. This has resulted in iterative software
development becoming much more palatable to organisations looking to adopting an iterative approach.

Look familiar?

Agile-ish in Enterprise
Over the past 7+ years working with Agile (and sometimes Fragile!), I have seen the methodology in its varying forms and
flavours. Implemented in smaller tight knit project teams, and larger scale geographically dispersed teams, in globally
recognised organisations. I have received training from a leading Agile consultancy & been part of Agile projects that are
being run with large degrees of variance from the Agile Manifesto. I am yet to experience Purist Agile, consistent only in
its inconsistency.

I am yet to experience Purist Agile, consistent only in its


inconsistency.
Enterprise Agile in Practicality
Most Enterprise IT PMOs I have worked in are generally still operating primarily in the Waterfall methodology, however in
recent years there has been a much faster adoption of Agile. Most PMOs have been shaken up by Agile Coaches and
specialist consultancies for the greater good. Talking to other Agile evangelists as a previous regular attended of Sydney
Scrum User Group, Enterprise organisations with high levels of Agile practice maturity still appear to be a rarity. Most
organisations are still running a hybrid of the Waterfall and Agile methodologies. But is that really such a a bad thing? Does
Enterprise Agile Zen even exist?

Does Enterprise Agile Zen exist?


Adapting Agile to Fit Other Moving Parts of Your Organisation
A certain degree of deviation from Agiles core fundamentals is often healthy. Iteratively tailoring the methodology to your
project needs and management style is in-fact the essence of Agile its self! Whilst at Vodafone, myself and the other Agile
PMs did just that. All starting out with typical Kanban boards in JIRA, then tailoring them to address bottlenecks we were
facing on Story Cards & tasks that needed input from departments outside of our Agile teams. Many of whom were
completely new to the Agile concept, and how we operated.

Typical JIRA Agile Kanban Board


Source: Atlassian.com
Manage Software with Agile. Not Your Whole Organisation
Agile is not an enterprise wide, one size fits all approach to managing an organisation. Its a methodology designed to build
better Software. Finance, Information Security & Legal to name a few typical business units that most projects have
dependencies with, do not operate with a similar approach to Agile teams. These established departments typically have
long standing business processes that need to be followed, and us as a newly formed Agile team needed to fundamentally
understand how they operated, in order to appropriately engage them.

Agile is not an enterprise wide, one size fits all approach to


managing an organisation.
Defining your Agile Practice to Facilitate the Wider Business
Simply Shoehorning Agile techniques into existing Waterfall PMO processes is not the right viable long term solution.
Refinement of the PMO processes as a whole should be made to incorporate Agile projects. Different project controls and
documentation standards should be put in place where management reports / project outputs between methodologies
meet. Consideration for how other business units operate should be carefully reviewed, as should there be a mutual
appreciation for Agile processes within other departments.

Address Resistance with Education


Educating other departments about the benefits of Agile is an essential for newly formed Agile teams. Overcome hostility
and resistance to change by adding value, delivering software faster and more frequently. Showcase Agile teams
achievements and welcome the opportunity to further streamline processes with other departments.
Forging & refining Agile processes that streamline with other business units is no easy task, but can be attained thought
collaboration, compromise and mutual appreciation both sides of the fence.
I wish you all the best of luck with your Agile-ish endeavours in Enterprise.

Author: Brad Murdoch


Software Engineering Professional & Agile Evangelist
LinkedIn: http://www.linkedin.com/in/bradmurdoch
Published Date: 02/03/2016

You might also like