May 17, 2019 at 16:22How to conduct distributed paperless quarterly planning and not screw it up?
Given: A company that uses the Scaled Agile framework (SAFe) to scale Agile development across the organization; 10 development teams, combined into one large team (Agile Release Train, according to SAFe terminology), delivering a common product; the need for 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 distant exceeds 6 thousand kilometers with a corresponding difference of 5 hours of working time; previous planning experience, involving the physical presence of key colleagues in the same room and the use of analog boards / whiteboards / markers / sticky notes.
* The heavyweight construct “IT Team Work Plan for the Next 3 Months” threatens to seriously increase the volume of the text, so in the future I plan to write simply - “comment” instead. Accordingly, draw up and adopt a work plan - “commit”.
1) Fatigue from analog working methods. While spaceships plow open spaces, and Elon Musk digs tunnels, we IT specialists persistently write with markers on sticky pieces of paper and sculpt them on the boards - this is a kind of dissonance. This was our comment some time ago:
Yes, this is a piece of paper about 2x5 meters in size, and each piece of paper should, after planning, be turned into a task in Jira ...
2) The fatigue of fellow nomads. 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 were not at all happy with such a nomadic life, and my arguments in the style of “C'mon, you’re swimming in the sea, bask in the sun ”, which I had the imprudence to express, were not very warmly received - not everyone is ready for frequent business trips, their households do not always welcome this, someone doesn’t react very well to frequent flights.
3) Connecting more colleagues from IT to the planning process. As is clear from the previous paragraph, we could not afford to send the entire office for planning, therefore we sent only the Chosen, thereby excluding the rest from the process, which did not add pluses to the general morality.
4) Optimization of financial costs. Yes, this is a sensitive moment - there are a lot of key people, and carrying them back and forth four times a year is an overhead.
And it all starts much earlier - in order to work fruitfully on the comment during planning, it is necessary that there is something to commit. To ensure this, I have to “load” business owners with work on the proposed initiatives (or, in SAFe terminology, Epicam, but I will use the term familiar to me) as early as possible. Ideally, this process should be completely divorced from the cyclical nature of quarterly planning and go its own, kanban way. As a basis, we took SAFe portfolio Kanban:
We have a separate JIRA-project with three types of tasks: epics, business initiatives and architectural initiatives; as well as the corresponding Kanban board. The algorithm for the business owner of the initiative is simple: he adds the task to this project, and by default it falls into Backlog - this is the first status of our kanban -Funnel:
It stores initiatives that are not yet ready for review. The business owner works on the content of the initiative until he feels ready for the next step. The minimum required at this stage is the completed Problem Statement, Desired Outcome and Measure of Success fields, as well as a slightly more detailed, but simple and clear presentation. At this stage, it is important to get away from mentioning technical solutions and focus on business parameters. When all the data is collected, the owner moves the task to the next status - Reviewing.
We conduct a review 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 a decision on the fate of the initiative. She can:
At this stage we are cheers! - we can attract employees from IT: analysts, architects, leads, anyone. By “we,” I mean myself as a Release Train Engineer, but in the ideal case, business owners who have already gained some experience and the independence necessary to attract the right teams and start the analytics process on their own. I am writing about an 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 a bit from this practice.
The purpose of this stage is preliminary analytics, or, as we call it, pre-discovery. At the exit, we should get the minimum that will allow us to commit: the proposed solutions, risks and dependencies, non-functional and infrastructural requirements, user maps (user maps), architectural schemes. Additionally, we ask teams to give a preliminary assessment in story points at the level of features - 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, you can see features and stories, with an initial binding to a certain iteration, which is provided by a separate workflow in the form of future iterations. In the boards, custom teams according to development teams are configured. Since the JIRA ecosystem is rather confusing, during pre-discovery and discovery we create tasks in separate projects so as not to clog the backlogs of teams:
Also, at the analytics stage, architects are involved in this process or, as we have recently adopted, their trusted people are “Ambassadors” (EA Ambassadors). Their task is to convey to the participants in the process a vision of the architectural department, to help find the best solution and, in the end, to coordinate this solution with the chief architect of the company (Head of Enterprise Architecture).
When teams believe that the initiative is well developed and ready for the next step, they move it to the next status - Portfolio Backlog.
At this stage, an important step is to carry out the WSJF-prioritization ( Weighted Shortest Job First ). To do this, we hold a large meeting 3 weeks before planning, which, unfortunately, takes many hours, and during this meeting, using the Fibonacci poker score, management board members evaluate Business Value, time criticality ( Time Criticality), potential risk reduction (Risk Reduction) and implementation of opportunities (Opportunity Enablement):
In order to be able to track the history of initiatives, to each of them I add a label in the label with data on the quarter: 2018Q4, 2019Q1, etc. .
Looking ahead, I will describe the following possible statuses. After committing, initiatives that are successfully taken to work will move to Implementing status , while “non-fit” ones will receive Parked status and in the future have the opportunity to be considered for the next quarters. Delivered initiatives move to Done .
As a result, we have about the following picture on the Kanban board:
Of course, we are not even in the middle of the path, 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, it’s a hot time for preparation. There is too much to consider, and in order not to forget anything, you have to create a multi-page “logistic” Google table. I will try to describe the most important tabs from this table and the activity around them.
Feedback. A few days after each planning, we conduct a retrospective, and to adjust the course, it is important not to forget what conclusions we arrived at and how we need to adjust the course. This is an important part in the context of continuous process improvement.
Technical training.With the transition to remote planning, specific requests arose, such as the quality of Internet connection (prioritization and route optimization for JIRA and Confluence) and television and audio presence (we use Logitec Group kits, Jabbra microphones and personal headphones 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, a complete list of all invited.
Check list.A complete list of important tasks with deadlines and those in charge. For greater immersion, I will give several examples of the most characteristic and important tasks that are repeated for each planning: facilitator training (a training manual has been prepared for facilitators with all the necessary steps from organizing a working team, timing meetings to explore options for technical solutions and to the process of decomposing the initiative into a list of features) ; update of working group location plans for each office; control of the update of Velocity for all development teams; lunch order; reporting on previous quarters; printouts of lists of initiatives (to be at hand) and schedules.
After all the preparatory running around, finally comes this moment - the start of quarterly planning. In two days we must have time to sort out all the initiatives, make sure that there is enough information and commit. After a few short but incendiary speeches, the working groups disperse in their places and get down to business. At the moment, the number of groups is distributed between the three offices according to the 4x4x4 formula, and remote users connect to the necessary table through a dedicated Zoom channel.
At the end of the discovery of each of the initiatives, the facilitator, making sure that all the necessary data - such as acceptance criteria, a description of the technical solution, risks, dependencies, the need for a new infrastructure - exists, notes the initiative with the IT Session Finished checkbox for transparency of progress and the working group may move on to the next.
After a dozen plans, the feeling of constant nervous tension and temporary time pressure that has been with us from the very beginning has resolved significantly, and now the atmosphere is more like a quiet work. In the second half of the first and second days, the time comes for a leisurely comment in accordance with the priorities. To execute the commit, I have several separate structures. The first of them is a structure containing a list of features and paths planned for comment:
Unfortunately, this structure contains the remains of material that did not fit into the comments of the current quarter, so the sample is not representative. In any case, in the search, I can select the initiative that interests me in order of priority by number, which during 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 put it in the right iteration, thereby committing itself:
As a result, the task will disappear from this structure and appear in a new one, reflecting the growing comment:
As you can see in the screenshot, in this structure the stories get into the folder of the development team to which they belong and are grouped by iteration. Here, I see the overall team velosity in the folder name, and also in the Commitment column, using the formula, the overcomment for each group is automatically determined and signals us in red.
Of course, if the first and most priority initiatives come into comment without problems, soon, with the appearance of the first teams that have filled their backlog to failure, problems begin and some initiatives are not without debate, but they have to be postponed.
At the end of this simple process, teams on the flag of the company solemnly swear to deliver a comment (a joke) and scatter home (also a joke - everyone scatter through bars).
While everyone drinks vodka, RTE is working on creating a comment in the form in which it can be distributed to the development team backlogs and monitored throughout the quarter. To do this, I use the plugin 'Bulk Clone Professional for Jira' - it adds an item that provides collective cloning to the Bulk Change menu and has such necessary features for me as cloning links, updating links between freshly created clones, updating epic links, adding prefix in the title and automatic labeling:
I add the status as a prefix, because at the planning stage the statuses reflect the planned iteration of completion, and as a result, I immediately see in the title when we plan to finish the feature or side and.
First, I clone absolutely all tasks into a separate Global Backlog project, since we store epics in it, and I need to have relevant epic - story connections in freshly cloned tasks. And already as a second step, I make requests for each development team separately and move the stories to the final projects of the teams.
As a result, I create a structure that reflects the current comment and consists of the final tasks, which I then use for monitoring:
In general, the advantages that have arisen as a result of this approach are as follows:
Friends, of course, I understand that the description is quite 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, risk management, and much more. But it’s not yet clear to me 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 I would like to avoid the fray around Edge, frameworks, effective and “efficient” managers by all means. Please remember that I described the whole process in the hope of interesting people who are close to it with its technical implementation, and I really look forward to relevant discussions.
See you in the comments!
* The heavyweight construct “IT Team Work Plan for the Next 3 Months” threatens to seriously increase the volume of the text, so in the future I plan to write simply - “comment” instead. Accordingly, draw up and adopt a work plan - “commit”.
Why is this needed?
1) Fatigue from analog working methods. While spaceships plow open spaces, and Elon Musk digs tunnels, we IT specialists persistently write with markers on sticky pieces of paper and sculpt them on the boards - this is a kind of dissonance. This was our comment some time ago:
Yes, this is a piece of paper about 2x5 meters in size, and each piece of paper should, after planning, be turned into a task in Jira ...
2) The fatigue of fellow nomads. 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 were not at all happy with such a nomadic life, and my arguments in the style of “C'mon, you’re swimming in the sea, bask in the sun ”, which I had the imprudence to express, were not very warmly received - not everyone is ready for frequent business trips, their households do not always welcome this, someone doesn’t react very well to frequent flights.
3) Connecting more colleagues from IT to the planning process. As is clear from the previous paragraph, we could not afford to send the entire office for planning, therefore we sent only the Chosen, thereby excluding the rest from the process, which did not add pluses to the general morality.
4) Optimization of financial costs. Yes, this is a sensitive moment - there are a lot of key people, and carrying them back and forth four times a year is an overhead.
Part Zero, or Portfolio-Backlog
And it all starts much earlier - in order to work fruitfully on the comment during planning, it is necessary that there is something to commit. To ensure this, I have to “load” business owners with work on the proposed initiatives (or, in SAFe terminology, Epicam, but I will use the term familiar to me) as early as possible. Ideally, this process should be completely divorced from the cyclical nature of quarterly planning and go its own, kanban way. As a basis, we took SAFe portfolio Kanban:
We have a separate JIRA-project with three types of tasks: epics, business initiatives and architectural initiatives; as well as the corresponding Kanban board. The algorithm for the business owner of the initiative is simple: he adds the task to this project, and by default it falls into Backlog - this is the first status of our kanban -Funnel:
It stores initiatives that are not yet ready for review. The business owner works on the content of the initiative until he feels ready for the next step. The minimum required at this stage is the completed Problem Statement, Desired Outcome and Measure of Success fields, as well as a slightly more detailed, but simple and clear presentation. At this stage, it is important to get away from mentioning technical solutions and focus on business parameters. When all the data is collected, the owner moves the task to the next status - Reviewing.
We conduct a review 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 a decision on the fate of the initiative. She can:
- go back to backlog for revision
- to abolish without a chance for further life (for this I use a separate Out-of-Date status , hidden on the Kanban board)
- get approval and go to the next stage - Analyzing.
At this stage we are cheers! - we can attract employees from IT: analysts, architects, leads, anyone. By “we,” I mean myself as a Release Train Engineer, but in the ideal case, business owners who have already gained some experience and the independence necessary to attract the right teams and start the analytics process on their own. I am writing about an 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 a bit from this practice.
The purpose of this stage is preliminary analytics, or, as we call it, pre-discovery. At the exit, we should get the minimum that will allow us to commit: the proposed solutions, risks and dependencies, non-functional and infrastructural requirements, user maps (user maps), architectural schemes. Additionally, we ask teams to give a preliminary assessment in story points at the level of features - 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, you can see features and stories, with an initial binding to a certain iteration, which is provided by a separate workflow in the form of future iterations. In the boards, custom teams according to development teams are configured. Since the JIRA ecosystem is rather confusing, during pre-discovery and discovery we create tasks in separate projects so as not to clog the backlogs of teams:
Also, at the analytics stage, architects are involved in this process or, as we have recently adopted, their trusted people are “Ambassadors” (EA Ambassadors). Their task is to convey to the participants in the process a vision of the architectural department, to help find the best solution and, in the end, to coordinate this solution with the chief architect of the company (Head of Enterprise Architecture).
When teams believe that the initiative is well developed and ready for the next step, they move it to the next status - Portfolio Backlog.
At this stage, an important step is to carry out the WSJF-prioritization ( Weighted Shortest Job First ). To do this, we hold a large meeting 3 weeks before planning, which, unfortunately, takes many hours, and during this meeting, using the Fibonacci poker score, management board members evaluate Business Value, time criticality ( Time Criticality), potential risk reduction (Risk Reduction) and implementation of opportunities (Opportunity Enablement):
In order to be able to track the history of initiatives, to each of them I add a label in the label with data on the quarter: 2018Q4, 2019Q1, etc. .
Looking ahead, I will describe the following possible statuses. After committing, initiatives that are successfully taken to work will move to Implementing status , while “non-fit” ones will receive Parked status and in the future have the opportunity to be considered for the next quarters. Delivered initiatives move to Done .
As a result, we have about the following picture on the Kanban board:
Of course, we are not even in the middle of the path, 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 a review
- The review has become more meticulous in a good way
- Teams have more pre-discovery time
- I don’t lose old initiatives - you can always return to parked, undeliverable or forgotten initiatives and work on them further
Tools used at this stage:
- Atlassian Jira Software Server
- Colors for Jira plugin - for highlighting business and architectural initiatives
- Plugin 'Structure - Project Management at Scale' - for visualizing the structure of 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 charting
Part I. Preparing for Planning
Somewhere a month before planning, it’s a hot time for preparation. There is too much to consider, and in order not to forget anything, you have to create a multi-page “logistic” Google table. I will try to describe the most important tabs from this table and the activity around them.
Feedback. A few days after each planning, we conduct a retrospective, and to adjust the course, it is important not to forget what conclusions we arrived at and how we need to adjust the course. This is an important part in the context of continuous process improvement.
Technical training.With the transition to remote planning, specific requests arose, such as the quality of Internet connection (prioritization and route optimization for JIRA and Confluence) and television and audio presence (we use Logitec Group kits, Jabbra microphones and personal headphones 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, a complete list of all invited.
Check list.A complete list of important tasks with deadlines and those in charge. For greater immersion, I will give several examples of the most characteristic and important tasks that are repeated for each planning: facilitator training (a training manual has been prepared for facilitators with all the necessary steps from organizing a working team, timing meetings to explore options for technical solutions and to the process of decomposing the initiative into a list of features) ; update of working group location plans for each office; control of the update of Velocity for all development teams; lunch order; reporting on previous quarters; printouts of lists of initiatives (to be at hand) and schedules.
Part II Planning and commenting
After all the preparatory running around, finally comes this moment - the start of quarterly planning. In two days we must have time to sort out all the initiatives, make sure that there is enough information and commit. After a few short but incendiary speeches, the working groups disperse in their places and get down to business. At the moment, the number of groups is distributed between the three offices according to the 4x4x4 formula, and remote users connect to the necessary table through a dedicated Zoom channel.
At the end of the discovery of each of the initiatives, the facilitator, making sure that all the necessary data - such as acceptance criteria, a description of the technical solution, risks, dependencies, the need for a new infrastructure - exists, notes the initiative with the IT Session Finished checkbox for transparency of progress and the working group may move on to the next.
After a dozen plans, the feeling of constant nervous tension and temporary time pressure that has been with us from the very beginning has resolved significantly, and now the atmosphere is more like a quiet work. In the second half of the first and second days, the time comes for a leisurely comment in accordance with the priorities. To execute the commit, I have several separate structures. The first of them is a structure containing a list of features and paths planned for comment:
Unfortunately, this structure contains the remains of material that did not fit into the comments of the current quarter, so the sample is not representative. In any case, in the search, I can select the initiative that interests me in order of priority by number, which during 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 put it in the right iteration, thereby committing itself:
As a result, the task will disappear from this structure and appear in a new one, reflecting the growing comment:
As you can see in the screenshot, in this structure the stories get into the folder of the development team to which they belong and are grouped by iteration. Here, I see the overall team velosity in the folder name, and also in the Commitment column, using the formula, the overcomment for each group is automatically determined and signals us in red.
Of course, if the first and most priority initiatives come into comment without problems, soon, with the appearance of the first teams that have filled their backlog to failure, problems begin and some initiatives are not without debate, but they have to be postponed.
At the end of this simple process, teams on the flag of the company solemnly swear to deliver a comment (a joke) and scatter home (also a joke - everyone scatter through bars).
Tools used at this stage:
- Atlassian Jira Software Server
- Plugin 'Structure - Project Management at Scale' - for monitoring the process of discovery and during execution of a commit.
Part III. Cloning tasks into a working JIRA ecosystem of a company
While everyone drinks vodka, RTE is working on creating a comment in the form in which it can be distributed to the development team backlogs and monitored throughout the quarter. To do this, I use the plugin 'Bulk Clone Professional for Jira' - it adds an item that provides collective cloning to the Bulk Change menu and has such necessary features for me as cloning links, updating links between freshly created clones, updating epic links, adding prefix in the title and automatic labeling:
I add the status as a prefix, because at the planning stage the statuses reflect the planned iteration of completion, and as a result, I immediately see in the title when we plan to finish the feature or side and.
First, I clone absolutely all tasks into a separate Global Backlog project, since we store epics in it, and I need to have relevant epic - story connections in freshly cloned tasks. And already as a second step, I make requests for each development team separately and move the stories to the final projects of the teams.
As a result, I create a structure that reflects the current comment and consists of the final tasks, which I then use for monitoring:
In general, the advantages that have arisen as a result of this approach are as follows:
- It may sound corny, but it’s easier for a person from IT to print new features and stories than write with a marker on a sticky piece of paper.
- Many things, such as the capacity balance and the WSJF update, depending on the ratings, are calculated automatically using formulas.
- Thanks to cloning, the original cast of the commit is preserved for the story and you can always return to it.
- Time and energy are very much saved on preparation of planning - work with paper takes forces.
- Of course, it’s great that you no longer need to stuff jigsaw puzzles in a gira.
Tools used at this stage:
- Atlassian Jira Software Server
- Plugin 'Bulk Clone Professional for Jira' - for cloning features and stories into final JIRA projects.
- Plugin 'Structure - Project Management at Scale' - to create the final structure.
Epilogue
Friends, of course, I understand that the description is quite 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, risk management, and much more. But it’s not yet clear to me 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 I would like to avoid the fray around Edge, frameworks, effective and “efficient” managers by all means. Please remember that I described the whole process in the hope of interesting people who are close to it with its technical implementation, and I really look forward to relevant discussions.
See you in the comments!