Agile for non software and systems engineering
At a meeting of Vancouver Technology Leaders a few years ago now, I'll never forget my first interaction with the group. Conversation was flowing and I kept hearing "Business this" and "IT that", Business and IT, Business vs IT etc. My first question was to ask about this seemingly shared perception that there was a dichotomy re Business and IT. For me, unless your Business is IT, there is the Business. IT, just the same as Legal, HR, Operations, Sales etc. (think Porter's Value Chain model) is a part of, and exists to enable the Business.
Similarly, I attended an Agile Vancouver conference in October last year and one of the panel members on the stage in a session asked for a show of hands re the circa 200 people in the room. Firstly, "whom here is from IT". 199 people vigorously raised their hand. Then, "Anyone here from the Business". I raised my hand in a sea of solitude. All in good jest, the panel member proclaimed "ah, there is always one...", to which my first response was (again all in great jest with audience and I laughing at this exchange) "but I wonder if that is part of the problem..."
I mention these two events merely to share my perception that quite a few people often see a divide between Business and IT and for Agile, their remains some frustration (IT and Agile practitioner communities) about a clear understanding from Business about what it is, what value it brings etc. But a part of the challenge may be that, often, Agile events/conferences are heavily attended by our more technical colleagues and invariably discussions, topics, presentations etc. inevitably seem to drift into a more technical direction. I’ve yet to see anyone at such an event provide a focused application of Agile for non-technical use.
So first question: is there still work to do to make the subject of Agile more accessible by our non-technical “Business” brethren?
My next question: is Agile solely applicable for Software/Systems engineering?
We have experience of many of the Agile family of practices, behaviors, techniques (DSDM, Scrum, PRINCE2 Agile and predominantly SAFe for reasons of its enterprise level coverage/completeness) and, whilst the fact it Agile practices were born in the software development domain, I struggle with why the vast majority of those behaviors, practices, techniques etc. can't be applied in a none software/IT domain. It’s just my background and default lens I suppose, but I always look at things from a business perspective first. To me, IT is an enabler to/of Business - and an ever increasingly important one in these technology dependent times.
Let’s take the Agile Subway Map infographic. For those not familiar, an interactive version is available at www.agilealliance.org. I would suggest some (but only a very few) of the “stations” on this map are solely technical disciplines. For example, Automated Build and ATDD really do spawn from the technical domain. But as per any good toolkit, we don’t need all tools in the bag for every job we do so, for a business (non-technical) activity/initiative/project etc. where some of the benefits of a more nimble, “Agile” approach would be of value, we’ve simply no need to apply the ATDD wrench.
Take a look at the rest of the map, various boards and information radiators (metrics/progress/issues etc.), concepts of estimating, planning, organizing, accountability/role clarity and management operating rhythms that foster short cycle iteration enabling performance and learning cycles focused on working solutions rather than vanity metrics are present. Why can’t all of these, in their entirety, apply to non-software related activities?
One of the core capabilities of my firm is our SAFe training and consulting practice. We’re a SAFe Gold Partner and understand and apply the behaviors, principles, practices and techniques with our clients often. Apologies here to my SAFe colleagues/partners, but just about the only thing that mildly frustrates me about SAFe is the mandatory labelling at the top of the model – shown here:
"SAFe 4.0 for Lean Software and Systems Engineering". Just my personal thought, and to be fair, I’m fully aware that the founders of SAFe were focused on the software and systems delivery issues de jour, so no blame factor here at all, but I’d like to solely depict the title as “Scaled Agile Framework for the Enterprise (SAFe)”.
Whilst targeted at software development and systems engineering by design, does even the title of this framework turn-off our non-technical cohort? Wouldn't simply spelling out SAFe in full (which respects fully SAFe) be more inclusive and entice a wider audience to peek under the hood of SAFe? Could the heading/title be a limiting factor re wider scale awareness and/or adoption of applicable elements?
Back to the Business and IT divide. Couldn’t we excuse some Business leaders for thinking that this framework is solely the domain of their IT counterparts – that’s what they get paid for…? Wouldn’t it be healthy for the CEO, COO, CFO or other more traditional Business roles to be advocating for SAFe/similar and asking their IT colleagues to engage with them in exploring its virtues, value and viability in their enterprise?
I look at SAFe, as I do all other Agile frameworks/models, and, in my opinion with very little adaptation, there is a wealth of value in the behaviors, practices, techniques etc. espoused that could (and should) be leveraged more fully in standard business operating models.
Do we in the Agile community need (want?) to peel back the technical layers a little to broaden the interest and potential applicability of things we know are proven to deliver business value?