This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
Moving from “Command and Control” to “Innovative Agile Management”
“Ownership” describes how a knowledge worker needs to be part of the whole process and not just a specialist in a department.
The concept of “business” has changed dramatically since the Industrial Era. The idea of business as we know it was created in the early 20th century. There was (simple, mechanical) work to be done that could not be done by the machines that launched the Industrial Revolution. Instead, the work required tactile fingers or human strength. The people who carried out the work received exact instructions on what to do, according to a clear plan.
As the economic process became more complicated, no individual person or team could work on completing a single product. Competition was harsh, resources had to be delivered just in time, and ultimately, the idea of a “knowledge worker” was created. Problems were no longer solved on the business level, products were no longer clones, every product was individually crafted and new. Workers ceased to be “copying machines” and became inventors, communicators, and researchers. In today’s highly technical world, micromanaging a knowledge worker is only possible if you already know the solution and all the steps involved. A low-risk project with expectable outcome: perfect for the Waterfall method. But if you do not know the market or technology, it is up to the team to work out the solution on their own, ideally with an Agile technique.
Scrum recognizes this change by putting the Scrum team at the center of development. In order to produce something relevant for the customer in a quickly changing market, the team needs to feel a sense of ownership, not only in the confines of their specialty or department but also of the overall product.
This connects to what I have written about multidisciplinary teams. The development team is seen by management as incapable of making the right business decisions—and often rightfully so, because HR hired developers, but not people with business, marketing, or sales experience! Last but not least, upper management tends to see moving people from teams “up” to middle management as a reward.
In reality, the situation is more complex. Striking the right balance between business and development is difficult. But this difficulty is mostly rooted in the fact that in order to implement these Agile ideas, established systems within the company have to move away from the Waterfall method.
It comes down to the ultimate question: Do you really want an Agile team? Or do you want to keep important decisions outside the team and enforce a system of command and control, moving and managing work packages from team to team?
Now, to get back to the ground, which parts of Scrum are affected by this? Or, a better question would be: in your existing implementation of Scrum, how do you recognize symptoms relating to a team’s lack of feeling of ownership?
I will explain three examples to illustrate:
A demand for commitment and overtime. Directly or indirectly, a manager might interpret the idea of “commitment” as a contract of delivery. On first glance, Scrum very much seems like an external company contractually bound to deliver a certain set of features in a certain amount of time (a sprint). This leads to a lot of failed sprints, high employee turnover, higher salary demands, the installation of the Scrum Master as the team cheerleader to motivate the team to perform, or a combination of these. This led to an update of Scrum in 2011: the word “commitment” was replaced with “forecast.” The idea of Scrum is not to be able to create perfect sprints which will, in the end, deliver exactly as promised. If that is required, and if your business depends on such a model of planning, use a different method. If you need the output of Scrum in another department exactly at the “promised” date, you are practicing the Waterfall method, not Scrum! Even in large-scale Scrum, the planning of the new sprint does not start weeks ahead, trying to include the results of other teams. It starts on the first day of your sprint.
Additional meetings. Beyond your regular Scrum meetings, a lot of other meetings might happen that involve the Scrum Master, product owner, or members of the Scrum team. This is usually taken as something normal. But I suggest carefully logging and looking at each of these meetings. The findings might hold valuable information about the quality of your Scrum process. Ask the questions:
– Why exactly is this meeting being held? A meeting with upper management about the course of the product might point to a lack of ownership on the part of the team.
– Who exactly is needed for the meeting in question? If meetings always include everyone, this might point to a lack of scope and planning. Maybe two or three people are enough to discuss an important technical issue. Maybe backlog grooming requires only part of the team.
– What about non-formal meetings that interrupt the work of the team? Some meetings could be delayed and made part of the regular Scrum meetings.
Deployment, demo, or installation issues. Encountering issues at the very last “phase” of the project is a common problem, yet it points to a much larger issue, especially if the demo is seen as work that can be squeezed in at the end of the sprint. As with all bugs, you can and should trace these particular issues back to the origin and find out the reason they were made (for example, was the demo made at the end of the sprint during overtime hours?). Given an issue’s particular place of occurrence, you should focus on:
– Project and test planning. Having bugs in one particular place means that there is an imbalance in the parts of the program you test. In the Waterfall method, the parts developed first underwent more testing and more changes than the later parts. In Agile, your goal should be to have all parts equally tested.
– Non-involvement of the team in the deployment phase. Looking back at my history as a programmer, I always felt the need to take extra care when I was the final person responsible for delivery. I took extra care because I would be the one staying up late at night (yeah…) to fix the issue when customers came complaining.
– Scrapped projects or features after development. This happens. Unfortunately, often way too late because no decision could be made within the company and responsibilities were pushed from one desk to another within the company hierarchy. Why does this happen?
Ultimately, it is due to a lack of connection between the customer and the Scrum team. It might point to non-involvement of the team in the final phase of the project. And that is not testing or deployment, it is getting the product to the customer! If it is an internal project, it means getting it to upper management. If you see an increase in developed projects or features being scrapped, you are either increasingly falling back to the Waterfall method, or your team does not have marketing or sales expertise.
To summarize: Keep your eyes and ears open. Situations such as a lack of motivation or ownership by the team should not be accepted, but the cause of such issues often lies much deeper, below the surface. As a Scrum Master, you are like a medical doctor, looking for clues about the underlying issues.
