Predictability Framework

Execute for assured outcomes

At TechMojo, our partners experience certainty in our outcomes through our strong execution capabilities that assure transparency, predictability, and consistency in everything we do.

As part of the predictability framework, we strive to institutionalize transparency, predictability, and consistency in our execution so that our partners can experience certainty in our outcomes.

Towards this, we first train our staff on how to declare their “Individual RAG” status correctly and courageously. “RAG” status stands for Red, Amber, or Green status which represents the team member’s confidence about completing their individual sprint-assigned tasks by the set due dates. The team members declare their RAG status as “GREEN” when they are 100% confident of completing their individual sprint-assigned tasks within their set due dates. They declare their RAG status as “AMBER” when they have impediments in their way, however, they are 100% certain that they can complete their sprint-assigned tasks within their set due dates. They declare their RAG status as “RED” when they have impediments, and they are not confident of meeting the due dates for all their sprint-assigned tasks. That is, they declare their RAG status as RED when at least one of their individual sprint-assigned tasks can slip their set due dates.

The RAG status sets the foundation brick for our transparency endeavor. From individual RAG status, we then decide the team RAG status as the most concerning status of the team members. That is, within a team, if one member is RED and the rest of the team members are GREEN, then the team’s RAG status is RED because RED is the most concerning status expressed by at least one of the team members. In the other POD team, if one member is AMBER and the rest of the team members are GREEN, the RAG status of that team is AMBER because that is the most concerning status of at least one member of that team. Now, the overall program RAG status is RED because that is the most concerning RAG status of the teams involved for that day. The rationale for this is that we want visibility for the impediments and want them to be addressed at rapid speed. This is where our transparency in making individual-level, team-level, or program-level impediments will not only help to bring in early identification of impediments or risks but also seek everybody’s attention in resolving it. This way, we resolve impediments early and thus we make progress as per the plan, this ultimately leads to predictability.

As part of our daily standup meeting, each team member updates below four key themes to the rest of the team members.

  1. What is my RAG status? (Individual confidence on completing the set sprint backlog)
  2. What did I do yesterday? (Review of yesterday)
  3. What am I planning to do today? (Plan for today)
  4. What impediments do I have on my way? (Impediments/Risks)

After the conclusion of the daily standup meeting, we will get story-wise, and team member-wise impediments/ risks daily. Daily, we then collate these impediments and publish to our partners about the current impediments along with their next action, assignee, and ETAs for resolution. The early identification of impediments/risks and flagging of their resolution actions to the key stakeholders set the transparency on “daily team progress” and “predictability of the sprint backlog on a daily basis”. Thus, our partners are informed about the sprint backlog status daily contrary to the rest of the world where they get to know about sprint backlog status on the last day of the sprint.

We train our staff to work with a “sense of urgency” while completing the sprint backlog. We work on impediments in such a way that we go all our way to resolve them as early as possible by extending all that we could do within our capacity. As part of the sprint demo, the product owner and team agree on what user stories have met their acceptance criterion and what user stories did not meet their acceptance criterion along with their reasons. We then proceed for a sprint retrospective where the team discusses “what went well”, “What did not go well” and “What can start” on the levers’ named progress, people, and tools. Being on the same page with our partners, we settle each sprint by the end of each sprint taking adaptive actions for the next sprint.

Our commitment to meeting sprint-wise objectives gives predictability toward our release-wise goals. Early identification of impediments and efficient risk management strategies will not only give predictability about our release-wise goals but also enable our teams to consistently progress as per the set plan. Thus, our predictability framework leads to consistency and uniformity in our methods and outcomes.

In the entire process, we ensure that product owners have full control in prioritizing the payload for the release as well as sprints. Thus, our business partners experience more control over what features are to be prioritized for what sprint or release.

Thus, our predictability framework helps our business partners experience certainty in our outcomes through transparency, predictability, consistency, and more control over the prioritization of user stories.