Interview with Petri Heiramo
Scrum framework has become an essential requirement for managing complex projects and daily functions in a business environment. It’s a solid and successful Agile framework that’s been applied to a variety of projects and teams.
We had a conversation with Petri Heiramo, an experienced Agile trainer and coach with more than 15 years of experience in process improvement. Certified by Scrum Alliance as a CST since 2008, he has held over 300 certified courses and has trained thousands of people, in organizations ranging from small companies and startups up to multinational giants worldwide.
Petri has been involved in a wide variety of projects and, as a result, he has seen the positive effects of Scrum on the human side of software development. That why he focuses on people, as a great listener and motivator, with interactive style in coaching. We asked him to share some of his experiences.
Why Scrum is the most implemented framework in the world and very popular in various Agile environments?
I think part of the reason is that Scrum is fundamentally very simple. It’s as simple as it can be, and still work. And all of that is very intentional, by design.
Unfortunately, that simplicity is also part of the problem. Many people do not realize how deep it goes, and only repeat the basic routines. Scrum is silent about, for example, technical practices, so many people do not pay enough attention to them. There are more than 20 years of experience on how to create really excellent code very fast, but very few companies realize that or pay enough attention to it. Thus, their use of Scrum is only a shadow of what it could be.
Scrum is similarly silent about how the Product Owner can know what is important and how to prioritize effectively, or about what organizational changes you should make to enable effective teamwork. Many companies spread their teams over many locations, and then wonder why they don’t really get much done, or don’t improve.
Part of the reason is there are companies that have made the necessary changes and have become very successful with Scrum (or Agile in general). Other companies see that success and want to benefit from the same. This has created a lot of general interest in Agile, also in the press. So far, Agile has been a competitive advantage, but we are moving to a time where Agile is the standard and non-Agile companies simply struggle to survive.
Finally, I think part of the success of Scrum are probably the certification programs around it. There are many good trainings, and now also more advanced options. These programs have created awareness in the industry and CSM & CSPO are considered a minimum criteria for many positions. There is an increased demand for experienced Agilists and Agile coaches. Many of the people I worked with 10 years ago are now driving Agile change in their current organizations and positions.
How to make sure Scrum team members will work together and become self-organized?
I believe that people work together when they see value in doing so. Forcing them to do so, when they don’t see any value in doing it, will only create opposition. Thus, if we want people to collaborate, we need to create an environment where they need to – and want to – collaborate.
Thus, the Scrum team must have a shared goal that inspires the members. They must understand what they are doing, why they are doing it, whose lives are made better, and what constraints exists for the solution. This goal must touch the hearts of the people; making money for the owners of the company is rarely sufficient.
This goal must also require everyone’s contribution – people must feel that their work is a necessary and valuable part of the outcome. And it must be sufficiently challenging that only by working as a team they can achieve it.
Without those conditions, people feel that it is easier to work on their own. And it is. Working together is always more challenging than working alone. There is always extra effort needed to create shared plans and to keep the member up to date on what everyone is doing. It is always easier not to take responsibility, and simply do what one is told to do. Unfortunately, it is also much less rewarding to do so, and thus many people are quite unhappy at work.
What are the constraints?
Once the above are in place, the people need to self-organize and get freedom to do that. The management must not micromanage the team, but trust and expect that they figure out how to solve the problem. This is very scary, both for many managers and most teams. Too many business cultures are very manager-centric and taking responsibility at team level is challenging and often not rewarded.
Management must therefore create also an environment of safety. Without emotional and psychological safety, other attempts to create space for self-organisation will fail. To put it simply, the way management reacts and behaves when something goes wrong defines how people will behave even when things are otherwise fine.
Finally, it is a fact that very few people know how to effectively self-organize as a group in a business setting. Having a good Scrum Master or Agile coach can help massively. They can observe how things are going, facilitate group workshops and meetings, and help teams reflect how they are collaborating. Without such support, teams often “self-organize” into a very traditional setup (i.e. someone becomes the de-facto leader/manager and tells others what to do).
How much daily Scrum is important and what if team members not seeing value of it?
Daily Scrums are obviously important to maintain the coordination and collaboration within the team at the daily level, but more than that, they are actually one of the more reliable “thermometers” of team health. When the team is not working well, the dailies don’t work well either. But the dailies don’t directly tell what is wrong; only that something is. In our human bodies, fever is a similar indicator.
So, when people don’t see value in a daily Scrum, the most likely reason is that there is no value. Or at least not enough to justify spending the time in it. The two typical responses – quitting dailies and forcing people to participate – are the wrong responses. Instead, it would be important to figure out why there is no value in the daily.
Usually the people in the team simply don’t care enough what others are doing. They have their own tasks to worry about. This directly implies that there is no shared goal that would bind the team together. As I said above, people work together when they see value in it, and they work solo when they think that is more effective.
Making Daily Scrums work is really a matter of making a team work, and that takes us back to things I talked about earlier – shared goal, need for each other, sufficient challenge, and psychological safety.
What is the best approach to understand your stakeholders and customers?
Surely, there are many ways product owners and teams can connect with their stakeholders, but very few beat letting them try the product for real. It is really difficult for us people to imagine what we want, but we can easily tell what we like and don’t like in a product we can touch.
Obviously, it isn’t always easy or even possible to show a version. So very early on, we can use ideas like Design Thinking or Lean Startup to try to discover what customer might want. These are often much cheaper approaches than building something in code. Paper prototypes, visual examples, discussions, and other such simple means are often a good starting point for elaborating on early ideas. And even during development, it is possible to test initially new feature ideas with such approaches.
During development, Agile approaches provide a natural means – the Sprint Review or equivalent. Inviting stakeholders to those meetings will provide an easy way to incorporate stakeholder feedback into the development process itself. If we build features in an incremental and iterative way, the early versions are effectively feature demos which allow refinement of the planned features set.
And then there are the various technical means, like tracking user behavior and A/B testing. They can provide data on actual choices people make and behaviors people have with the product. Many companies are also hoarding all kinds of user data and can make many decisions based on it. This, obviously, only works when there are lots of transactions and users.
When there are only a few stakeholders, we should not forget simply talking to them and asking what they want. We can also run some simple facilitated workshops or sessions to help them express their desires and their relative value to them. Scrum Masters can be very good at coming up these sessions to help their Product Owners.
What are the most common challenges and how to overcome them by using Scrum?
Scrum doesn’t actually promise to solve any problems. Instead, should show your problems and then it’s up to you to solve them. That’s why using Scrum is often so difficult. We often discover so many problems that we don’t know how to deal with them. But it’s not Scrum that is not working.
The most common problem that I see is the lack of actual teamwork. There’s a lot of people working together, but it’s really everyone working on their own and then connecting the results with others. While this is ok with some types of work where we know what we need to do, it is not effective when we have to solve tough problems together. The most effective remedy is working to find a real shared goal and connecting people to it. We also have to make that the problem is multi-faceted, open-ended, and sufficiently challenging.
The second most common is an organizational problem – the structures in our typical organizations are designed towards individual effort. Managers measure people through personal metrics, and reward heroes. We hire people for specific jobs, and then those jobs become small silos in themselves. It preventing us from taking broader responsibility and seeing the greater whole. Business units are grouped around skills or functions, not around customer value or product delivery.
For example, there is a business unit that “owns” the product and customers, but the product is built and operated by separate IT department with their own key metrics that are rarely aligned with customer success. Again, Scrum doesn’t solve this problem, but makes it apparent. It’s up to the organisation to redesign its internal structures and systems.
How Scrum can help?
Many organizations are finding that they do not have good Product Owners. Others are finding that they do not know how to build software in an Agile way. A lot of organizations have trouble coordinating the work of multiple teams towards a unified product delivery. There are still very few really good Scrum Masters. Even if an organisation has them, they rarely know how to utilize them effectively. None of these are “Scrum problems”, either, but all make the use of Scrum and Agile successfully difficult.
But the world is changing. Scrum and Agile are so much more well-known and spread out. Even if there are lots of organizations struggling, there are also more and more of those organizations that are doing it well and benefiting from it. There has been a huge change in the industry during the 12+ years I’ve been trying to make Agile work. Back then, there were only a handful of people, and the Agile books were few. It was possible to own and read them all. Now, it’s thousands upon thousands of people and the books are too many to mention.