Moving from “command and control” to “innovative Agile management”


“Ownership” is about 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 single 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. In today’s highly technical world, no manager can order a developer how to program without actually knowing how to do the work him or herself. Problems are no longer solved on the business level, products are no longer clones, every product is individually crafted and new. Workers ceased to be “copying machines” and became inventors, communicators, and researchers.


Scrum recognizes this change by putting the Scrum team at the center of the 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 speciality or department but also of the overall product.


This connects to what I have discussed in another article, 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 that might point to problems relating to a lack of feeling of ownership by the team?


I will explain four examples to illustrate:


  1. 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.
  2. 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 those meetings. The findings might hold valuable information about the quality of your Scrum process. Ask the questions:
    • Why exactly is this meeting 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 aspect. Maybe backlog grooming only requires 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.
  3. 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 it is the “last” thing the team has implemented. As with all bugs, you can and should trace them back to the origin and find out the original cause they were made (for example, was it made 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 your program you test. In the Waterfall model, 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 team in deployment phase. Looking back at my long 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.
  4. 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 the other 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 a 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 of 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.


How much does your team identify with the product? To what extent does your team identify with the company? What team-building measures do you prefer? How is the relationship between upper management and the teams? Tell us in the comments!