A guest post from Alex Adamopoulos, CEO of Emergn Limited
In recent weeks I have been involved in or privy to conversations with four global financial services companies, a research and publishing company and an airline all talking on the topic of the realization of where they are with agile.
Six companies. All global. All leading brands. All using agile. All at a crossroads with it.
All of these companies have the following things in common, almost to the letter:
- Agile, more specifically Scrum, has been used in the IT organization for at least two years and in some cases much longer
- Success using Scrum has been experienced on several projects
- General acceptance of agile has grown across the IT organization and in all cases people on the business side are now aware of it to some degree
- A disparate agile team and staffing model exists
- The business wants more of the benefits from this way of working but none of these companies have gotten enough buy-in or investment to refine the approach that would do make this happen.
- The realization has set in that even though using agile (Scrum) has provided many benefits worth repeating on other projects, there is stall a gap in terms of standardizing an approach across a wider part of the IT organization
In short, these companies are at an impasse. While their IT executives all see the reasons and the needs to go wider and deeper, their cries are ignored by those holding the purse strings. There is frustration and a sense of “what do we do now?” One these companies openly admitted to having watched much of the good work and output just slip away over the last year or so.
The problem can be explained. Much of the investment that companies have made in agile has really been centered on two specific areas: putting an agile development team in place and/or putting two roles on projects, ScrumMaster and Agile Coach. In defense of these investments, for a long time, this was the standard approach to introducing agile. You would decide to dabble with it, bring in a ScrumMaster if you had a handle on what you wanted to do, or an Agile Coach if you knew you were going into deep waters and wanted more hand holding.
Both these roles would work alongside of your team, in many cases improve the team and the project and victory was claimed. It’s right here where many of the challenges started. Companies often add coaches to other projects and in some cases create an internal agile practice or center of excellence but in effect, it really becomes a way to staff roles on projects. It ends up looking more like a resource management function instead of a well constructed, transformation team that has established an approach focused on outcomes and output not just “doing agile.”
What I’ve described above is still a common approach. What I’m suggesting is something completely different – it’s actually a question: What problem are we trying to solve? That answer means I’ll spend my budget differently and probably not on the things I was originally thinking about. It means I might need to have some tough conversations with senior executives and stakeholders. It means many things will be different if we answer it honestly.
I understand I may sound like I’m making some very general statements and maybe seem even a bit harsh. I’m playing back the conversations of these six companies. So while I definitely know there are many companies that are not in this same predicament, there are many more that are.
This predicament that I’m taking too long to explain is that these companies know with certainty that an agile-minded organization founded on principles that adapt better to change is the way forward, BUT the obstacle to getting there is still helping procurement and parts of the business see that they’re not talking about just another product or service which can be auctioned on the street. Rather, the realization is that just putting coaches and ScrumMasters in place no longer ensures that change will stick and that the company will realize the investment 10 or 100 times over.
One of these six companies is taking steps to correct their journey. After investing in building a global agile development practice, they now see that having a disparate coaching model is becoming counter-productive. Their emphasis now is to help this group develop a standardized (yes, sometimes a bad term to use in the agile community, but it’s proven to be necessary) approach that isn’t tied to a single methodology or model but provides for at least a minimum set of practices and principles that are specific to that organization’s goals. Flexibility is still key, but structure has been lacking for all six of these companies when it comes to delivering a predictable, consistent, high-quality service to their customer.
So it’s not all bleak; it just needs to be called out. Others need to know they’re not in this place alone and that they can take the lessons learned and move this forward with some fresh thinking.
How do they do that?
For starters, all six have voiced or rather acknowledged where they are. While this sounds simplistic and a bit obvious, recognition is the first step to recovery (to borrow a term). Secondly, it takes a bit of courage, but half these companies are rewriting their charter and going to the business to develop a joint vision of what “change” means for the organization.
I suppose that is the ultimate question: Why are we using agile? More importantly, what does change mean for us, not only in IT but across our business? For new ideas that need funding and for projects that we know are critical yet challenged, what are the results we want? It’s from this basis that we can then consider the best approach for our organization.
It’s never “we need agile” – it should always be we need this _____ result/outcome (“fill in the blank”).
Read Alex’s blog
The post The Realization of Where We Are With Agile appeared first on VersionOne Blog.