Jianbin CAI – Manager of Asian IT Delivery Team of International Logistics Company
Introduction:
Agile is a popular term, but in Agile, including many teams that are just starting to use Scrum, how quality can be an aid to Agile rather than a drag is my main focus.
As for the definition of mass, I came across an article not long ago, in which there was a diagram describing five dimensions of mass, but I made some fine adjustments and changed it to four. Now let’s discuss each of the four dimensions of mass that I define.
1. Quality based on value, delivering impacts rather than delivering products
There’s a very famous guy in IT called Weinberg the consultant, and he mentioned the definition of quality called quality is value to somebody, what does value mean?
Ford asked the customer what he wanted. He said he wanted a faster horse, but Ford gave the customer the car. Horses and cars are products offered to customers. What is the value? The customer may have the demand to fly from each city every day, he hopes to have the faster horse assistance, this is the meaning of value. Customer requirements are often solutions, and they rarely tell you what the purpose is behind the thing. So behind the User Story is value.
At work, I don’t think we’re delivering products. I think we’re delivering impact, which is delivering impact on users. You asked me to develop a better horse, and I’m going to ask what the horse will do and what impact it will have on you, because I deliver impact not product.
Impact Mapping uses Why Who How What to get some ideas: What do we make products for? Who does it affect?
– If a cafe owner wants to earn 100 million yuan, who can help him achieve this goal?
– If the customer can help him achieve this goal, how?
For example, after buying coffee, a customer (who) thinks it is good and then recommends it to other friends (how). Therefore, by recommending coffee shops to friends, a customer can earn a small goal of 100 million (why). However, it should be noted that the number of “who” can be many.
And then you have the “What”
In order to encourage customers to recommend their friends, I may develop a functional system of “recommend earning points for coffee” (what). The development of the Story is not the Story itself, and the product itself is not our direct goal. Our goal is actually to influence the behavior of “customers recommend friends”. This influence, and ultimately achieve the business goal, is why.
We cooperated with the product, and they did what for us. They would say that you gave me a function of redeemable points for coffee. In fact, it is more important to discuss what kind of value these functions will bring. But the frame doesn’t really ask why, who, etc., it tells us what really needs to be delivered, not the actual product. Therefore, it is a fundamental purpose of the framework to propose a better what that may conform to the target behind.
2. Use feedback based on the quality of the product
For example, if we want to develop a faster horse, or a car, that’s the product itself, and there’s still a quality element to it, how to make things right.
Cynefin model:
Simple: Your solution is simple, you just have some best practices to apply, and if your company, your r&d is in this quadrant, congratulations, it’s very comfortable
Complicated: A complicated scenario. In this scenario, you may have multiple solutions, there may be no best practices, or there may be multiple practices, and you may need several experts to help you solve the problem
Complex: There is no way to simply find several experts to study and come to a conclusion. There are various dimensions to deal with, which may be quality problems, limited budget, unclear product direction, unclear requirements, and lack of cooperation between the product and the architect. But there is a goal that needs to be promoted.
Chaotic: Chaos. In case of such a chaotic situation, the challenge is really very big and may be beyond the reach of ordinary managers. CXO needs to sit together and give direction.
Disorder: Managers break problem solving into subdomains and scenarios to attack one by one.
Product development is mostly in the second and third quadrants, where you do things first and then you give feedback. Feedback has a principle: the earlier you give feedback, the cheaper it is.
For example
One of the biggest problems in product development is the gap between your technical team and your product manager. This gap is common, but in my own work scene this gap is not common, I’ve always been a person in the field of technology, but I or requirements on the product with product managers are always work together, to cross the feedback with real-time feedback, and don’t wait for the product manager has been designed for two months, then give us after developing the online, then put forward the demand is wrong, It’s more passive.
If feedback can be delivered in real time, here’s how it works. At the beginning of new product development, technical staff and product manager and I would draw the conceptual model together, because a team has many roles, including architect, development, US, and even outsourcing personnel, how to ensure the same understanding of different roles, and finally understand how to do their own work. How do you make sure that the campaign is based on a unified understanding? Without consensus, it’s easy to have gaps. Drawing a conceptual model is just for practical examples, it can be very simple, what business objects do we have, what are the relationships between them, drawing these things down, and everyone doing their work based on a common understanding, the gap will be less.
3. Based on the quality of the output, the definition is completed and the end is the beginning
I am from R&D background, what is the r&d quality output? This is the output, the first output is code, especially in the software industry, code accounts for 80% of the output, how to write code right, is the third dimension.
Code quality has an approach called definition completion;
For example, a lot of programmers you ask him this Story is done, what is the answer he gives you? The measurement of bugs is zero, and the programmer gives it to QA, who tells the developer if there are any bugs. The next step in your QA process is my client, I should tell you if there are bugs or how many bugs there are, not the other way around.
Quality of demand is also an important output;
You want to make sure that the requirements that your product manager is doing are consistent, are itemized, are prioritized, and that you are doing the most important things. You have three teams, each working according to the priorities, but whether the three teams have the same priorities, many teams do not.
There are some requirements that users will not be happy if you do not do them, but you will not be very happy if you do them. Just like our practice, it will be miserable if you do not do them when the project is large, but the project may not be successful.
At work, when you ask a programmer whether it is done or not, many programmers will tell you that it is 90% done, or it is done but there is no test, or there are a few bugs, or it needs to be refactored. This mentality is not good, but there is no feedback.
We call it beginning with end, there are only two states of user stories, only finished and not finished, no but, not finished and you have to finish it. The programmer will say this is 90% done, then move on to the next story, and none of it will work. What we advocate is to do one thing completely before moving on to the next.
4. Process quality, disassembly
There is a saying that if you bake bread the same way, you will get the same bread.
Process quality is the quality of writing code, and the idea is to break it down, break it down into something small, break it down into something deliverable, and actually writing code needs to be broken down.
So for example, a lot of programmers write code, and at the end of the day the code hasn’t compiled yet, so the way we write code is like this, a lot of programmers write code a little bit here and a little bit here, what does that mean? Without transparency, he doesn’t know which one to write, and this process is impossible for good code quality.
conclusion
We’ve talked about the four dimensions of quality, value, and cost, but many teams don’t have control over the value part, and some do. We are a technical leader and the products are out of our control. Where do you think customization rights are? Where is the right of influence? What you can control is your costs, and what you can’t control is what you can’t provide.
Who is responsible for the quality? If development problems between engineering and QA, finally developed the function of hard, users complain harder to use, is the value and quality problems of division of labor is more and more fine, now in many team focused on one layer, such as programmers care about writing code, don’t care about value and product, product managers are only concerned with value, don’t care about the technical implementation and the gap will affect the whole quality.
Worktile’s website: Worktile.com
Contents: Worktile
This article was first published on Worktile’s official blog.