Beyond ceremonies and artifacts
How we created a high-performing Agile team in Global Technology.
by Hiren Patel, Senior Manager, Project Management
Up until 2022, the Restaurant Product and Engineering team in Global Technology was building dashboards using waterfall methodology. This happened partly because McDonald’s outsourced the development, and it can be tempting to define all the details of the scope and the final deliverables upfront in the contract.
Unsurprisingly, the team faced the same issues that are often associated with waterfall projects everywhere, and ultimately making them less effective. Furthermore, there were major design gaps between the product that was built versus what was compatible within the McDonald’s ecosystem.
This post talks about how the performance, as well as the perception, of our team improved in 2022, once the team changed its approach. The team implemented the Agile methodology scrum framework but saying that doesn’t say it all.
Teams in many companies all over the world assume that they are Agile teams once they implement scrum ceremonies and artifacts. Upon a closer look, it becomes clear that while many of those teams adopt the mechanics of scrum, they don’t have the right mindset to be successful. In fact, they are often given fixed scope, deadlines and budgets, which they decompose into so-called user stories and batch into sprints. In essence, they are waterfall teams disguised as Agile teams, even if it is unintentional.
Our leadership team supported us in adopting the right mindset and below are a few highlights of how we created a high-performing Agile team.
Focus on products rather than projects
When people think of projects, they assume that projects have a finite end. In fact, many of the leading professional project management organizations explicitly define a project as having a finite end. On the surface, the idea of projects seems very practical in the corporate world. Contracts get approved faster when the final deliverables and firm deadlines are defined upfront; budget planning is simpler when the scope and schedule are already fixed; and managing expectations with leadership seems easier when the triple constraints are firm.
However, the presence of the finite end of the project has some unintended consequences: Deadlines exert pressure on the team and drive decisions throughout the course of the project, which are not always productive in the long run. Decisions may be made with bias toward schedule rather than doing what’s needed to obtain optimal outcomes; as the arbitrary deadline that was established several months earlier gets closer, project teams focus more on getting things done rather than getting things right.
On the other hand, when people think of products, they accept the fact that products always have room for improvement. A focus on projects leads people to make decisions based on deadlines, while focus on products lead people to make decisions based on what’s best for stakeholders.
When our team was project focused, we built a dashboard that checked off some boxes in a statement of work, but the product would not have been of much use to our stakeholders in the real world. In the six months after we switched to a product-centric mindset, we launched a modified version of that dashboard, which is a better fit for our stakeholders.
A product-centric mindset doesn’t necessarily mean that every iteration of a product will be perfect, but it does lead to better products over time compared with the project-centric mindset. And to be clear, product-centric focus is not mutually exclusive from caring about budgets, schedules, and speed to market.
Deliver value frequently
Our team adopted the concept of a product grade when it comes to dashboards, so that we can deliver working products rapidly. A typical family sedan and a luxury supercar both can be working products of high quality, but they are intended to be of different grades. In another example, a manual screwdriver and an electric impact screwdriver both can be working products of high-quality, but they, too, are of different grades.
Similarly, we focused on how we can deliver a lower grade, but high-quality dashboard to our stakeholders quickly and then continuously improve the grade during each sprint. For example, we might deliver a dashboard that contains a table in the first sprint; then, add sorting and filtering capability in the next sprint; then, add a color scheme and drill-down features in the third sprint. At any grade level, the dashboard is always a fully working, high-quality product that our stakeholders can use.
This approach enables us to deliver working dashboards to our stakeholders faster, rather than the alternate path in which we wouldn’t have delivered anything to our stakeholders until the dashboards were of high quality and high grade, simultaneously.
Trust the developers
Like every good Agile team that uses scrum, we use burndown charts, but we do not penalize developers based on the charts. Even when a team has the most talented developers, the burndown charts should not normally look perfect. If the burndown charts consistently look perfect, it’s likely that your developers are more focused on making the burndown chart look good rather than pushing themselves to do their best. That is because estimates are approximate rather than exact and surprises are inevitable in every sprint.
Pushing for a perfect burndown chart is an unrealistic and unnecessary expectation, which usually lowers morale and encourages the developers to game the system. Teams that lean too heavily on burndown charts as the primary tool for measuring productivity might be successful in driving behavior that results in perfect-looking burndown charts, but that is not necessarily going to result in a high-performing team. Instead, we use the burndown charts to educate ourselves on what happened, where we deviated from the sprint plan, why we deviated, and what we can do better. In response to the trust that we give to developers, they trust us with their candid feedback rather than telling us what sounds good. We hold developers accountable based on the working dashboards they deliver, rather than the burndown charts.
Be flexible to change
Sometimes the requirements, priorities, and needs change. Sometimes developers recommend changes to us, and sometimes we ask the developers to change things. There is always careful consideration and good dialogue when changes occur so that everyone on the team understands what the change is and why it is necessary. But most importantly, our team makes an effort to embrace changes rather than avoid them, even if they arise at inconvenient times. Avoiding changes might seem like the better choice in the short term, because it might help keep the burndown charts looking good, it might enable the team to deliver something at the end of the sprint, or it might help avoid a cost impact. However, the debt of not accepting changes accumulates over time, and the cost of repaying that debt could be much higher down the road.
Focus on communication rather than documentation
Documentation is helpful but it has diminishing returns beyond a certain extent. We have user stories with acceptance criteria, design documents, and other documentation that helps us with communication. However, we put the greatest emphasis on constant communication and ensuring the developers clearly understand the requirements. They don’t insist that we write every minute detail in the ticket, and we don’t expect them to figure everything out by simply reading the tickets.
Conclusion
In 2022, the Restaurant Products and Engineering team delivered multiple working dashboards during the first three quarters, along with several rounds of enhancements for each. This was a major improvement from the prior year. Furthermore, stakeholders are starting to recognize the team for its ability to transform ideas into working dashboards that are truly useful to the users. A virtuous cycle has formed within the team that leads to improved performance and improved morale, thanks to the mindset that we adopted.
