As an agile specialist, I am aware that when one is faced with developing an OKR methodology within a client, one has to first adapt to the culture, context and tools that one finds when entering a client and from there build to improve. That is, to carry out a successful implementation of this type of goal-setting methodology, you must understand the situation, look for the best solution with what is available and agree with the client on what can be changed. I think that is honestly the best way that works for the vast majority of clients we collaborate on.
The context in which I placed myself was the following: three teams working in a cloud center of excellence, with a total of twelve team players. The teams specifically have infrastructure construction and delivery tasks in addition to support and operations.
The OKRs were worked on quarterly, four per year obviously. In this regard, I have not made any modifications.
My initial observations as I began collaborating with the client revealed the following three points:
- The meetings to prepare OKRs were not so regular on specific dates.This makes the team less confused. Previously, meetings were inconsistent and sometimes missed. Giving regularity to events helps make teams more effective and eliminate waste. For this reason, the first thing was to organize the events so that they were regular and the entire team knew that in each quarter they would encounter the same events and with a fixed calendar:
-
- Four one-hour preparatory meetings, the month before the start of the quarter to devise and refine future OKRs for the following quarter.
- A two-hour meeting at the beginning of the quarter, to set them by consensus.
- An end-of-quarter meeting of one and a half hours to review the results obtained.
- Two or three meetings to review your status during the quarter coinciding with the events of the Scrum retrospective. With the duration that is available for this event. I didn’t want to overload the quarter with more meetings and it was a great fit for us to do it at this event.
The duration of the meetings has been estimated based on our experience with other similar meetings that we have already held (planning, refinement, reviews, etc…).
2. Documentation not clear enough, what I used until I arrived was a slide presentation as a tool to document OKRs. This created a lot of confusion and little operability, so I created my own templates with the Confluence tool (a collaborative tool for documentation) with which to structure and set the OKRs permanently. With the following elements:
-
- Objective and key results (which, as you know, are the specific and measurable indicators used to evaluate progress towards achieving the objective).
- Weight of each of the key results within the Objective: this helps us focus on the most important key results taking into account that they all must be completed.
- Current state of achievement of key results, in our case we choose to measure them using percentages between 0% and 100%. And we update them in review meetings during the quarter.
3. Some metrics and data referenced in OKRs were not easy to obtain or plot, so some OKRs did not have the desired power. To solve this problem, I integrated a list with all the tasks to be performed defined to achieve the key results. These tasks are defined and addressed in tasks in our Jira dashboard (Jira tool and its tag management) and a couple of extensions that help us by visualizing certain metrics with which we have established key results. Specifically EazyBi and Time To SLA. For example on one KR: “In the backlog there must be less than 30% of tasks that have been created in the previous quarter and have been carried over to this quarter without having yet been started.” I usually include a table or graph to check in realtime this metric:
I believe that this implementation has been quite positive for the client since due to the feedback received from the client, it is helping them to focus on the objectives, to see them more clearly and to work with them in a more complete way. Furthermore I see that the team has more clear objectives in the area. More alignment, better transparency and they feel more engagement with the company.
On the other hand, I continue to implement new improvements for the next year. I want to test new complements and probably I will reduce some meetings due to the teams having been learning how to work with the framework and we have verified that they have reached a high degree of maturity working with him.
Image: Unsplash | Kelly Sikkema
Agile Practitioner en Keepler Data Tech. "I love working as an agilist helping customers to understand and discover the Agile culture. I am always willing to share all my time and knowledge to bring the most to people. Active listening and continuous improvement are my personal mission."