When I join product team or company here is the list of questions i have in my mind. What do you think about that? Do you think some questions are not relevant? Is there anything you would add?
- Do you use public cloud service providers?
- Are you considering building private cloud?
- Are you using containers?
- Please describe infrastructure provisioning process from idea to deployment
- Please describe any needed areas of improvements/shortcomings of the existing infrastructure
- What is the lead time required to provision a new production environment or enhancement?
- Please describe how do you plan your capacity? (decision making process, how far ahead, how often, with whom?)
- Please describe your disaster recovery strategy, including system backup/restore procedures, simulation of disasters… (how often? who initiates?)
- Please describe any dependencies that need to be managed as part of deployment (e.g. CDN, caching 3d party services, …)
- Please elaborate on how broadly you’re using opportunities to choose external service providers. Why? What type and size of projects?
- How do you ensure that your solution is resilient?
III. Quality assurance
- Please describe your quality assurance process: who, what, how, …
- What is definition of quality in your team? (SLOs)
- Please describe your test planning. Each sprint, month?
- How Business/Product people are involved in quality assurance? By whom?
- Please describe tools/services used for quality assurance.
- What is the percentage of your environment is covered by automated tests?
- How often tests are executed?
IV. Continuous integration
- Please describe the CI process implemented in your team (how code gets from developer workspace to shared repository)
- Please describe the frequency of builds. Why?
- Please describe the extent of automated testing
- Please describe tools/services used for CI process
- Please describe any needed areas of improvements/shortcomings of the existing CI environment/process
V. Continuous delivery (Deployment automation)
- Do you have downtimes during deployment? (How long?)
- Please describe the extent of deployment automation within the development, staging and productions environments
- Please describe the frequency of deployments
- Please describe any cases of manual deployments
- Please describe the ways used to document deployments
- Please describe the tools/services used for deployment automation
- Please describe any needed areas of improvements/shortcomings of the existing deployment automation process
- Please describe how your deployment changes in case of major changes that require infrastructure or application architecture alterations
- What is your maintenance/downtime window and how it relates to automated deployments
VI. Configuration management
- Please describe the extent of configuration management within the development, staging and productions environments. How? Who? When?
- Please describe the frequency of configuration updates
- Please describe any cases of manual configuration changes
- Please describe the ways used to insure configuration consistency
- Please describe tools/services used for configuration management
- Please describe any needed areas of improvements/shortcomings of the existing configuration management process
VII. Monitoring and logging
- Please describe the extent of monitoring and logging within the development, staging and productions environments. Types of metrics, frequency, size of logged data, period of time
- Please describe who and how uses information? What decisions are made using this information? How often (sprint, month, quarter)?
- Please describe who is defining what and how to monitor/log
- Please describe tools/services used for monitoring and logging
- Please describe any needed areas of improvements/shortcomings
- Do you understand benefits of building APIs? Is your functionality covered with APIs?
- Do you have geographically distributed teams? Do you have many UIs (mobile, desktop)?
- Does anyone outside your organization would like to access your data and workflows in a programmatic way?
- Do you have platform team to work on following services: infrastructure, guidelines, development/configuration portal?
- Have you established API community to drive the topic across organization: education, contribution to common platform services?
Typically it reveals following issues:
- Missing (or understaffed) service oriented platform teams that focus on building self-service solutions for product teams.
- No ability to purchase/rent needed services as temporary solution before internal service teams are established properly.
- Quality is not measured which makes it (almost) impossible to prioritize non-functional (scale, technical debt, increased usage) improvements.
- No multifunctional teams with a mix of #1 and #2 leads to additional stress on teams responsible for a service due to additional headache of prioritizing scarced resource. It also reduces possibility of exchanging feedback between product teams and service teams, which is crucial for building internal services right.
- (Almost) no focus on automating activities related to software delivery and maintenance which increases delays and manual work as solution complexity and usage increases.
More lessons learned – http://agilemindstorm.com/2017/02/18/network-structure-11-lessons-learned/
- 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
It was a long journey of trying to understand what organisational structure is best for dynamic growth, experiments, agility and change.
Simple conclusion that i came up for myself – it works! And it is the best way to grow up to an organization 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 organization 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 artifacts 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
- Behavior 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 artifacts 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 experience organizing work as a network of autonomous teams, I would love to hear your insights, ideas and experience.
Is it possible to build an organisation which benefits from uncertainty, errors and randomness?
- How small should be the teams?
- What should be minimum process?
- What is the level of centralisation/decentralisation?
- How often achieved agreements must be reviewed?
- What behaviour is needed?
- What is the ratio between explicit and self-discipline?
- What is the level of autonomy?
- Can growth be the target?
- Should it reflect value delivery?
- Should org. look different depending on the context?
- Should unstable be new stable?
Those are curse words for any member in a company. Often companies are designed as if for any non-repetitive task it is exactly known what is going to happen and what is the most efficient way to do that.
What manager does? Their main focus is not on people performance and their efficiency, not about rules or KPIs. These are tools that are selected or built with your team. Instead their focus is on value creation, environment and principles.
Want to share ideas how i manage for some reasons:
- it might be helpful to others
- it is extremely curious to me if my point of view is going to be different when i read it later
- learn from others so comments and feedback are welcome
Environment. Results are very important, but we won’t be successful as a team unless each individual is fulfilled.
Style. “Ask. Understand. Change.” Process is only a tool, understanding your business is essential. Go out and talk to people. Adjust to business demand and make changes fast.
- Humor (sometimes even rude) is a big part of the game.
- Direct person. This is my natural behavior. I expect this from my team.
Problem solving. When a challenge is presented, bring along several solutions, one of which does not include spending (more) money. Always try to understand root cause – why, why, why,…
Meetings. Book a meeting only if it can’t be avoided. Prepare, engage invited people, come out with actions.
Professionalism. High internal standards push me to do things in a best way possible. Same is required from team members.
Learning. “Experts” can ruin everything as they are not accepting new information. If you are not changing and learning new things than something is wrong with you.
Change. Processes, tools, structure must always be adjusted to business needs
Winning. My definition of “winning” is that everyone wins: employees, customers, users.