Operational Planning at Redmine
In the last article, I talked about how we set up the task life cycle for programmers at Redmine , now I want to talk about how we plan tasks at Redmine by the month (I’ll probably write about strategic planning in a separate article).
How do we plan
I’ll briefly talk about the operational planning process that works in our IT department.
Any employee of the company can write a request to the IT department for the development of some function in software or for another job (some applications require the approval of the head, others do not).
The application falls into those. support, which then lowers the application to the head of the department responsible for the implementation of this type of work.
The head of the direction, if he sees the need for this work, creates a task on the basis of the application and puts it in the plan for a specific month or in the queue (for later), notifying the customer who wrote the application about the shift of the deadlines.
Also, the head of the department sets tasks on the basis of his own vision, filling the next month’s plan with tasks, and distributes the tasks among the performers.
Something similar to Scrum sprint planning happens on the last Friday of the month (I somehow got sick with this methodology). The fundamental difference is that we have many customers present at the approval of the plan, and in Scrum from the customer’s side only the Product owner.
The head of the department and key customers come to the planning meeting (key customers are determined by order and are tied to the development direction), other customers who are interested in their tasks falling into the discussed plan may also come to the coordination of plans.
At this bargain, it is decided which tasks need to be thrown out of the plan drawn up by the leader and which should be included. The leader adjusts the plan and approves its version, agreed earlier at the meeting.
In the process of executing the plan, urgent applications can fly to the manager, and he can include them in the current plan based on his own vision.
We came to this process empirically, not immediately, and he has been living in the company for quite some time.
What have we done at Redmine
Standard Redmine allows you to combine tasks in the version, set deadlines and estimated hours. Perhaps the standard planning possibilities end there.
Someone may have enough of these opportunities, but it was not enough for us: there is no way to allocate resources, there is no way to control the backlogs, and there is still a lot of things, as it turned out during the implementation process.
There are a number of plugins available for deeper planning. Most of them are tailored for flexible development methodologies (Scrum, Kanban, etc.). But agile methodologies are not always suitable for a large company. Moreover, we have different programming departments with our own specifics, there are a lot of customers and there are no people who want to become Product owners, it was necessary to implement operational planning not in the programming departments.
We used the Advanced roadmap plugin around the block, and then we started making our own and that's what we did.
The first thing we did was introduce the concept of a performer (I talked a bit about this in a previous article ). The contractor is the one to whom the task is assigned once, and he is responsible for its final execution. The “Assigned” field was immediately renamed to “On whom”, during the execution of the task this field can change several times from the author to the customer.
For the project managers, they made an “Assign” button, which puts the task in the plan.
We introduced the concept of the plan itself, which may include several versions. Those. in October, for example, there may be two versions of the program itself. At the same time, in non-programmer departments, for transparency of working with the plan, they automatically linked the task to the plan by the completion date. And also, they made automatic creation of a plan and version if they did not exist. This has made planning more transparent for professionals far from IT.
According to the contractor and version (with the ability to switch in the interface) they began to form a plan. The latter, by the way, was renamed to stage. It was more understandable to users.
Pretty quickly a prioritization problem arose. The leaders had a need to show the performer in what order it is necessary to complete the tasks.
Redmine's standard text priorities weren’t very suitable, because they didn’t set a clear sequence of tasks.
Redmine also has the ability to link tasks in sequential chains. This also did not fit, as changing priorities turns into a non-trivial task. The action was sometimes blocked, and a hidden automatic change of dates in the entire chain was not always in place.
We recorded a numerical priority in a custom field, and implemented a priority change in the plan using ordinary drag and drop, both in the whole plan and for a specific artist. Now, if the situation has changed, then at any time you can rebuild the execution order. Line priorities, however, were left to visually reflect the importance of tasks.
In order to efficiently distribute tasks among performers, we screwed up several counters that showed how full the plan was for the employee, how long the performer completed it, etc.
If an employee participated in several projects, then calculating his workload according to the project plan was problematic, so we made a general plan for performers, which showed a general picture of performers by month. Tasks from all projects were collected in it, and it gave a more complete picture of the workload of performers.
At first, the plan was agreed only in words at the meeting once a month. Over time, customers began to wonder why the agreed tasks flew out of the plan and we screwed up the plan approval function in Redmine.
Now, the manager simply clicks the “Agree on a plan” link. After that, a cast of the plan is made and you can watch all the changes that occur with it: how the watch’s score changes, which tasks fly out of the plan, and which appear in it, and even how the task headings change. This gives amazing flexibility to the project manager, and control over the plan remains high.
Where puzzles hang and why
We have both large and small software development departments. Large departments have a full range of positions related to software development: analysts, programmers, testers, and supervisor. It so happened that analysts wrote requirements “in the box”, and programmers did not have time to write code. It’s not very good, in order to control such situations, we came up with an analog of the Scrum-board (my manager calls it a WIP (Work in progress) -board). Each column of this board can be flexibly configured based on standard Redmine task requests. That is, we can say that the tasks of this request fall into this column, and the requests of this into another.
The whiteboard helps to visualize at what stage of the life cycle tasks accumulate.
Sometimes tasks are accumulated not in positions, but in specific people or in specific statuses. Therefore, we made detailed statistics on how much time the tasks spent in certain statuses and on certain people. These statistics are conveniently used to analyze the life cycle of tasks, for example, or to assess the workload of certain people. Statistics are available both within the entire plan and within the framework of a specific task.
Operational planning has given many additional benefits:
- Work and responsibility ceased to be lost.
- The performers got a focus on achieving the plan.
- Control over the work of the unit has grown.
- There was some kind of mutual understanding between internal customers and programmers. Customers began to see that the IT department is not only an expense item. It became easier for the performers to explain their workload.
It would be interesting to know what tools for operational planning are used by the Habra community, and what are their advantages?