How to conduct a distributed paperless quarterly planning and not to screw up?
Given: A company that uses the Scaled Agile framework (SAFe) to scale Agile development across the organization; 10 development teams combined into one big team (Agile Release Train, according to SAFe terminology), delivering a common product; The need for a two-day quarterly planning (PI Planning) to determine the work plan of IT teams for the next 3 months *; three development offices, the distance between the most remote ones is more than 6 thousand kilometers with a corresponding difference of 5 hours of working time; previous planning experience that involved the physical presence of key colleagues in the same room and the use of analogue boards / whiteboards / markers / sticky papers.
* The heavyweight construct “The work plan of the IT teams for the next 3 months” threatens to seriously increase the amount of text, so in the future I plan to write instead simply - “commitment”. Accordingly, to draw up and adopt a work plan - “commit”.
1) Fatigue from analog methods of work. While the space ships plow open spaces, and Ilon Mask digs the tunnels, we, the IT people, persistently write with stickies on sticky pieces of paper and sculpt them on the boards - there is some kind of dissonance in this. That was what our commitment looked like a while ago:
Yes, this is a piece of paper about 2x5 meters in size, and every piece of paper should have been turned into a task in the Jir after planning ...
')
2) Fatigue of nomadic colleagues. Despite the fact that our head office is located in a rather friendly, warm country, to my surprise last year I found out that they are not at all happy about such a nomadic life, and my arguments are in the style of “oh well, you buy at sea in the sun you will get warm ”, which I had the imprudence to express, were not received very warmly - not everyone is ready for frequent business trips, their households do not always welcome this, someone has an organism that does not respond to frequent flights very well.
3) Connecting a larger number of IT colleagues to the planning process. As is clear from the previous paragraph, we could not afford to send the entire office for planning, so we sent only the Elected, thereby excluding the rest from the process, which did not add any advantages to the general moral.
4) Optimization of financial costs. Yes, this is a sensitive moment - there are quite a lot of key people, and carrying them back and forth four times a year by airplanes is an expensive matter.
And everything begins much earlier - in order to work productively on the commitit during the planning, it is necessary that there be commit to that. To ensure this, I have to “load” business owners with work on proposed initiatives (or, in SAFe terminology, Epicame, but I will use my usual term) as early as possible. Ideally, this process should be completely divorced from the cyclical nature of quarterly planning and go its own way. We took SAFe portfolio Kanban as a basis:
We have a separate JIRA project with three types of tasks: epic, business initiatives and architectural initiatives; as well as the corresponding Kanban board. The algorithm for the business owner of the initiative is simple: it adds a task to this project, and it defaults to Baclog - this is the first status of our kanban - Funnel:
There are stored initiatives that are not yet ready for review. The business owner is working on the content of the initiative until he feels ready for the next step. The minimum required at this stage is the filled fields of Problem Statement, Desired Outcome and Measure of Success, as well as a slightly more detailed, but simple and clear presentation. At this stage, it is important to get away from the mention of technical solutions and focus on business parameters. When all data is collected, the owner moves the task to the next status — Reviewing.
We conduct reviews on a weekly basis, both for business initiatives and for architectural ones. Ideally, this is a five-minute presentation with subsequent answers to questions. The result of the review is the decision about the future fate of the initiative. She can:
At this stage, we - hurray! - we can attract employees from IT: analysts, architects, leads, anyone. By “we,” I mean myself as a Release Train Engineer, but ideally business owners who have already gained some experience and autonomy necessary to attract the right teams and independently launch the analytics process. I am writing about the ideal case, because the level of self-organization of our colleagues is floating, and in some cases they ask for help in the form of a specially appointed facilitator, but I try to step back from this practice.
The purpose of this stage is preliminary analytics, or, as we call it, pre-discovery. At the output, we should get the minimum that will allow us to commit: proposed solutions, risks and dependencies, non-functional and infrastructure requirements, user maps (user maps), architectural schemes. In addition, we ask the teams to give a preliminary assessment in story points (story points) at the feature level - this will allow us to determine priorities at the end of the quarter.
For each initiative, a personal Kanban board is created in which, as they are created, features and storyboards can be seen, with a primary link to a specific iteration, which is ensured by a separate workflow in the form of future iterations. In boards svanely are configured on development teams. Since our JIRA-ecosystem is rather complicated, during pre-discovery and discovery we create tasks in separate projects in order not to litter the backlog of commands:
Also at the stage of analytics, architects are involved in this process or, as is customary in our country lately, their trusted people are “EA Ambassadors”. Their task is to convey to the participants of the process the vision of the architectural department, to help find the best solution, and finally to coordinate this solution with the chief architect of the company (Head of Enterprise Architecture).
When teams believe that the initiative is sufficiently developed and ready for the next step, they move it to the next status - Portfolio Backlog.
At this stage, an important step is to conduct a WSJF prioritization ( Weighted Shortest Job First ). To do this, we have a big meeting 3 weeks before the planning, which, unfortunately, takes many hours so far, and during this meeting with the help of Fibonacci poker, the members of the management board evaluate the Business Value (time value) Time Criticality), potential risk reduction (Risk Reduction) and Opportunity Implementation (Opportunity Enablement):
To be able to track the history of initiatives, for each of them I add a label (label) in jire with quarter data: 2018Q4, 2019Q1, etc.
Looking ahead, I will describe the following possible statuses. After the commitment of the commitment, initiatives successfully taken into work are moved to the Implementing status, while those “not affected” receive Parked status and have the opportunity to be considered for the next quarters. Delivered initiatives move to Done .
As a result, we have about the following image on the Kanban board:
Of course, we are not even in the middle of the road yet, but at the moment I can already note that thanks to the use of Kanban at the Portfolio-Backlog level
Somewhere a month before planning comes the hot time of preparation. Too much needs to be taken into account, and in order not to forget anything, you have to create a multipage “logistic” Google table. I will try to describe the most important tabs from this table and the activities around them.
Feedback. A few days after each planning we conduct a retrospective, and in order to correct the course, it is important not to forget what conclusions we came to and how we need to adjust the course. This is an important part in terms of continuous process improvement.
Technical training. With the transition to remote planning, specific requests have arisen, such as the quality of Internet connection (prioritization and optimization of routes for JIRA and Confluence) and television and audio presence (we use the Logitec Group kits, Jabbra microphones and personal headsets in various combinations, webcams, Zoom software for video conferencing).
Facilitators. Here is a list of employees responsible for facilitation in each of the working groups, indicating their location and a link to the permanent Zoom-channel of the working group.
Lecture hall. Accordingly, the complete list of all invitees.
Check list. Full list of important tasks with deadlines and responsible. For greater immersion, I will cite several examples of the most characteristic and important tasks that are repeated for each planning: training of facilitators (a training manual is prepared for the facilitators with all the necessary steps from organizing a working team, timing the meetings on researching technical options and decomposing the initiative into a list of features) ; update of working groups location plans for each office; control of the speed update for all development teams; ordering meals; creating reports from previous quarters; printouts of lists of initiatives (to be at hand) and schedules.
After all the preparatory running around, this moment finally comes - the start of quarterly planning. In two days we must have time to disassemble all initiatives, make sure that the information is sufficient and commit. After several short but incendiary speeches, the working groups disperse in places and get down to business. At the moment, the number of groups is distributed among the three offices according to the 4x4x2 formula, and remote users are connected to the required table via a dedicated Zoom channel.
Upon completion of the discovery of each of the initiatives, the facilitator, making sure that all the necessary data - such as acceptance criteria, technical solution description, risks, dependencies, the need for a new infrastructure - is available, notes the initiative of the IT Session Finished checkbox for transparency of progress and the working group may move on to the next.
After a dozen of plans, the feeling of constant nervous tension and temporary time pressure, which was with us from the very beginning, has significantly resolved, and now the atmosphere is more like calm work. In the second half of the first and second day, there comes a time for a slow commitment according to priorities. To perform a commitment, I have several separate structures. The first one is a structure containing a list of features and sites scheduled for the commitment:
Unfortunately, this structure contains remnants of material that did not fit into the commitment of the current quarter, so the sample is unrepresentative. In any case, in the search, I can select the initiative of interest to me in order of priority by number, which in the discovery process is put in a separate field for each feature and story, change the status of the necessary tasks from Planned to Committed and place it at the desired iteration, thereby committing itself:
As a result, the task will disappear from this structure and appear in a new, reflecting growing commitment:
As you can see in the screenshot, in this structure, the stories fall into the folder of the development team to which they belong and are grouped by iteration. Here, I see the common velocities of the command in the folder name, as well as in the Commitment column, using the formula, the overcomment is automatically determined for each group and signals to us in red.
Of course, if the first and highest priority initiatives go into a committment without problems, soon, with the appearance of the first teams that have filled their backlog to failure, problems and some initiatives begin not without controversy, but have to be postponed.
At the end of this simple process, the teams on the company's flag solemnly swear to deliver the commitment (joke) and run up to their homes (also a joke - everyone runs up to the bars).
While everyone is drinking vodka, RTE is working on creating commitments in the form in which it can be distributed to the backlog of development teams and monitored throughout the quarter. For this, I use the 'Bulk Clone Professional for Jira' plugin - it adds an item that provides collective cloning to the Bulk Change menu, and has such necessary features for me as link cloning, updating links between newly created clones, updating epic links, adding prefix header and automatic label addition:
I add status as a prefix, because at the planning stage the statuses reflect the planned iteration of completion, and as a result I see right away in the title when we are planning to finish the feature or story.
At first, I clone absolutely all tasks into a separate Global Backlog project, since we keep epics in it, and I need to have actual epic - story connections in newly cloned tasks. And already as a second step, I make requests for each development team separately and move the story into the final projects of the teams.
As a result, I create a structure that reflects the current commitment and consists of final tasks, which I then use for monitoring:
In general, the advantages that resulted from this approach are the following:
Friends, I, of course, understand that the description is rather superficial, and a lot of things could be revealed in more detail - monitoring the distribution of capital between business and architectural initiatives and operational tasks, calculating formulas in structures, managing risks and much more. But I still do not understand whether this topic is interesting to the audience, and if so, what exactly. If I see interest, I will be ready to reveal the necessary topics.
And one more thing - it’s hard to believe that this is possible, but by all means I would like to avoid sracha around the edjal, frameworks, effective and “effective” managers. Please remember that I described the whole process in the hope of getting interested by the people who are close to it, with its technical implementation, and I look forward to the relevant discussions.
See you in the comments!
* The heavyweight construct “The work plan of the IT teams for the next 3 months” threatens to seriously increase the amount of text, so in the future I plan to write instead simply - “commitment”. Accordingly, to draw up and adopt a work plan - “commit”.
Why did it take?
1) Fatigue from analog methods of work. While the space ships plow open spaces, and Ilon Mask digs the tunnels, we, the IT people, persistently write with stickies on sticky pieces of paper and sculpt them on the boards - there is some kind of dissonance in this. That was what our commitment looked like a while ago:
Yes, this is a piece of paper about 2x5 meters in size, and every piece of paper should have been turned into a task in the Jir after planning ...
')
2) Fatigue of nomadic colleagues. Despite the fact that our head office is located in a rather friendly, warm country, to my surprise last year I found out that they are not at all happy about such a nomadic life, and my arguments are in the style of “oh well, you buy at sea in the sun you will get warm ”, which I had the imprudence to express, were not received very warmly - not everyone is ready for frequent business trips, their households do not always welcome this, someone has an organism that does not respond to frequent flights very well.
3) Connecting a larger number of IT colleagues to the planning process. As is clear from the previous paragraph, we could not afford to send the entire office for planning, so we sent only the Elected, thereby excluding the rest from the process, which did not add any advantages to the general moral.
4) Optimization of financial costs. Yes, this is a sensitive moment - there are quite a lot of key people, and carrying them back and forth four times a year by airplanes is an expensive matter.
Part Zero, or Working with Portfolio Backlog
And everything begins much earlier - in order to work productively on the commitit during the planning, it is necessary that there be commit to that. To ensure this, I have to “load” business owners with work on proposed initiatives (or, in SAFe terminology, Epicame, but I will use my usual term) as early as possible. Ideally, this process should be completely divorced from the cyclical nature of quarterly planning and go its own way. We took SAFe portfolio Kanban as a basis:
We have a separate JIRA project with three types of tasks: epic, business initiatives and architectural initiatives; as well as the corresponding Kanban board. The algorithm for the business owner of the initiative is simple: it adds a task to this project, and it defaults to Baclog - this is the first status of our kanban - Funnel:
There are stored initiatives that are not yet ready for review. The business owner is working on the content of the initiative until he feels ready for the next step. The minimum required at this stage is the filled fields of Problem Statement, Desired Outcome and Measure of Success, as well as a slightly more detailed, but simple and clear presentation. At this stage, it is important to get away from the mention of technical solutions and focus on business parameters. When all data is collected, the owner moves the task to the next status — Reviewing.
We conduct reviews on a weekly basis, both for business initiatives and for architectural ones. Ideally, this is a five-minute presentation with subsequent answers to questions. The result of the review is the decision about the future fate of the initiative. She can:
- go back to backlog for revision
- to be abolished without a chance for further life (for this, I use the separate Out-of-Date status hidden on the Kanban board)
- get agreement and go to the next stage - Analyzing.
At this stage, we - hurray! - we can attract employees from IT: analysts, architects, leads, anyone. By “we,” I mean myself as a Release Train Engineer, but ideally business owners who have already gained some experience and autonomy necessary to attract the right teams and independently launch the analytics process. I am writing about the ideal case, because the level of self-organization of our colleagues is floating, and in some cases they ask for help in the form of a specially appointed facilitator, but I try to step back from this practice.
The purpose of this stage is preliminary analytics, or, as we call it, pre-discovery. At the output, we should get the minimum that will allow us to commit: proposed solutions, risks and dependencies, non-functional and infrastructure requirements, user maps (user maps), architectural schemes. In addition, we ask the teams to give a preliminary assessment in story points (story points) at the feature level - this will allow us to determine priorities at the end of the quarter.
For each initiative, a personal Kanban board is created in which, as they are created, features and storyboards can be seen, with a primary link to a specific iteration, which is ensured by a separate workflow in the form of future iterations. In boards svanely are configured on development teams. Since our JIRA-ecosystem is rather complicated, during pre-discovery and discovery we create tasks in separate projects in order not to litter the backlog of commands:
Also at the stage of analytics, architects are involved in this process or, as is customary in our country lately, their trusted people are “EA Ambassadors”. Their task is to convey to the participants of the process the vision of the architectural department, to help find the best solution, and finally to coordinate this solution with the chief architect of the company (Head of Enterprise Architecture).
When teams believe that the initiative is sufficiently developed and ready for the next step, they move it to the next status - Portfolio Backlog.
At this stage, an important step is to conduct a WSJF prioritization ( Weighted Shortest Job First ). To do this, we have a big meeting 3 weeks before the planning, which, unfortunately, takes many hours so far, and during this meeting with the help of Fibonacci poker, the members of the management board evaluate the Business Value (time value) Time Criticality), potential risk reduction (Risk Reduction) and Opportunity Implementation (Opportunity Enablement):
To be able to track the history of initiatives, for each of them I add a label (label) in jire with quarter data: 2018Q4, 2019Q1, etc.
Looking ahead, I will describe the following possible statuses. After the commitment of the commitment, initiatives successfully taken into work are moved to the Implementing status, while those “not affected” receive Parked status and have the opportunity to be considered for the next quarters. Delivered initiatives move to Done .
As a result, we have about the following image on the Kanban board:
Of course, we are not even in the middle of the road yet, but at the moment I can already note that thanks to the use of Kanban at the Portfolio-Backlog level
- Business owners began to work out initiatives in detail and seriously prepare for the review.
- The reviews have become more meticulous in a good way.
- Teams have more pre-discovery time.
- I do not lose the old initiatives - you can always go back to the parked, undelivered or forgotten initiatives and work on them further
Tools used at this stage:
- Atlassian Jira Software Server
- Plugin Colors for Jira - for highlighting business and architectural initiatives
- The plugin 'Structure - Project Management at Scale' - for visualizing the structure from initiatives with features linked to them and their WSJF prioritization
- Atlassian Confluence - source of internal documentation
- Lucidchart and its plugins for Jira and Confluence - for drawing diagrams
Part I. Preparation for Planning
Somewhere a month before planning comes the hot time of preparation. Too much needs to be taken into account, and in order not to forget anything, you have to create a multipage “logistic” Google table. I will try to describe the most important tabs from this table and the activities around them.
Feedback. A few days after each planning we conduct a retrospective, and in order to correct the course, it is important not to forget what conclusions we came to and how we need to adjust the course. This is an important part in terms of continuous process improvement.
Technical training. With the transition to remote planning, specific requests have arisen, such as the quality of Internet connection (prioritization and optimization of routes for JIRA and Confluence) and television and audio presence (we use the Logitec Group kits, Jabbra microphones and personal headsets in various combinations, webcams, Zoom software for video conferencing).
Facilitators. Here is a list of employees responsible for facilitation in each of the working groups, indicating their location and a link to the permanent Zoom-channel of the working group.
Lecture hall. Accordingly, the complete list of all invitees.
Check list. Full list of important tasks with deadlines and responsible. For greater immersion, I will cite several examples of the most characteristic and important tasks that are repeated for each planning: training of facilitators (a training manual is prepared for the facilitators with all the necessary steps from organizing a working team, timing the meetings on researching technical options and decomposing the initiative into a list of features) ; update of working groups location plans for each office; control of the speed update for all development teams; ordering meals; creating reports from previous quarters; printouts of lists of initiatives (to be at hand) and schedules.
Part II. Planning and Commitment
After all the preparatory running around, this moment finally comes - the start of quarterly planning. In two days we must have time to disassemble all initiatives, make sure that the information is sufficient and commit. After several short but incendiary speeches, the working groups disperse in places and get down to business. At the moment, the number of groups is distributed among the three offices according to the 4x4x2 formula, and remote users are connected to the required table via a dedicated Zoom channel.
Upon completion of the discovery of each of the initiatives, the facilitator, making sure that all the necessary data - such as acceptance criteria, technical solution description, risks, dependencies, the need for a new infrastructure - is available, notes the initiative of the IT Session Finished checkbox for transparency of progress and the working group may move on to the next.
After a dozen of plans, the feeling of constant nervous tension and temporary time pressure, which was with us from the very beginning, has significantly resolved, and now the atmosphere is more like calm work. In the second half of the first and second day, there comes a time for a slow commitment according to priorities. To perform a commitment, I have several separate structures. The first one is a structure containing a list of features and sites scheduled for the commitment:
Unfortunately, this structure contains remnants of material that did not fit into the commitment of the current quarter, so the sample is unrepresentative. In any case, in the search, I can select the initiative of interest to me in order of priority by number, which in the discovery process is put in a separate field for each feature and story, change the status of the necessary tasks from Planned to Committed and place it at the desired iteration, thereby committing itself:
As a result, the task will disappear from this structure and appear in a new, reflecting growing commitment:
As you can see in the screenshot, in this structure, the stories fall into the folder of the development team to which they belong and are grouped by iteration. Here, I see the common velocities of the command in the folder name, as well as in the Commitment column, using the formula, the overcomment is automatically determined for each group and signals to us in red.
Of course, if the first and highest priority initiatives go into a committment without problems, soon, with the appearance of the first teams that have filled their backlog to failure, problems and some initiatives begin not without controversy, but have to be postponed.
At the end of this simple process, the teams on the company's flag solemnly swear to deliver the commitment (joke) and run up to their homes (also a joke - everyone runs up to the bars).
Tools used at this stage:
- Atlassian Jira Software Server
- The plugin 'Structure - Project Management at Scale' - to monitor the discovery process and during the execution of the commitment.
Part III. Cloning tasks into a working JIRA-ecosystem of the company
While everyone is drinking vodka, RTE is working on creating commitments in the form in which it can be distributed to the backlog of development teams and monitored throughout the quarter. For this, I use the 'Bulk Clone Professional for Jira' plugin - it adds an item that provides collective cloning to the Bulk Change menu, and has such necessary features for me as link cloning, updating links between newly created clones, updating epic links, adding prefix header and automatic label addition:
I add status as a prefix, because at the planning stage the statuses reflect the planned iteration of completion, and as a result I see right away in the title when we are planning to finish the feature or story.
At first, I clone absolutely all tasks into a separate Global Backlog project, since we keep epics in it, and I need to have actual epic - story connections in newly cloned tasks. And already as a second step, I make requests for each development team separately and move the story into the final projects of the teams.
As a result, I create a structure that reflects the current commitment and consists of final tasks, which I then use for monitoring:
In general, the advantages that resulted from this approach are the following:
- No matter how trite, but new features and storytelling is easier for a person from IT to type than to write with a marker on sticky paper.
- Many things, such as capital residual and WSJF update depending on the ratings of parties, are calculated automatically using formulas.
- Thanks to cloning, the original cast of the committment is preserved for history and can always be returned to it.
- Time and energy on planning preparation is very much saved - paper handling takes power.
- Of course, it's great that you no longer need to fill the bag in the jeera with paperwork.
Tools used at this stage:
- Atlassian Jira Software Server
- Plugin 'Bulk Clone Professional for Jira' - for cloning features and story into final JIRA projects.
- Plugin 'Structure - Project Management at Scale' - to create the final structure.
Epilogue
Friends, I, of course, understand that the description is rather superficial, and a lot of things could be revealed in more detail - monitoring the distribution of capital between business and architectural initiatives and operational tasks, calculating formulas in structures, managing risks and much more. But I still do not understand whether this topic is interesting to the audience, and if so, what exactly. If I see interest, I will be ready to reveal the necessary topics.
And one more thing - it’s hard to believe that this is possible, but by all means I would like to avoid sracha around the edjal, frameworks, effective and “effective” managers. Please remember that I described the whole process in the hope of getting interested by the people who are close to it, with its technical implementation, and I look forward to the relevant discussions.
See you in the comments!
Source: https://habr.com/ru/post/452330/
All Articles