It is a time where a lot of thought and writing is going on about how Agile teams could work best. And with results: beautiful frameworks, guidelines, best-practices… Whole books are written about it.
But how it all fits in existing environments and how these environments can best deal with all of this? That seems to be a rather unexplored area. For example: traditional company policies (such as individual appraisals), hard marketing deadlines, conventional accountancy evaluations and quality management systems. There are numerous examples of things that provide the necessary areas of tension on (self-organizing) teams.
A lot of articles and trainers claim, that you could try to change the entire organization and let the teams do it all themselves. This might all work fantastic in utopian organizations, or startups maybe, with self-managing teams who can determine their own salaries, etc. I remember reading several articles that had invented it: DevOps had to be expanded with marketing: MarDevOps or something like that. Others stated that it would be needed that the finances were also managed by the team itself.
Unfortunately, it is not possible to realize the above self-managing FinMarDevOps teams in most of the organizations. But how do you solve the “problems” mentioned above? And how do you as management guarantee quality characteristics such as security, reliability, etc.? Often these are business decisions and management is (traditionally) still held responsible when things don’t go well. After all, they are appointed for that.
I will blog about some of these topics later, but one thing is certain: the average DevOps engineer is really not happy when he/she has to work on an ISO27001 certifiable ISMS. Or has to study the new GDPR. What often makes them happy is having a mission, being customer-oriented and having a certain degree of constraints. These constraints must be created and are variable.
A good Agile coach once presented me with a metaphor: these constraints (freedoms and restrictions) depend on mutual trust and must grow just as children must grow. You don’t just let your 5-year-old toddler cycle to school. You only cycle a few meters behind him if you know that the toddler can cycle well, knows the road, is environmentally aware and isn’t overlooked. On the contrary, the same goes for it: which teenager is happy when parents bring him or her to school every day.
And that, in my opinion, is the role of the Agile manager: embracing and motivating self-organisation, building trust, negotiate on constraints and keeping the no-customer-value stuff away from the teams as much as possible. But most of all, ensure that the bridge between the modern Agile development organization and the (often traditional) environment is continuously built.