Written by You’ll start a new product. Awesome! You gather a great development team to kickstart the product, aka to build an MVP. Since you’ve had the idea of the product, it is natural that you’ll be the CEO of that new startup and, therefore, will make the business decisions regarding your product (launch date, market segmentation, etc.).
You decide on a great marketing and business strategy. Then, you decide on the release dates according to some potential competitors’ plans. Everything seems to be well planned!
The first thing you do in the development part is to begin the inception phase with the team. You tell them what you want to build, they challenge your ideas, you change some things according to their inputs, and everyone reach a consensus on what the product should look like in each milestone, and how they should start coding it. Awesome!
With that in place, you decide to leave the team alone and not micromanage them. Good choice! You focus on the business strategy, while the team is working on their backlog. You glance at how their backlog looks and how it is being consumed… But since you don’t have their context anymore, that doesn’t say much.
One month later, you are 2 days away from the first release. Your team comes to you and say that they have way too much stuff to do and they definitely won’t be able to finish everything by then… What?!
Ok, so that is a common thing in teams… The business and technical plans seldom touch bases throughout the development process. Generally they start at the same point, but diverge fast.
What we use at Plataformatec is a ceremony to align the business and technical plans, and we call it Reality Check. We run it on demand, every time the development team feels they have too much work to do in a short time. That feeling is usually noticed during daily meetings and/or retrospectives. And we try to hold the ceremony as soon as possible to avoid scenes like the above-mentioned.
The ceremony
The participants of this ceremony should be the development team and the people that decide the business plan. It could be the CEO itself, it could be a Product Owner that works as a proxy for the business people, or any other person that could influence the business side.
Before the ceremony, the facilitator sticks to a board, using post-its, all stories left to reach a defined milestone (it could be a new release or any other fixed dates). And they should be ordered according to the former priority decision.
After the ceremony gets started, the development team goes over each one of the cards explaining, in high-level, what they are about and eventual difficulties on their development. The idea here is to put everyone on the same page about the project, and inform all the present stakeholders of the progress.
After the explanation and debate on each of the cards, the facilitator gives to each member a paper in which they’ll write how comfortable they are with finishing the work until the deadline. Usually we use a 1-to-5 rating to facilitate the vote, where 5 is totally comfortable and 1 is not comfortable. Other times we found it more useful to use 1 to 4 to avoid people that tend to choose median numbers, like 3 in the 1-to-5 range.
With the numbers shown at the same time, to not create bias, we let the people that showed the highest and lowest numbers talk to check why they chose differently. After that, we check again how are their perceptions on the feasibility of finishing the work. If most people are still uncomfortable with the deadline, the business side needs to intervene and reprioritize the backlog according to what is more valuable to the product, and/or readjust the deadline accordingly.
Here is another approach that we follow:
- There is a column for the prioritized backlog;
- There is a column for each of the remaining weeks, until the deadline;
- The group tries to reach an agreement on which week each feature will be delivered;
- After that, the group votes, saying how confident they are that the plan will work out (using 1-5 or 1-4)
- If the rating is low, we try to come up with actions to help it increase (using post-its as well).
Conclusion
The idea of this ceremony is to increase the project visibility to others outside of it and, if needed, trigger some changes in the business plan. The faster we have that feedback, the easier and painless will be to think of other solutions. The two different approaches are written here to show you that there’s no right way of doing it. If you are reaching the desired objectives, you are doing it right! 😉
What do you think of this ceremony? Would you use it? Leave your comments below!
This “Reality Check” that you are doing (weighing commitment levels) sounds like something you should do on a sprint planning meetings. It might be that the sprints last longer until you get the necessary feedback or maybe the stories are not refined well enough and small enough to be more precisely estimated? This method might put some additional pressure on the team and might pull a commitment level that will result in overtime. Fix time, budget and quality, and have scope and shorter sprints to adjust accordingly.
Hey Dalibor! Thanks for your comment
Actually, the idea is far from being to weigh commitment levels, and it is good that you said that, because I may have lacked details on how to handle it. The questions that we make, on how confident the team is with finishing those stories, are to bring everybody to the same page on whether it is or not possible to finish that work, not talking exactly if they will indeed do it. After all, we are dealing with real people, real projects and real money, therefore if all tasks won’t be covered before the deadline, we may need to adjust the deadline or the scope, and it needs to be done asap.
So the idea is to bring transparency to the business side of the flow, in order to adjust the strategy. However, it is good to mention that, in order to avoid overwork and overtime like you said, it is good to remove all the “retaliation culture” that some teams have when they say something that may differ from the original plan. For example, if a dev thinks that something won’t be finished, he/she must say it and he/she must not suffer by saying it.
Besides that, when we use Kanban we not necessarily apply Sprint Planning meetings. So if you use Scrum, you indeed could do this reality check during the ceremony, however it could take much longer than necessary.
Hey hey! Thanks for your reply. Do you have an On Site Customer (XP), or Product Owner how Scrum wants to call it, that represents the business and is available to the team? Do you do any other regular events like planning and retrospectives with Kanban and how long is the loop until you get a measurable feedback on the delivery and the process? I get the impression that the “Reality Check” is kind of a reactive meeting that happens at some tipping point vs having proactive meetings that could potentially deliver more continuous improvements but only if they are short, efficient and avoid waste. 🙂
Hey! So yes, in our clients we usually have a P.O. to the projects. We usually do the Daily, Retrospective and Planning (or Replenishing) with Kanban. However we don’t like to call it Kanban (or any other name), since we don’t follow any methodology by-the-book.. We try to implement practices that will improve the process, and not only follow a methodology.
The feedback loop on delivery and process is not long at all. Since we keep metrics of the process, and follow their behaviour everyday, we always have a clue on how the process health is.
About the P.O. being present, they usually are, but sometimes they don’t see the big picture and look at the whole backlog to reprioritize everything.
And this is not a ceremony that should always be used. If you don’t need it, that’s perfect! It means that all your other meetings are being transparent and efficient enough to deliver the information to the business area. And that is awesome! We ourselves don’t use it in all of our teams/clients… But the idea is to pass the knowledge of this kind of ceremony so, when someone has the problem where the business and technical areas are unaligned, they can act on it with a more focused meeting. Does that make sense? 🙂
Cool, thanks for the insights. As long as that works for you, that’s great. I was just curious to learn more details about your process. 🙂
No problem! Any questions you have, just ask us =)