> Agile is about ditching managers, bureaucracy, and estimates in favor of empowering the team itself.
Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers:
* know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement;
* at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted;
* reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira);
* decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast";
* make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day.
If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.)
So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this:
The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes.
This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.
> for example, this is the occassion when the developers could collectively decide to stop using Jira
That's the gold standard! You know you are doing fake agile when the team is not allowed to decide stop using Jira.
In all seriousness, thanks - very valued insights! I did not even know those were the original purposes of the Scrum ceremonies, having only ever worked witn almost exactly the kind of pseudo-Scrum you describe.
Perfect litmus test indeed! I worked in one place where scrum master - the person explicitly assigned to protect the team - was the one who most loudly imposed that the company configured Jira shall be used. Despite this being brought up as a PITA every retrospective.
This is the moment you know you are doing fake Agile and your scrummaster is just the managers puppet in disguise to spy on the team.
It is difficult for the Scrum Master to be impartial in a situation where the management ultimately decides who will be the Scrum Master and whether Scrum will be used at all.
I am not sure what would be the right solution. One possibility is to fire the management, or never even hire them at first place -- if you want to have a software company that uses Scrum, do it from start. Another possibility is to have a Scrum Master with strong political skils... which more or less means, it cannot be a former developer.
Probably the fatal mistake is having too many managers in the company. At that moment, it is practically guaranteed that they will try to interfere with everything. They have to, because that is how they protect their own jobs. And they will hire more managers, because that is one way to get higher on the company ladder (hire more people into positions below you). And at that moment, everything is doomed, because now the company serves the managers instead of the other way round.
I guess this means that Scrum can work as intended only in small companies. Where the Scrum Master is not below several layers of management, but on the same level as the few managers, right below the company owner.
Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers:
* know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement;
* at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted;
* reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira);
* decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast";
* make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day.
If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.)
So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this:
The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes.
This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.