Why Scrum matters?

This really is just a personal brain dump on the topic of scrum in large organizations.

Scrum matters, especially in the context of large companies which I have the most experience with, for three reasons:

1. Shielding the “makers” in a “manager’s” world
2. Structuring the conversation around setting priorities
3. Fostering a culture of decision making at the appropriate “level” (man, I hate this word)

I know, I know those are not your three go-to reasons why you are using scrum, most likely something along the lines of: time-to-market, adaptability (if you are lucky, you might even have to deal with a VUCA world), customer feedback, working software over concepts, etc., etc., etc. which are all true. But actually, I think that there is something more fundamental at work, when talking about scrum in big companies, something that goes beyond software, product and goes directly into the topic of culture & mindset.

Maker’s and Manager’s schedule

This is directly inspired from a great post by Paul Graham, called Maker’s schedule, Manager’s schedule. The general idea is that there are two major types of schedule (or units of counting time) and that differ because of the nature of work that needs to be done in them.

There are the manager’s – Paul Graham calls these the “boss'”, but in many organization a lot more people than just the “boss” work on this schedule, probably anyone in a coordinating function – which is counted in units of one hour. Basically people on this schedule think in small units of time: they will spend 15 minutes answering this email, 30 minutes talking to this colleague to get an answer, maybe spending 45 minutes on a powerpoint presentation. There are even some colleagues I know, that count in 5 minutes blocks.

Then there is the Marker’s schedule, which in opposition has much bigger blocks, for example half-days. This is the time needed to work on a chunk of code for developpers or for a scene for writer for example. I also see these as single tasks where one needs to be in the flow to get the best efficiency and result.

Now the issue really appears when these two schedule clash: what may only be a 5 minute slot in one schedule, actually disturbs a half-day block for the other schedule. And this again is something that the scrum approach tries to tackle actively. There is one day blocked for the events needed between sprints & daily check-ins that are at the beggining or at the end of the “Maker’s schedule” so that the developers are the least distrubed and have sufficient time to get into the flow.

I have just touched superficially about this article, but it has been a great inspiration for the way I work with my Dev Team (I am a product owner) and I generally try to give this ariticle to any new team in the storming phase, so that especially the stakeholders working predominantly on a Manager’s schedule understand the repercussion of “just asking a developper to do this small change”. And I think this is something that scrum does especially well in bigger organizations or companies: it created the awareness about the different nature of work but also makes sure (if you follow the guidelines) that the scrum team is shielded within a sprint from having their flow and schedule disturbed.

Structuring the conversation around setting priorities

This argument is probably wider spread but chances are you have come accross the following conversation:

” – So we need to have funcationality A and functionality B for the next sprint, all stakeholders agree on this.
– Ok, but we have estimated both user stories (maybe using scrumpoker-online.org ;-)) and it is quite probably that we won’t be able to do both, so which one is more important.
– No, you don’t seem to have understood me, we need to do both.
– No, I agree, but it the ressources are such that we simply cannot do both, so which one do we work on first?”

Agreed, this is quite stereotypical, but I have had these conversations often enough to say that the focus of an ordered list of priorities in scrum (the backlog) is worth gold in organizations that want to do every, where everything is a top priority. It forces everyone to make an either or discussion (at least for the next task that is being worked on) and while if you are an empowered product owner, you can make those decisions yourself, they are also brought forward and clearly communicated to the stakeholders. So the backlog is a strutured way to work on the most important tasks for the developement team but it is also a great tool for communicating value to the rest of the origaniation. Also this is a mindset shift that is positive for big organizations: make sure that we are working on what brings the most value and bringing the transparency that allows for a conversation around these.

Fostering a culture of decision making at the appropriate “level”

Many companies nowadays aspire to flatten hirarchical structures, while making sure that leadership are not bottlenecks for decision making – often the solution to this is to estabish initiatives that improve decision making at the right “level”, to inspire the employees to take on leadership on their own topics. Scrum also gives a framework to do this, by giving a clear role defition and the included decision making elements and responsibilities.

In a simplified manner, the product owner is respoinsible (and makes the decisions) about the “what”, so what functionalities are and should be worked on. Of course these decisions are not made unilaterally but taking into account input from users, stakeholders and the dev team – but ultimately the PO says: “function B before function A”. But when we talk about the “how”, the product owner again doesn’t hold the reponsibility anymore but the dev team does and they can take into account input from the product owner (if he is technically versed) but the ultimate decision lies with the developement team.

Scrum with the role repartition, supported by the structured events, gives a framework to make sure that decisions are made by the people at the right “level” . Maybe going further than that scrum does away with the idea that there is a “level” for decision making! The decision about what solution should be implemented gets separated into smaller bits (for example the “what” and the “how”) and thus allows for decisions to be made by the people that are the best equipped to make that decision. There is no need of a conversation about “level” but simply a conversation about area of expertise and responsibilities, something that could help companies get where they seem to want to go.

As I am finishing this post, I realized that I have gone into a bit of a personal rant – but I would be interested in your opinions about some of the ideas that I have thrown around.