"Bloodsucker bosses" out of context or why they always fail
In my opinion, the article “Bloodsucking Bosses in the Context of ...” did not disclose the reason for the disintegration of self-managed teams, but the reason was precisely the slow speed at which product requirements spread, and the lack of understanding that the manager is always part of the team.
By changing the approach to planning the work of the design department in developing a new product, it is possible to increase the speed at which information spreads, which is much more important for a project than just having information.
Classic scheme
In the classical scheme, the work planning and development process has clear time boundaries. Usually the planning process is carried out before development. At the end of planning for each month, a “network work schedule” appears on which the product development process begins by the design and engineering department. There are not many types of network graphs - these are mainly PERT and GANTT. Deadlines in the network are usually declarative and not supported by anything, which creates some imaginary space when working in the development process by the design and engineering department. In fact, the deadlines in the network schedule are agreed with the customer and the contractor is forced to comply with them, otherwise the failure of the key development deadlines may threaten the closure of the project as a whole. Nobody asks the developers in the classical scheme and the project manager simply drops the deadlines for each work to the developers.
From the outside, it looks like the project manager gives everyone a kind of fishing rod (tool) and says: “Catch while the crucian. At the end of the month I’ll come and check how much I’ve got. Need to catch 2 tons. ” During the month, the project manager holds meetings at which someone reports to him, how many tons and what type of fish he caught. At the end of the month, a new “updated” network work schedule is launched by the project manager, according to which the customer wants to catch not carp, but for example “zucchini” . The “wise project manager” has a chance to get a bonus for buying a new plasma or a new modern SUV. If he is lucky and there will be at least one who catches a “fish-zucchini”, then he will pay a premium to himself and a successful angler, and the others will impose a fine.
This mode of operation forces the project manager to take on some of the development tasks for themselves, and the developers of such a project are constantly delayed at work, and sometimes they have to go on weekends to have time to develop new interfaces for users to interact with the product. All this, as I mentioned above, is aggravated by the fact that the requirements for the final product can change, and then the network schedule is adjusted, and the adjustment is made in such a way as not to hurt the key deadlines in the project.
In such a scheme, all work depends on the human factor, which plays a key role. The human factor can be minimized by introducing automated planning and development systems, which many people actually do when implementing CAD systems in their enterprises., CAM , CAE , PDM , ERP , CRM , PLM , etc.
However, the basis in the form of a classical scheme, when planning and development have clear time boundaries remains unchanged. As a result, developers have to keep up to date numerous editions of the software product and documentation in each automated system, as well as constantly maintain system integration, which is problematic in today's competitive IT market conditions. The customer ultimately needs only one thing - this is a finished product or a streamlined production. In the classical scheme, the list of documentation developed by the contractor will always be redundant, since neither the customer nor the contractor has complete confidence that the goal will be achieved, and therefore it is necessary to document the process as much as possible in order to identify “to shift responsibility” for the deadline.
How, then, to make the customer not change the requirements too often, and the performer fulfilled all the requirements of the customer on time?
In the classical scheme, the planning process is handled by an experienced expert in project planning, who, based on his experience, determines the list of tasks and their deadlines. I believe that all this could not have been done by an experienced expert, because the timing of the tasks, as well as the list of tasks necessary for the implementation can be determined by the team itself. For this, the expert from the customer needs to describe the product in as much detail as possible in his TK and the deadline for which the product is needed, and that’s all! The team, under the leadership of the project manager, can carry out the work planning itself, reveal the pitfalls, decompose the tasks, in short all the work that the most experienced expert performs.
The “problem” is that in this case, each member of the team knows the final goal, it is transparent and at each moment in time we know how far the team is from it. “A wise project manager” will not be able to include his megacel in this goal: “buying a modern SUV.” In order for him to successfully achieve his 100% mega-goals, he needs to separate the planning and development processes and issue task lists in batch as the “problems” arise. In this case, the task of the project manager is to maximally divert the attention of the team from the final goal of the project, and focus their attention on solving the specific work of the network on time. In other words: “fill up the team with routine work”.
A fundamentally different scheme of work is a scheme of work using flexible development methodologies, where the main principle is:
frequent uninterrupted supply of a product of value to the customer.
This is achieved primarily by the transparency of the planning process, when each team member knows the final goal and participates in the formation of a task pool for the next 1-4 weeks, after which the customer sees the first version of the product with new functionality. Obligation of the project manager to obtain approval from the customer or simply notify him of the product version with new functionality that will be ready after the iteration is completed. All additional requirements coming from the customer should be taken into account when planning a task pool team in the following iterations.
In order not to stray from the goal of reaching the final goal, the team gathers every day to hold 15-minute rallies, at which each team member answers three questions:
- What was done from the previous rally?
- What will be done for the next rally?
- What are the problems?
In the case when planning is carried out separately from the development, the answer to the second question is given by the project manager, as well as the answer to the third.
At the end of each iteration (sprint), the team demonstrates the product with a new functionality to the customer. After each demonstration, the team meets separately from the customer for a retrospective. Methods of conducting retrospectives mass, I would like to note a retrospective in the “PLUS / DELTA” style, in which each team member gives 10 positive points (PLUS) and ten points that made the team deviate (DELTA) from achieving the intended goal.
In the scheme of work using flexible development methods, automated systems play a key role, allowing you to get a product with the most advanced new functionality at the end of the iteration. After each iteration, the product can be sent for technological development in ERP or CRM systems in order to further launch the production of a prototype product for testing under conditions as close as possible to real ones. Thus, after each iteration, a software product is updated and new functional requirements are increased. The clients themselves are already at the stage of technological development or a pilot project through feedback in the CRM-system will make demands that you would not even think about. The main thing is to bring these requirements to the developers in time, and not to hide them in the halls of the mind, as the “Wise Project Managers” sometimes do.
Draw conclusions
Attempts to build the development process according to the classical scheme using flexible methodologies usually fail, and seeing so many project managers to please their “mega-targets” or simply automatically following the fundamental principle of “divide and conquer”, they refuse to apply modern knowledge of project management in practice.