1. terms of reference for Agile operations
The flexible software development manifesto focuses on achieving business value, discarding and reducing the importance of everything that does not bring it closer to business value. In this sense, traditional detailed terms of reference, signed by the customer and the contractor, is often the cause of losses.
I wrote about this in detail in the article 12 of the article about the problems with the terms of reference in the IT product.
The ToR, like any other legal document, imposes obligations on both sides to formally comply with all the paragraphs of the document. This gives side effects:
1. The customer, though striving for a business goal, is forced to accept the results of work on the formal TOR;
2. The contractor, who sees how to make the work more optimal, prefers to follow the ToR and not to get involved in the re-coordination of the plan, even if it turns out that the plan is not effective.
2. Metaphor for a planning tool
The software is abstract and easy to change. This property of software differs from the production of things in the real world. For example, after building a house no one would think to say, "Now let's move the 5th and 6th floors apart and insert a huge shark tank between them. This is not the case in the world of material production, but software development is the norm. That's why the approach to planning should be appropriate to the nature of the software.
In my opinion, the metaphor of a navigator in a car fits well:
1. The navigator knows where we are now and where we want to go.
2. If, on the way home, we decide to turn to the store, it will rebuild the original way to accommodate the changes.
3. If we change our mind about going home, we put a new point on it and immediately show us the new best way to the new goal.
4. If there was an accident on the road and the way is closed, the navigator rebuilds the route.
It would be good to have such navigators when working on IT products. Our planning would turn into a constant laying of optimal routes to business value with a quick reaction to changes in external factors, such as user feedback, actions of competitors, the desires of investors, etc.
3. Implementation of an adaptive work plan
In order to create a "navigator" for the IT product, I recommend to use suitable planning tools, to periodically return to the beginning of planning and revise plans, to stop fixing the amount of work for a long time in the future and to build communication around business goals.
3.1 Visual and "multidimensional" terms of reference
People work well with visual images, mind maps and schemes. Therefore, we do not write much "flat" text in our practice, but we actively use maps and images. Pictures and maps can be easily rebuilt unlike a 300-page document. In addition, these maps are quickly read and help people on the project to communicate effectively.
The interaction of all parts of the IT product, user experience and user scenarios are described in Customer Journey Map and User Story Map.
Once these three maps have been created, you need to cut off the most important business tasks for the next release and pave the shortest way to the goal. Here again, it helps that all the maps are visual, they help to cut off the parts and draw the paths.
3.2 Cycles and Revisions
Flexibility is created due to the cyclicality of the IT product development process and the ease of making changes to plans. As all plans are described in schemes and stickers, making changes to them is easy.
After each release, it is necessary to go back to the beginning and see if you have made a step in the right direction. For each cycle we learn something new about the market and about our capabilities, draw conclusions and go to a new circle.
Description of this process with an example of a project from the practice of our company in the article Five most important components of the process of successful projects release.
3.3 The scope of work is not a fixed value
To ensure flexibility in a classic project triangle, two things need to be changed: stop fixing the scope of work and start fixing the quality.
Fixing quality - because the direction of software development is constantly changing, the architecture and code should not be broken when making changes. The code should not be fragile. To improve the quality of the code they use Extreme programming practices and monitor the level of technical debt.
Floating scope of work - usually the time and price are important for the customer, these values remain fixed. But what exactly will we do in the specified term? We will do what will bring the customer as close as possible to the business goal, and this will be seen by the maps and schemes used in planning.
Developers are well aware that one and the same task can be done in an infinite number of ways. For example, if you print a beautiful indicator, it will take two days for the designer, maker and programmer to work, and if you show a number instead, it will be done five times faster. Therefore, we often "flex", i.e. do less, but do not worsen the achievement of the business goal.
To make the scope of work floating, we need to build a high level of trust between the contractor and the customer. How to do this in the article Customer satisfaction for programmers: Trust and transparency.
3.4 Business purpose orientation
Together, the customer and the contractor are guided by a business goal in paving the way without formal terms of reference:
With this approach, there is no formal list of works to be performed contrary to common sense and loss of efficiency.
4. I am an accountant, I see it this way
Our schemes and stickers on the wall, unfortunately, are not suitable for formal documentation and legal registration of works. Accountants and lawyers require terms and description of the scope of work. They do not oppose the "flexible" approach, they only try to comply with the laws and reporting rules adopted in the country. That's why usually in life the scheme of work looks like this:
In this case, the ToR remains, but is only a legal support to the project. It is often written in an abstract way to leave enough space for creativity and risk response. Even more often the list of works is filled already after realisation of an IT product and is signed by date of the beginning of the project. Thus all norms of the law are observed and TK does not spoil a course of works by the inflexibility.
5. We improve the quality of work
The main theses:
1. Work planning is a cyclical and continuous process, so you need to use flexible tools;
2. Do not replace live communication with TORs. If the ToR starts to take the lead role, you should be wary and check how the communication in the project is organized between all participants;
3. Write TORs when necessary. Make it as useful as possible;
4. Control of the development process is achieved by visualizing the current status of the project and understanding the next steps.
In the following articles we will answer these questions:
When do you need to stop writing the Terms of Reference and start making a project? There is a scheme of how to balance between overly detailed and thus expensive TORs and too abstract ones which leads to risks and errors.
There are 5 reasons to write the ToRs, which list the reasons why the entire work plan should be described in detail before the start of the project.
12 problems when working on the terms of reference in the IT product. Problems which transform a writing of the ToR into losses for business are described.
Frank communication with the customer, where the dispute about how much detail the ToR should be.
Terms of reference as a knowledge base about the project, which describes that writing the ToR - is a loss to business.
How and what terms of reference to write when working on Agile, where it is described how to use appropriate planning tools, stop fixing the amount of work for a long time in the future and build communication around business goals.