December 19, 2011 at 18:00Overcoming Traditional Agile Implementation Challenges
I read the post " Problems in implementing Agile " by the adnotum habuser , I wanted to offer several solutions to the problems described. Since the solutions are quite universal, I decided to design them as a separate post.
Most of the problems described appear because Scrum is a flexible framework and not a full-fledged methodology. This is its disadvantage and advantage at the same time. “Vanilla” or “Kosher” Scrum is described briefly in the official authority guidefrom Sutherland and Schwabber. “Kosher” Scrum is when you do everything according to the rules, but it turns out not very tasty, and the process itself does not give pleasure. Such a spherical Scrum will work only in an ideal vacuum, but it can and should be adapted, which is why this framework itself is good.
The product backlog is actually the main artifact in Scrum, but it really appears in a magical way: “divide the requirements into small user stories, arrange them according to priority” and everyone will be happy. In reality, we have two options: either according to the project it is necessary to carry out a full collection of requirements, or there is a large and complicated document of TK (TK = HZ).
In both cases, it is necessary to analyze the requirements, for which it is very convenient to use the following practices:
The practice of person analysis came to product management from User Experience practices. It consists in describing the users of the created product as a real character with specific values and goals.
A story mapping is a very convenient way to visualize the functionality to check the completeness and validation of requirements. Visualization takes place on the board and begins with the high-level activities of the identified people.
Activities are divided into tasks, which in turn are decomposed into subtasks.
The top layer of subtasks is the simplest possible implementation of the functionality and is usually included in the first release. The subtasks below are the implementation of additional features. The lower we go on subtasks, the less important they are.
After (and during) the story mapping you can already do a full backlog and plan releases. More details can be seen at filippov in his presentation .
The problem is that each developer knows his own piece of code and usually there is a technid who has this knowledge as deep as possible. Typically, the solution is to increase cross-functionality between individual team members.
The simplest tools here can be the following engineering practices that will help disseminate knowledge among team members:
Again, it’s worth approaching this issue head on: the cross-functionality of the team, and not its individual members, is important to us, first of all.
Developers tend to deviate from the required functionality to provide a higher quality system from their point of view. Moreover, the quality criteria of developers may not coincide with those on the part of users or the customer.
As far as I understand the description of the problem, it is necessary to make criteria of completeness for user stories (definition of done), in which to write down (to write down, not specify), formal quality parameters: passing acceptance tests and unit tests, percentage coverage with tests, compliance with code standards, passing a formal code inspection / writing a code in pairs, etc.
The productivity of the developers is really different ... The worst thing is that it can differ not at times, but by orders of magnitude. Briefly commenting on this issue, we can offer the following options for solving the problems of organizing work and the motivation of stars (although I think this is not such a big problem):
Note: I do not pretend to be the ultimate truth.
Most of the problems described appear because Scrum is a flexible framework and not a full-fledged methodology. This is its disadvantage and advantage at the same time. “Vanilla” or “Kosher” Scrum is described briefly in the official authority guidefrom Sutherland and Schwabber. “Kosher” Scrum is when you do everything according to the rules, but it turns out not very tasty, and the process itself does not give pleasure. Such a spherical Scrum will work only in an ideal vacuum, but it can and should be adapted, which is why this framework itself is good.
Where does the backlog come from
The product backlog is actually the main artifact in Scrum, but it really appears in a magical way: “divide the requirements into small user stories, arrange them according to priority” and everyone will be happy. In reality, we have two options: either according to the project it is necessary to carry out a full collection of requirements, or there is a large and complicated document of TK (TK = HZ).
In both cases, it is necessary to analyze the requirements, for which it is very convenient to use the following practices:
- Analysis of persons ("Personas")
- Storimapping
The practice of person analysis came to product management from User Experience practices. It consists in describing the users of the created product as a real character with specific values and goals.
A story mapping is a very convenient way to visualize the functionality to check the completeness and validation of requirements. Visualization takes place on the board and begins with the high-level activities of the identified people.
Activities are divided into tasks, which in turn are decomposed into subtasks.
The top layer of subtasks is the simplest possible implementation of the functionality and is usually included in the first release. The subtasks below are the implementation of additional features. The lower we go on subtasks, the less important they are.
After (and during) the story mapping you can already do a full backlog and plan releases. More details can be seen at filippov in his presentation .
How to plan changes to legacy code
The problem is that each developer knows his own piece of code and usually there is a technid who has this knowledge as deep as possible. Typically, the solution is to increase cross-functionality between individual team members.
The simplest tools here can be the following engineering practices that will help disseminate knowledge among team members:
- Coding standards
- Code Sharing
- Pair programming / Formal code inspections
Again, it’s worth approaching this issue head on: the cross-functionality of the team, and not its individual members, is important to us, first of all.
What is good"
Developers tend to deviate from the required functionality to provide a higher quality system from their point of view. Moreover, the quality criteria of developers may not coincide with those on the part of users or the customer.
As far as I understand the description of the problem, it is necessary to make criteria of completeness for user stories (definition of done), in which to write down (to write down, not specify), formal quality parameters: passing acceptance tests and unit tests, percentage coverage with tests, compliance with code standards, passing a formal code inspection / writing a code in pairs, etc.
First among equals
The productivity of the developers is really different ... The worst thing is that it can differ not at times, but by orders of magnitude. Briefly commenting on this issue, we can offer the following options for solving the problems of organizing work and the motivation of stars (although I think this is not such a big problem):
- Career progression
- Training colleagues: from mentoring to speaking at internal events
- Conference attendance and speeches
- Ambitious tasks (by terms, by volume of work, by complexity, by flexibility)
Note: I do not pretend to be the ultimate truth.