For most people, Scrum is basically just a buzzword. In today's world of IT, you should notice that it is a kind of game-changer in “project management”. Nowadays, even large IT corporations, banks and most software developing companies are trying to implement the Scrum framework.
In my own experience, when someone tells you for the first time how Scrum should work and what the benefits are, it's really quite hard to switch from that classic “waterfall” mindset and give in to it. And it might not even be all because of the project manager's mindset, but rather a general distrust that the framework actually functions on what is essentially a “flat” organizational structure. For me, this is one of the biggest added values. It’s also the biggest change that simply has to occur within the company, so I'd like to spend some time on it.
Scrum is a "flat" organizational structure. Period. That's something I really enjoy about it. There can be none of “Boss, that's not on me, it's not my responsibility”. The development team (and me being part of it – the Product Owner) bears all responsibility for the product together. At the beginning of a sprint, the team commits to develop a set of requested functionalities by the end of it. Both the team as a whole and the individual members often receive feedback on their work. This is thanks to client reviews at the end of a sprint. It might seem, and often is the case, that the main responsibility lies with the Product Owner, but that is not the right approach. The fact that a client request is bad is a mistake on part of the PO, but also the team should have stepped in before it gets into development.
However, going back to the evolution within. It was not such a problem for us in this company, because there are not many of us and in any organization with fewer than 20 people this transformation is quite an easy change. We’ve never had a rigid organizational structure. We are all on a first name basis here and are basically friends. A certain amount of responsibility suddenly spilled over from the project managers to the developers themselves, which benefited us greatly. This way you make a better product. You let the developers and designers talk about the requests they receive and give them the chance to adjust the product so that they can feel proud of it.
The fact that this kind of transformation is easier in small companies is clear. But what about large corporations? Entire IT departments and other complex structures? How well are they managing to apply it? Not very well! Just because suddenly it's not all the analysts sitting together, the architects together, or designers together in their peaceful offices. Out of the blue, you have someone come to you and say, “We are going Scrum starting tomorrow”, and you will suddenly find yourself in a new office belonging to the “blue team”.
Another issue is switching roles based on someone telling you at a training that you need a Scrum Master. He or she then points at someone and makes them into the Scrum Master. And that’s basically evil. And it obviously won't work.
In any case, that's enough for now and let's focus on the individual roles and some details of teamwork next time. Please take care and comment below with questions or suggestions for future blog posts. I can’t wait to read your ideas! :-)
