There is a recurring theme that has been around the agile community for a while now. One so pervading the industry that I have spent quite some time reflecting on it.
Have you noticed that people are questioning the very nature of Agile itself? What IS Agile, people are asking. Is it a set of practices? If so, which ones? Some basic values and principles? Then how do we live them in our workplace, it seems too hard. What do you mean there’s no place for a project manager in Agile? We have loads of them! Speak to people at a conference or two, or even just read through the Agile LinkedIn groups forums and there are lots of examples of this type of question.
These questions (and others) are symptoms of the difficulty some people are having trying to apply ‘agile’ in their own environment. Let’s face it, an internet startup like Groupon or Twitter or Snapchat has a completely different environment to a multi-national Investment bank, a local government department or a defence contractor. A small company trying to figure out what its fledgling product will look like when it’s launched will have a different set of constraints to a company with an old and complex multi-platform architecture with development teams spread across three cities in two countries, a limited budget and a larger portfolio of planned projects than they have people to deliver them.
There are those who believe that Agile means Scrum. And/or XP. It means a small cross-functional team co-located, and delivering in short iterations to get a minimum viable product (MVP) to market as quickly as possible. And then delivering updates as quickly as possible based on feedback from real customers. The Lean Startup model. And these people are passionate about Agile. They live and breathe collaborative estimating and planning, test-driven development, continuous integration and one-click automated deployment. They have no need for project managers with their Big Design Up Front and detailed plans, nor system architects, or sponsors. And don’t even mention governance or… (deep breath) the project management office (PMO). For them Agile is lightweight, non-prescriptive, and fast-paced. It is lean (with a small L).
And there are those for whom this is anathema. Or a distant fantasy – a utopia beyond their wildest dreams. For they believe that their projects just cannot be run in this ill-disciplined manner. That projects need management, and planning, that a portfolio of projects needs governance. That there is a place for Business Analysts and platform-specialist developers, technical co-ordinators, change management teams, and yes the PMO as well. That implementations to Production (of multiple projects) happen maybe once a month (or longer), because there is complexity in parallel development. In this environment the involvement of external suppliers and lengthy contracts are the norm, tools for test-driven development won’t work with the platform and not everything is under source control. The approach to software delivery here is geared around projects – structured, planned endeavours with specific goals and usually a defined end-date.
As you can see, these two worlds (in the extreme examples I illustrate) are very different. Neither is right, neither is wrong. They just are. I call these worlds the Product World and the Project World respectively.
Our beliefs about what is right and proper are generated by our own experiences, knowledge and skills. Those who have experience only of the Product World have a fundamentally different view of what Agile is, and is supposed to be, than those whose only experience is of the Project World.
So we need, I believe, to recognise that these two worlds are very different, and that the same approach to Agile cannot work across both – there is no single transformation recipe, no one ‘best practice’ or method. That each organisation needs a deep understanding of the values and principles behind Agile, and work out the best way to live them in their own organisation. That what is right for one company is not necessarily right for another. And that we should all stop telling each other what is the ‘right’ way, and do more to discuss and learn about other ways in other environments. Sure there are things that we can all learn from other people in different environments, but we can’t assume that they will work the same elsewhere.
Agile is so much more than just a set of practices, and it is not a recipe book. Agile is a philosophy; a way of thinking. And all we can do is be as Agile as we can be, given the constraints under which we are working.