A project manager walks into a bar. The bar is called “organizational design”.
He tries to order beer but can't figure out how. Then disappointed he is about to exit the bar, but can't locate the exit.
Apparently he looks around and notices a lot of other managers around in there. "That’s a trap." - he thinks. "It is a complex system" - echo the others.
This week I spoke at Agile Tour Vilnius 2016 and PM Day Kyiv 2016. In November I'm visiting Lean Kanban France 2016.
This is my third increment of this talk and now I'm happy how it goes: spaghetti, Japanese poetry and complexity seems to be a good combination for any talk.
Below are some photos and selected slides. Down below are a full slide deck. Video is in post-production. Enjoy.
Just last week I spoke at two conferences on Organizational Complexity and Its Effects on Scaling.
The talks went pretty well and I ended them up presenting three most commonly seen (by me) team structures that create an "interesting" dynamics.
Here they are:
This one is seen very often in gaming companies.
There is absolutely nothing wrong with reusing an engine (platform), that's actually a great idea. What I'm talking here is about the managerial decisions on forming teams around these architectural layers.
In this case a set of consumer-facing teams will be building "their" features (products) on top of a shared platform "owned" by another team (teams). If this is your case, you often hear terms like: "engine teams" or "platform teams" or sometimes "system teams".
It is exciting (for a system thinker) to observe how unaligned those two types of teams can be. How much information needs to be handed over from the consumer teams to the platform teams to get "their" back-end part right. How much over-processing and over-production can be created on the back-end side. And how hard it is at times to get the whole thing fly to production, once all teams say "we're done!"
Beware of the system dynamics such structures create.
This is a very common example for so-called "web" companies that had emerged in the pre-mobile era, had built their product(s) on web and later on then started the mobile adoption.
For such companies it is not uncommon to create the pure "mobile teams". And with a good intend: hard focus on mobile technologies, fast delivery of the apps, separation of responsibilities, reusing existing "ready" APIs... There are many good intentions why to separate the mobile teams form the rest of the "old" organization. And the road to waterfall is paved with them.
In such setting you often hear terms like "mobile teams", "iOS teams", "Android teams", "web teams", "API teams" - such names being used to identify specific teams, backlogs, product owners, roadmaps. As of course it is rational to let each of those teams do their own "scrums".
Guess, how flexible, rapid and agile such a constellation is when suddenly you need to launch a new product on both platforms: web and mobile!
Beware of the dynamics such locally optimized constellations creates.
And lastly, this. The company embraced the idea of "full-stack", "feature" development teams - where each teams has all required specialization to be building the product features end-to-end.
But since the product is huge, it is of course rational to try simplifying the complexity by the old roman principles: divide and conquer. Anyone seen Romans recently?..
Indeed, it does feel right to break up a huge product into areas - that small that each can be "managed" by one product owner with a small development teams. Then each team has its easy-to-facilitate planning, review and a retrospective meeting. A ScrumMaster can be fully dedicated to the team and everyone is fully focused...
...Focused on a small piece of an overall big picture that no one is able to grasp anymore. The company turns into an unassembled puzzle. And it takes several layers of managers to start seeing the bigger picture... That's often an illusion of management, because no one is capable of understanding an unassembled puzzle.
Be ware of the dynamics your rational decisions create.
Among the many thinking tools, there is one called "Causal Loop Diagrams". Or the CLDs.
It is a way of modelling dynamics of a system through "variables" and their "relationships". The next illustrations should give you some high-level idea:
Modelling is a powerful way to get engaged in meaningful discussions.
And we all know from Alistair Cockburn's insights that no other way of communication beats several people talking while sketching on a whiteboard:
So, you wonder how you can get "you management" reconsider the structural decisions they have been making? Mobile teams, platform teams, small-product teams... That's hard and everyone needs to have her own epiphany to change her mind.
This takes time. But this as well can be facilitated and hopefully speed-up. For example, why not running an small in-house workshop with your decision-makers to let them explore some of the dynamics at play?
You don't have to call it a "system dynamics workshop" as this can scare mindfulness out of some of your people. Call it a retrospective. Call it a beer game. Call it anything you want. The goal is to get people talking about meaningful stuff.
The CLDs (or any other system thinking tool you know) might be of your great helpers.
As well as some food and beer to follow.
I've re-brushed my CSPO class. Yey.
And I'm currently validating it being on a trip to Tallinn, Riga, Helsinki and Vilnius.
The class has lots of flip-charts, simulations and table discussions, which makes it really hard to share the full experience of it.
Here are some slides to give a little taste:
Sign up for the newsletter.
No spam. Only relevant agile news and updates from Alexey Krivitsky.
(C) 2015-2016, agiletrainings.eu