Why and how we do audits
Imagine that you have something sick (God forbid, of course). You go to the doctor and there are two possibilities:
Personally, my colleagues and I like the second option, which is why when we are asked to implement “these your Ajails,” we conduct an audit. But we are not like PricewaterhouseCoopers - we are better, we are informal and we give valuable results. How exactly - read under the cut!
Most often, we conduct an audit in three days. The first day and a half are held in the collection of information with the client, another day we do the analysis, and then we make a presentation in half a day. Now a little more.
')
At the beginning we communicate with the audit client. to clearly define the purpose of the audit, the reasons for the audit, the expectations of the audit and the willingness to change. From this depends on what questions we ask and what recommendations to give. Then, along with the lead project (technical, managers, analyst leaders), we draw the value stream map (VSM). What it is? This is a description of how a business idea through development ultimately reaches the end user. It looks like this
VSM allows you to understand areas for improvement and unnecessary steps that do not add value and are a source of losses.
Then we collect developers, testers and analysts from this scheme in turn and give them 10 minutes to write about the problems that they experience during a particular product development step. Stickers help us with this as always. After 10 minutes, we work together on all issues, jointly fix and discuss them.
Since we carry out the audit either together or three, then we separate and find out the details on the technical and product part of the development.
From the point of view of technology, it is important for us to know the following things:
From the grocery point of view, the following aspects are important to us:
Usually the first day ends there and we take a timeout.
The next half of the day we continue to communicate with the team.
For developers, testers, and system administrators, we take the following two exercises in turn.
First is the Speed ​​Boat. The bottom line is that we draw a ship on a large sheet. This ship is the development process, and the problems that exist are the reefs for which the ship's anchor clings. The task is to write near the anchor, for which it clings. The degree of importance of the problem can be reflected in the depth of the anchor, the deeper - the more serious the problem. Oddly enough, these problems almost do not overlap with the fact that before that people spoke at VSM. But besides the problems, we also fix what is positive or would like it to be. In the case of a ship, it is the wind that blows into the sail.
After we’ve finished with the ship, together we are completing the second task - we build the project’s infrastructure: servers, storage, services, and so on. What is most interesting in this case, each next group, says "And how much they did not draw ..." or "Yes, they all incorrectly displayed!"
Also, in the Speed ​​Boat format, we communicate with the recruiters of the company. This is necessary for understanding the mood in the company, motivating people and so on. Once, it was communication with recruiters that helped in understanding the problem in detail.
After that, it is time to process the results. I will not reveal all the secrets, I will say only about two points.
First, we sort out all the problems in the following groups:
This partition allows us to understand the current level of maturity of the company according to our internal model:
After all this, we are preparing a proposal and slides. It is also worth noting here that we are preparing the presentation on large sheets of flipcharts using infographics and Visual Notetaking techniques. The feature of the sheets is a sticky edge, which turns them into giant stickers that remain after the presentation with the client. The presentation itself lasts about 3-4 hours. During it, we tell what we saw in two days, what we felt and what problems we fixed. In 99% of the entire audience agrees that such problems exist and they must be solved. Thus, an additional objective of the audit is achieved - to open people's eyes to the fact that someone besides them has a problem that can be taken together and solved by joint efforts.
This is how the three days of our audit are so intense and energetic, and everyone is happy with each other.
- "Cut to hell!"
- You are going to get tested and then learn that you just ate something wrong
Personally, my colleagues and I like the second option, which is why when we are asked to implement “these your Ajails,” we conduct an audit. But we are not like PricewaterhouseCoopers - we are better, we are informal and we give valuable results. How exactly - read under the cut!
Most often, we conduct an audit in three days. The first day and a half are held in the collection of information with the client, another day we do the analysis, and then we make a presentation in half a day. Now a little more.
')
At the beginning we communicate with the audit client. to clearly define the purpose of the audit, the reasons for the audit, the expectations of the audit and the willingness to change. From this depends on what questions we ask and what recommendations to give. Then, along with the lead project (technical, managers, analyst leaders), we draw the value stream map (VSM). What it is? This is a description of how a business idea through development ultimately reaches the end user. It looks like this
VSM allows you to understand areas for improvement and unnecessary steps that do not add value and are a source of losses.
Then we collect developers, testers and analysts from this scheme in turn and give them 10 minutes to write about the problems that they experience during a particular product development step. Stickers help us with this as always. After 10 minutes, we work together on all issues, jointly fix and discuss them.
Since we carry out the audit either together or three, then we separate and find out the details on the technical and product part of the development.
From the point of view of technology, it is important for us to know the following things:
- technologies (programming language, frameworks, databases, IDE, VCS)
- architecture
- process of working on features
- process of working with VCS (feature branch, branch by abstraction, ...)
- Continuous Integration state
- state of unit-testing on a project (are tests written, who writes, what experience, ...)
- availability of joint code ownership practices (pair programming, code review, ...)
From the grocery point of view, the following aspects are important to us:
- who and how to research the market and users
- how is product vision development going
- is there a notion MVP - minimal viable product
- How is it determined what functionality is really needed
- who is working on the requirements and how
- if there are metrics, one or another functional is successful
Usually the first day ends there and we take a timeout.
The next half of the day we continue to communicate with the team.
For developers, testers, and system administrators, we take the following two exercises in turn.
First is the Speed ​​Boat. The bottom line is that we draw a ship on a large sheet. This ship is the development process, and the problems that exist are the reefs for which the ship's anchor clings. The task is to write near the anchor, for which it clings. The degree of importance of the problem can be reflected in the depth of the anchor, the deeper - the more serious the problem. Oddly enough, these problems almost do not overlap with the fact that before that people spoke at VSM. But besides the problems, we also fix what is positive or would like it to be. In the case of a ship, it is the wind that blows into the sail.
After we’ve finished with the ship, together we are completing the second task - we build the project’s infrastructure: servers, storage, services, and so on. What is most interesting in this case, each next group, says "And how much they did not draw ..." or "Yes, they all incorrectly displayed!"
Also, in the Speed ​​Boat format, we communicate with the recruiters of the company. This is necessary for understanding the mood in the company, motivating people and so on. Once, it was communication with recruiters that helped in understanding the problem in detail.
After that, it is time to process the results. I will not reveal all the secrets, I will say only about two points.
First, we sort out all the problems in the following groups:
- Atmosphere and culture in the company
- Work with products
- Processes
- People
This partition allows us to understand the current level of maturity of the company according to our internal model:
- Requirements Management
- Quality
- Communications
- Development Management
- Motivation
- Engineering culture
- Personnel Management
After all this, we are preparing a proposal and slides. It is also worth noting here that we are preparing the presentation on large sheets of flipcharts using infographics and Visual Notetaking techniques. The feature of the sheets is a sticky edge, which turns them into giant stickers that remain after the presentation with the client. The presentation itself lasts about 3-4 hours. During it, we tell what we saw in two days, what we felt and what problems we fixed. In 99% of the entire audience agrees that such problems exist and they must be solved. Thus, an additional objective of the audit is achieved - to open people's eyes to the fact that someone besides them has a problem that can be taken together and solved by joint efforts.
This is how the three days of our audit are so intense and energetic, and everyone is happy with each other.
Source: https://habr.com/ru/post/180417/
All Articles