Product delivery questionnaire

Posted on Leave a commentPosted in management

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?

I. Provisioning

  1. Do you use public cloud service providers?
  2. Are you considering building private cloud?
  3. Are you using containers?
  4. Please describe infrastructure provisioning process from idea to deployment
  5. Please describe any needed areas of improvements/shortcomings of the existing infrastructure
  6. What is the lead time required to provision a new production environment or enhancement?

II. Operations

  1. Please describe how do you plan your capacity? (decision making process, how far ahead, how often, with whom?)
  2. Please describe your disaster recovery strategy, including system backup/restore procedures, simulation of disasters… (how often? who initiates?)
  3. Please describe any dependencies that need to be managed as part of deployment (e.g. CDN, caching 3d party services, …)
  4. Please elaborate on how broadly you’re using opportunities to choose external service providers. Why? What type and size of projects?
  5. How do you ensure that your solution is resilient?

III. Quality assurance

  1. Please describe your quality assurance process: who, what, how, …
  2. What is definition of quality in your team? (SLOs)
  3. Please describe your test planning. Each sprint, month?
  4. How Business/Product people are involved in quality assurance? By whom?
  5. Please describe tools/services used for quality assurance.
  6. What is the percentage of your environment is covered by automated tests?
  7. How often tests are executed?

IV. Continuous integration

  1. Please describe the CI process implemented in your team (how code gets from developer workspace to shared repository)
  2. Please describe the frequency of builds. Why?
  3. Please describe the extent of automated testing
  4. Please describe tools/services used for CI process
  5. Please describe any needed areas of improvements/shortcomings of the existing CI environment/process

V. Continuous delivery (Deployment automation)

  1. Do you have downtimes during deployment? (How long?)
  2. Please describe the extent of deployment automation within the development, staging and productions environments
  3. Please describe the frequency of deployments
  4. Please describe any cases of manual deployments
  5. Please describe the ways used to document deployments
  6. Please describe the tools/services used for deployment automation
  7. Please describe any needed areas of improvements/shortcomings of the existing deployment automation process
  8. Please describe how your deployment changes in case of major changes that require infrastructure or application architecture alterations
  9. What is your maintenance/downtime window and how it relates to automated deployments

VI. Configuration management

  1. Please describe the extent of configuration management within the development, staging and productions environments. How? Who? When?
  2. Please describe the frequency of configuration updates
  3. Please describe any cases of manual configuration changes
  4. Please describe the ways used to insure configuration consistency
  5. Please describe tools/services used for configuration management
  6. Please describe any needed areas of improvements/shortcomings of the existing configuration management process

VII. Monitoring and logging

  1. 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
  2. Please describe who and how uses information? What decisions are made using this information? How often (sprint, month, quarter)?
  3. Please describe who is defining what and how to monitor/log
  4. Please describe tools/services used for monitoring and logging
  5. Please describe any needed areas of improvements/shortcomings

VII. API

  1. Do you understand benefits of building APIs? Is your functionality covered with APIs?
  2. Do you have geographically distributed teams? Do you have many UIs (mobile, desktop)?
  3. Does anyone outside your organization would like to access your data and workflows in a programmatic way?
  4. Do you have platform team to work on following services: infrastructure, guidelines, development/configuration portal?
  5. Have you established API community to drive the topic across organization: education, contribution to common platform services?

 

Typically it reveals following issues:

  1. Missing (or understaffed) service oriented platform teams that focus on building self-service solutions for product teams.
  2. No ability to purchase/rent needed services as temporary solution before internal service teams are established properly.
  3. Quality is not measured which makes it (almost) impossible to prioritize non-functional (scale, technical debt, increased usage) improvements.
  4. 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.
  5. (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/

Agile and Lean meets IT

Posted on Leave a commentPosted in management, process

Was making presentation about how we were transforming IT into service type instead of control type.

Conclusions

  1. Imagine you have to earn money. Perfectly shifts away your thinking away from “cost efficiency”.
  2. Avoid broad terms. Too much room for interpretation.
  3. Control scope. Be explicit about what you can do. Say “no” to things you can’t.
  4. Monitoring and Transparency. Best way to control things.
  5. De-centralize certain activities. Build for scale.
  6. Grow you process. Evolution vs adoption
  7. Know value flow. Local efficiency is not what you need

[slideshare id=54959255&doc=a1269492-f8d5-4ebc-820e-92b27d1d4599-151110160930-lva1-app6891]

Network Structure: Use verbs to describe your service

Posted on Leave a commentPosted in management

we often focus on results and this drives our behaviour – setting targets and metrics, evaluating performance and etc. But is it always right thing to do? Isn’t action is the thing that describes you service much better?

Couple examples from the top of my head:

  • Zero bugs vs Keep customers happy
    • it’s not only zero bugs that will keep you happy
  • Simple ui workflow vs Help user to do the job faster
    • why to keep it simple?
  • High velocity vs Deliver right things on time
    • working fast and delivering random stuff is not needed
  • Files Storage API vs Will keep your files safe, synced, and easy to share
    • which one would you approach first?
  • Taxi Service vs You’ll get a driver in less than 5 minutes
    • there are lots of taxis now
  • SettingHadoop cluster vs Store and retrieve any data you want
    • the second one just explains it better

Why it’s better and more fun? Because verbs:

  • help you better define what problem you are actually solving. early defined deliverables (names of the service) are not necessarily the right ones and you will have to iterate through couple of versions
  • force you to think how actually you are going to solve the problem
  • describe service better as reflect “why” part
  • help you to differentiate yourself
  • help you to start a conversation with your “client”

And all these are very important for network structure as you need to understand easily who can provide what services to you (including yourself)