Sharing my talk about network structure experiment. If you want to read more about that you can follow this link – http://agilemindstorm.com/2014/12/19/network-structure-why-part-0/
As network organization is evolutionary and must be constantly adjusted to actual value being delivered you must have evolutionary architecture. Both approaches are aimed to decompose “Big Ball of Mud …”
Even though i think it is essential for network organisation company structured in any way will benefit from this type of product architecture.
You can read more about that in this great article – https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture
Microservices meet this definition because of its strong bounded context principle, making the logical division described in Evan’s Domain Driven Design a physical separation. Microservices achieve this separation via advanced DevOps practices like machine provisioning, testing, and automated deployments. Because each service is decoupled from all other services (at the structural level), replacing one microservice with another resembles swapping one Lego brick for another.
- Build multi-functional team.
- Pick up the problem/challenge/value.
- Define whom it’s important for.
- Define dependencies.
- Define success/failure criteria.
- Slice it.
- Give it to the world.
- Retrieve & analyze feedback.
- Keep #6, #7, #8, #9, #10 – cycle short.
Depends (not important)
- Process you use – less is more. underestimated cost of spreading heavyweight process accross users.
- Tools you use – bottom up standardization normally works much better. but would be interesting to make an investigation how/if tools standardization really helps.
- Planning – as lots of work is invested into making a plan, people try to a void changing it to match the reality.
- Various definition and templates – often do not match real work even before being issued.
- Roles descriptions – typically defined for people below high level management.
p.s. Tayloristic organisation defines “not important” as highly important
Although i am not acting as Agile coach or trainer but surprisingly listed here – 100 Top Agile Blogs in 2015.
Happy and proud to be among great people of agile community. It will definitely encourage me to continue sharing my ideas and thoughts about how to organize work in a company to keep Agile mindset even when you grow from 20 to 600.
Posts that worth taking a look at:
- My influencers – http://agilemindstorm.com/2015/05/12/people-that-made-great-impact-on-my-thinking/
- Network structure – http://agilemindstorm.com/2015/04/20/network-structure-choose/
- Benefits of value/network structure – http://agilemindstorm.com/2014/08/04/value-structure/
- When to fire a Scrum Master – http://agilemindstorm.com/2014/03/12/conclusion-when-and-why-to-fire-a-scrum-master/
- Agile and Lean meets IT – http://agilemindstorm.com/2015/11/17/agile-and-lean-meets-it/
- POD framework v0.3 – http://agilemindstorm.com/2016/03/16/network-structure-it-works/
Thank you for reading.
It was a long journey of trying to understand what organisational structure is best for dynamic growth, experiments, agility and change.
- Value structure – showing benefits of different type of organisation in numbers
- Organizational design – problems – explaining what type of problems are introduced with hierarchical growth and why functional departments are not good.
- Org. design: value structure Highlights from my presentation where i try to explain why do we need value oriented structure in the company
- Network structure – latest explanation why and how to turn into value structure
- Skill-set and responsibility – how are they different?
- POD framework v0.2 – written down practical experiment, draft version
Simple conclusion that i came up for myself – it works! And it is the best way to grow up to an organisation to a scale of 600 people at least. Reasons behind are simple – it allows you to scale fast naturally and have built-in flexibility in the structure to a constant change. Obviously there are challenges which you have to overcome.
TOP 7 Challenges
- Flexible structure is not possible if you want to keep technical foundation monolithic. Devops and Service Oriented Architecture is a must use practices otherwise organisation will not be able to adjust to changing business demand fast enough
- Easy to fallback to local optimizations and thinking that structure is something permanent
- POD Leads and Keepers start to maintain status quo rather than to advocate the change as structure must be adjusted according new findings, growing number of people, speed of delivery and many other things that pop up during the journey
- Extreme sense of ownership can lead to certain local optimizations instead of seeking global improvement
- It’s very important to define common artefacts for PODs as soon as possible so everybody knows what to expect and how to work. You can start from something simple first and grow it naturally according the needs
- Pod sponsor role is extremely critical in order to achieve alignment and solve challenges outside the scope of the POD or priority conflicts
- Especially for service pods which are often understaffed and business value is indirect, but high expectations are formed by the community
- Pod sponsor is an important contributor to network orchestration
- Transparency is key, especially regarding speed of delivery and commitments
- Behaviour and mindset is much more important than experience as new structure depends a lot on readiness to change and constant learning
- Change and adoption core group must be full-time activity and include decision makers (often C-level)
- Plays leading role in network orchestration
- Solves operational challenges together with leaders
But what you get instead:
- you know value creation chain of your company and make dependencies visible
- people are committed and motivated as they are the owners of what they do and decision making is delegated to them
- problems are transparent to everyone who is looking for information and you can act upon them
Updated document with our experience – POD framework v.03, comparing to previous version you will find:
- Description of deliverables and artefacts that can be used as a starting point of your journey
- Better description of roles to handle expectations
- Description of how roles work should together
- Challenges that you must prepare for
If you have some experience building network structure would love to hear your insights, ideas and knowledge.