Agile Development
From my writing, you will perhaps be aware of my passion for agile, but also my diva-like obsession with its appropriate application. Agile is of course much older (as a method) than most people seem to want to accept these days (and I have personally been working with it for most of my 25 years in IT). Even before the emergence of (true) Waterfall in the late 1970s, there was always a healthy debate in software engineering about the importance of being 'correct' versus the urgency of being 'quick'; with one side of that debate arguing for 'learning by doing' (through iterative prototyping) and the other side advocating for clarity on requirements up-front. It is my considered view that this argument will never go away, because it will always - rightly - remain a key question in any development effort.
> For more on the origin myths in Agile & Waterfall, check out my Agile v Waterfall piece > Check out "the mayor of Kingston Town" for a case study on how to chose well
The Agile SDLC
At the risk of stating the obvious, Agile is a software product development lifecycle & method. It never ceases to amaze me how many people don't fully 'get that'. Or how many (mainly tech) businesses describe or define Agile as a project management method. It isn't. Put simply, Agile allows for software development to be divided into a series of (grouped) tasks, for requirements to emerge or be refined over time, and for plans to be revised based on continuous feedback. This contrasts with 'structured' development methods like Waterfall, where there is a 'correct' answer at each stage (of requirements, design, development, test & release). Gartner used to call this Mode 1 vs Mode 2.
> Try out my Agile-o-meter tool to help you decide on Mode 1 vs Mode 2
Application of 'Pure' Agile
But I digress. The purpose of this article is to look at three situations where pure agile can be safely applied, as the most appropriate method in all circumstances and without undue risk. Particularly if your organisation is still relatively immature in agile adoption, these use cases can be a great way to get started; developing muscle strength and muscle memory before you tackle more challenging scenarios; in an effort to reach true enterprise agility.
> I cover this topic in more detail in my "creating an agile enterprise" article [1]
1. Continuous Improvement in BAU
The best place to use pure agile is in the regular cadence of business-as-usual continuous improvement (i.e. of an existing product). As development and/or configuration tasks are completed, the team will output 'Potentially Shippable Product Increments' (or 'PI's); i.e. items that have been tested and confirmed against the quality 'definition of done' for that feature. They will then be grouped into - and targeted for - an upcoming release to live. I tend to categorise PIs - by origin & purpose - as follows:
small changes / enhancements to a product (to meet a service request)
bug fixes to a previously released feature (to address an incident ticket)
service improvements (to address more systemic root causes of problem tickets)
housekeeping & essential maintenance ('self generated' by the dev team)
Whether an item is business-originated (the first three above) or self-generated by the dev team, all items need to be approved by the Business Product Owner as shippable before they can be added to a release. Moreover, before the work on any of these has been started, the Business Product Owner needs to 'legitimise' them into the work management system (as valid work to be done) and 'prioritise' them against other needs in the work backlog.
2. (Innovative) New Product Development ('NPD')
Agile is also perfect for the development of totally new products, specifically where these are innovative by nature and requirements are best allowed to be 'emergent' as the prototype is continually refined. In such a circumstance, what you actually develop in the end can end up very different to what you 'first thought of', just as the business proposition can evolve to a very different end-point (as the value of the features are tested in the market).
Proper Market Research is a vital component of NPD; including competitor analysis, reviewing the addressable market, and an analysis of the (customer) 'job to be done' with prospective users/consumers of the product. An allied (digital) technology discipline is that of (human-centred) user experience design; where one develops a set of personas to represent different segments of the addressable market / prospective user base. By exploring persona behaviour, motivations and goals, one can identify gaps in provision; which the new product can meet.
> See my forthcoming arc on 'product management for disruptive innovation' [2]
> And also, a completely different upcoming arc on 'human-centred design in agile' [2]
Innovation is my thing :) In my main, day job we are currently building an industry-first (and AI-powered) end-to-end marketing platform. I have written about the career-defining challenge and amazing innovation of WPP Open on my LinkedIn. What I didn't say there - but is 100% true - is that it is a perfect sort of initiative for Agile (which has been very successfully deployed on the programme). In the past, I have also used agile very successfully on NPD projects to build the world's first IoT Structural Health Monitoring Platform (for the Forth Road Bridge) at Arup and to develop AA Navigator (the UK's first commercial SatNav) at Centrica.
3. Client Tech Product Management
I hope you will recognise the distinction: in most larger organisations there will be 'client technology' products you develop for your clients to use, and 'enterprise technology' products you configure for your own use. For example, a training company might develop an e-Learning platform for its clients, but might choose to simply configure Microsoft Office 365 for its own intranet and collaboration needs (rather than trying to build its own bespoke solution).
So if Client Tech is all about programming and building something and Enterprise Tech is mostly configuring and product managing something, then Agile definitely works best for the former and less well for the latter.
Final Thoughts
An interesting question would be "what is not on the list above and why?" The answer is most of the enterprise technology projects in most organisations. Unlike the 1970s and 1980s, most of the enterprise tools people use today were built for them by a vendor (rather than built in-house). Moreover, most enterprise projects have a clear set of largely known requirements, within a known, finite and approved budget. None of these scenarios are great for agile.
> Check out my piece on tri-modal agile for how to deal with most projects
As ever, good luck with your efforts! Working in an agile way is loads of fun. Especially when you do it right - and do it on the right things!
© David Viney 2023. Licensed for re-use with attribution under CC BY 4.0
Preferred Attribution Code Snippet
The <a href="https://www.david-viney.me/post/3-best-situations-to-use-pure-agile">3 best situations to use pure agile</a>, by <a href="https://www.david-viney.me/">David Viney</a>, licensed under <a href="http://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>Footnotes
[1] Forthcoming articles in this arc; please check back soon
[2] Future story arc; coming later this year
Like the Post?
Comments