When a large organisation “welcomes” an agile project management methodology through their doors they may not know entirely what they are getting themselves into. If we look at Scrum specifically we know that a key role is that of the “Product Owner”. This is the person (or role) that is the gate keeper for new features into a piece of software – but I think that they are more than that, despite what the line management structure within the organisation is, I like the team to think that this is the person that they work for and this duality of chain of command can sometimes create challenges.
A really good example is when through the prioritisation of the Product Backlog the team will need to implement something that contravenes organisational policy. Development teams in particular straddle this interesting space where they work for part of an internal IT organisation, yet they are more aligned to the product owners interest so they would rather do something useful than fold their arms and say “sorry we can’t do that, its against policy”.
Ultimately everything we do is governed by our own personal sense of what is right and what is wrong, and through that what is possible and impossible. Being an external consultant in a lot of organisations I have a certain amount of scope to plead ignorance of internal policies so I watch out for them to the extent that going against them might break the law but turn a blind eye when it causes no pain.
Perhaps I am a bad influence on some teams because of this, but the ability to selectively ignore certain organisational policies allows me to progress some things faster at the risk of being escorted from the building or worse, causing someone some real pain.
Always Reach for the Banana
One of the reasons I do this is to re-test the assumptions that policies are based on because in a lot of cases the reason no longer exists. It reminds me of the story about monkeys in a cage reaching for the banana. I often play the role of the new monkey in the cage and often get attacked by the other monkeys. The lesson I’ve learned is that you have to get the banana very quickly for the other monkeys realise so that you can show them that the hose is no longer going to get them.
Agile Teams Always Reach for the Banana
Agile development teams develop a can do mind-set which is good for the company because they become brave enough challenge old assumptions. All policies need to be tested from time to time to make sure that they still hold true. If someone tells you that a policy prohibits a certain course of action decide whether you should do it anyway, ultimately you have the power to make something happen and if the outcome is truly valuable then only the stupid would punish you for a positive outcome which ended up removing one of those pieces of red-tape.