How to form a team structure for business needs 3
Continue. post and design In this post, we will talk about product development. In my last post, I’ve talked a lot about the utility of a design approach, and the question is, why do we need product development when there are such great projects out there? But projects are good for starting new initiatives or conducting cross-team activities. But if we want to deliver value in a more planned and continuous manner, we come to the concept of a product. There is a specific target audience of the product
- There is an approximate understanding of what features, stories, JTBD (jobs to be done) We want to implement There is a desire to roll out these changes in small portions and test how they work. There is an understanding that the plan can change flexibly during movement. With such a set of expectations, it becomes clear that the project approach does not suit us. In the end, we come to product development processes, which I talked about in the report.Improving the flow of software developmentwhere I recommended reading a book.Making Work Visiblefrom Dominica DeGrandis, which I mean. wrote earlier. But in general, there are several approaches to how to organize work and plan the time of its implementation. It is important to remember the ironic law of Parkinson’s.
The work fills the time allotted to it. This law makes it clear why buffer planning is a problem, and it is so often planned in project management. But if you plan the work of tasks per team in push mode, you can face the fact that the requirements for teams and their performance are not balanced, which does not allow you to complete all tasks on time. Ultimately, we need a pull-mode system where people pull out a new task as the previous one is completed. One such system is Kanban. But it is important to understand what tasks fall into such a process - it is important not to agree to everything in a row, but to deliberately give the go-ahead only to the most important at a particular moment and do it visually. To do this, you need to organize a working flow system that performs the following tasks:
- Makes work visible. Limits the amount of unfinished work Evaluates the workflow and manages it Effectively prioritizes Make adjustments based on metrics and feedback
And the problem with time and its leakage is due to the following five factors: Too WIP is a story about unfinished work, bottleneck and Little's Law. Unknown Dependencies is about architectural problems and dependencies between systems and different teams. Unplanned work: Unplanned work steals time from planned work. This makes the system unpredictable, and the main thing for us is predictability and expectations. Conflicting priorities – if all tasks are priorities, then none of them can be called really important. Without clear priorities, people have to try to do too much at once, which automatically leads to an increase in WIP, which slows down the entire system. Neglected work - often such work manifests itself in the form of tech debt, which accumulated in the system when people only riveted features without work to improve the technical perfection of the system. In general, important but non-urgent work that is so loved to be postponed often sags... until it escalates into an emergency situation, when it becomes an unplanned job that cannot be abandoned.
As a result, I have always sought to build product cross-functional teams using Kanban approaches. These teams were stream-aligned teams from Team Topologies. (detailed 1, 2, 3). About how I built product development I told in the context of our web Tinkoff.ru in two long-standing reports.
- Report at Teamlead Conf 2018 forward scaling Tinkoff.ru from a management point of view
- Report on ArchDays 2019 forward evolution of the entire bundle front - back - a / b test systemwhere the focus is more on architectural changes
#Management #Leadership #Project #ProjectManagement #Software