Andy Brandt

Two fundamental approaches to managing work in organizations - the flow perspective focused on efficiently processing work units through defined stages, and the product perspective centered on continuously evolving product value for customers - shape how organizations structure themselves and measure success. This comparative analysis examines how these contrasting viewpoints influence organizational structures, management practices, and performance metrics, with particular relevance for organizations transitioning to product-oriented operating models. Understanding these perspectives is crucial for leaders making strategic decisions about how to organize and manage work in today's digital economy.

Motivation in professional teams goes far beyond traditional incentives like bonuses or perks. Drawing from software industry experience, I explore three fundamental aspects of motivation that can transform team engagement: product connection, technical craftsmanship, and team spirit. While rarely achieved together, even one of these elements can significantly change how teams approach their work.

Dear Scrum Master! Being a Professional Scrum Trainer, agile coach & consultant for a while I had a chance to work with around a thousand Scrum Masters across different organizations. I see recurring patterns of misunderstanding and misapplication of Scrum usually visible in how Scrum Masters act. Based on that experience I want to share a couple of important points with you in hope that you will seriously consider them in your work. 1. You are not a boss. Repeat: You are not a manager. Repeat: You are not a foreman. Specifically you are not responsible for making sure the team delivers everything that was planned during the Sprint Planning. You are not responsible for gathering reports and coordinating work to meet deadlines. You are not responsible for ensuring everyone chimes in, so you are not responsible for checking if people are working hard enough nor handling laggards. You are not responsible for distributing work nor ensuring it is distributed fairly and in a way that makes best use of the talents and skills of your team. Your responsibility is nurturing, creating a team that would care for most of the above and more. This is a huge difference. A good analogy is that of a sports coach. During a match all a coach can do is watch from the bench. He is responsible for creating a team that will play the game, not directing each and every player once the game starts. In the end it is the team that is responsible for winning, not the coach. 2. None of the meetings in Scrum are for you. You are not supposed to be the center of attention at any one of them. Specifically, the Daily Scrum is not a reporting session, if you stand in the center and everyone else looks at you as they talk you’re doing it wrong. Also, the Sprint Review is not about showing team statistics and burndown charts. It is about showing a working product to the clients. Did I mention you’re not supposed to be the center of attention? That also applies to the Sprint Review, you shouldn’t be the one doing most of the talking — at best you should be the one doing the minimal moderation (that is keeping the meeting focused and effective) while the Product Owner and the team host the stakeholders, present their work and gather feedback. If in doubt what Daily Scrum or Sprint Reviews are for re-read the Scrum Guide or attend a training led by a qualified, experienced trainer from a reputable Scrum organization (as of now this means Scrum.org or Scrum Alliance). 3. You are also not a "Scrum Secretary". The fact that the team “does Scrum” and you have been elected/nominated/duped into being its Scrum Master doesn’t automatically mean that you should draw burndowns, move cards around on the board and keep other “Scrum artifacts” up to date. You may choose to do some or all of those things for a while, especially with a new, inexperienced team, but never ever allow the team to think this is your job as a Scrum Master. Doing that might give them the false idea that all those artifacts are for you — or the process, the management etc. — while in fact they are all for them, the team sprinting to reach the Sprint Goal. You are there to help them realize that. 4. You are also not a technical leader or an architect. You might be a brilliant programmer with lots of experience on the product, but being a Scrum Master doesn’t give you any authority to decide how the product is going to be designed & built. Specifically, as a Scrum Master it is not your duty to do code reviews or (worse) approve code or designs, answer technical questions or make any technical decisions. Doing so would bring you very close to becoming a traditional lead programmer or technical lead and thus would prevent the team from healthy self-organization. Yes, Scrum allows a person to be a Scrum Master and a developer at the same time in the same team. If that is the case you will have to carefully balance those two roles and make it absolutely clear to everyone and in every interaction whether you speak & act as the team’s Scrum Master or as one of the developers. This might turn out to be trickier than it seems on the surface. It may sometimes work, but in most cases the burden is too much for one person which is why it is not the encouraged model. Sadly, many organizations have even made it into a standard thus in most cases denying themselves full benefits well functioning Scrum teams could have given them. 5. You are not the team's spokesperson, nor are you an information relay for the team. As it was pointed out above the Scrum Master is coaching the team, protecting the team, nurturing the team and pushing it gently towards working better and smarter — but is not replacing the team in actually doing the work. Contrary to what some may think a development team’s work does not consist of just typing code into computers while drinking caffeine-rich drinks. It also involves communicating (preferably face to face) with others — teammates, other teams, the Product Owner, stakeholders, clients, users etc. — to first understand what and how to put into code. Very often when analyzing why things went wrong we discover it was because some people didn’t talk, didn’t communicate fast and early enough opting for sending an e-mail then forgetting about it or — worse — assumed this or that was ‘obvious’ and just went ahead based on that unfounded assumption. Because communication is so important for the art of developing software in teams as a Scrum Master you should care about it. This means you should monitor this communication to make sure there is enough of it, encourage it (in most cases just reminding developers it is better to call or walk over and have a chat rather than typing an e-mail is sufficient) at the same time ensuring that the process is not ‘leaking’ (for example no new work is being pushed into the team outside of the Product Backlog and PO’s knowledge). However, it is the team’s responsibility to communicate — it is them communicating, not you. Therefore you should never ever step in to act as a relay. So, if everyone who wants to get some information to or out of the team comes to talk to you, the Scrum Master, you’re doing it wrong. Get out of the way before too much harm is done. CONCLUSION There are of course other misunderstandings and dysfunctions, but the ones above are by far the most common. If any of the points above is not obvious for you please do rethink whether your stance as a Scrum Master — or what is considered standard in your organization — is indeed beneficial and in line with what Scrum calls for. In other words whether you are a Scrum Master — or is it just a title you have in your e-mail signature. Yours truly, Andy Brandt