“Agile is good, but we need management support for it“. “Agile adoption should start from management“. “Our agile adoption failed because management didn’t support it“. You hear it all the time, right? Indeed, such claims are everywhere. For example, 7th VersionOne’s State of agile survey says that in 63% cases initial agile champions were from management and also 31% says that management support is the biggest barrier for further agile adoption.
Well, it seems to me more like excuse then like a real barrier. People sometimes forget that bottom-up approach to agile adoption is all legal. Mike Cohn in his book Succeeding with Agile call it a “natural” approach.
I think that one of the reasons for such view could be that people don’t start from principles, but from practices. Starting directly from practices like Scrum could make you believe that you need deep organizational changes to start your agile journey. And organizational change needs, you guess – management support. What’s even more interesting that another reason is waterfall itself. To be more precise waterfall’s big upfront planning rule. It’s a kind of thinking legacy built into our brains that everything, including agile adoption, should be planned in details to succeed. And such big upfront planning and big decisions need, again – management.
Agility is a set of principles applied not only to an organization, but to people, too. Uncle Bob goes even further from here and says that “TDD is a personal decision“. Such a thought can be applied to some other practices and principles like kanban, pair programming, refactoring,…
Everyone should be aware that adopting some agile principles DOES NOT depend about management. I was a part of a team that tried and succeed in adopting Scrum without explicit decision and guidance by management. You can start tomorrow. No excuses!
It will happen that your manager will come back from some conference or training and will ask you to adopt agile. Put yourself in a position that you can say: “Dear boss, we’re already agile”.
I know there is a lot of debate if coexistence between traditional PMO and agile is possible. A friend of mine usually say that being agile or not is pretty much the same as being pregnant or not – you are agile or you are not. Instead in this way, I like to think of this topic like agile is an art of possible. Sometimes is just not possible to adopt all agile practices, because of a thousands of reasons. At least is not possible in short time and for a whole organization.
A month ago I was involved in an initiative to establish such coexistence between traditional PMO and agile development. It is a quite large organization where agile development grown bottom-up, so a number of development teams already practicing agile (mostly Scrum) for some time. Because of a good results, a consensus in high management resulted in initiative to better organize work between PMO (which is still organized traditionally) and agile teams. After a discussion, I proposed a model like this:
An idea is to enable agile teams to function as much agile as it’s possible inside large organization which is still mostly organized in a traditional way. So, let me explain this idea:
Every agile team is responsible for a single product (application). Notice that I did not say project, but product. Every agile team has Scrum master (SM) and Product owner (PO). So, this part is fully agile and use Scrum.
From the other side, there is a PMO. A PMO will designate a Project manager (PM) for every project they decide to start. PMO is influenced by stake holders, some boards etc. This is a traditional side of story.
So, where is the bond between these two sides? An idea is that PMs will work with all POs whose products are related to a particular project. PMs will influence POs to adjust their Product backlogs to fulfill project goals. Also, PMs will do all administrative project tasks and generally all job that they are familiar. At the same time, development team is isolated by SM and they do their job in an agile way.
Some early results of such approach are very good. A good thing is that only PMs had to modify their behavior, but only partially. Another important thing is to look at this model only as a step in a process of making all organization agile. Any other goal doesn’t make sense.