The current paper comes in response to another paper which appeared in TSM, issue 47, namely Know your enemy, by Vasile Selegean.
My colleague's paper (further referred to as the original paper) made me feel uncomfortable and kept coming to my mind, mainly because the opinions expressed there conflict with my understanding of Scrum. Therefore, I would like to offer another perspective on the aspects raised by my colleague. I will also give an answer to the very same questions my colleague answers, without attempting to offer a full description of Scrum. My hope is for this widespread method in our community to receive a better understanding. I would also like to offer people an opportunity to reflect on and improve their theoretical and practical knowledge of Scrum, an opportunity to become friends with Scrum, once they know each other better.
Here are the 4 principles of the Agile manifesto:
The original paper asks a rhetorical question: What is Scrum if not a process? My answer is: Scrum is a framework for processes, not a process. What is the difference? A framework is a loose process. It offers a structure and a path, without being too rigid or too detailed. By contrast, a process is a predefined set of steps and decisions that should be followed to reach a given goal.
Scrum defines: roles, responsibilities, meetings, the existence and purpose of 2 gateways, a list of artifacts (product backlog, user stories, etc.) and a process skeleton - the sprint, therefore, the three roles and the interactions between them. Starting here, each team builds up the process it needs, by taking into account its goals and the requirements it must fulfil. The process can describe new steps, artifacts (ex: documentation), new gateways even, and can even bring about new details on the missing items. For instance, it will create definitions for the "Done" and "Ready" gateways, as they are the product of the negotiation between the Development team and the Product Owner.
We, therefore, have the process frameworks and the methodologies, which is a starting point that gives us a common language on which we can set the process we need without the need of reinventing the wheel for each new product.
The Product Owner is the representative of all the stakeholders and must gather the requirements from all stakeholders in a single list which contains prioritized user stories, in Product Backlog. This does not mean that the Product Owner must personally gather and edit the requirements for the entire Development team, which would be almost impossible anyway. What is important about his role is the fact that it offers great support to the Development team in solving the conflicts which appear at priority level and offers a point of access for settling the blurred aspects related to requirements.
The Development team has many functions and must have the necessary skills to solve the problems at hand. For any situation, the team cannot solve on its own, the team must ask for Scrum Mater and/or Product Owner support. The possible problems may be linked to the fact that various clarifications, resources or specifications are missing.
Within the Agile paradigm, we must learn a new way to interact and collaborate with the team members. There is no more "command and control", no more hierarchy or competition and the focus falls on collaboration and responsibility. I know how strange this can be for all of us who learnt how not to take on initiative and responsibility. The graph in TSM no.48 sets an example in this respect, because it shows how little we want our manager to offer us freedom. Yet, for me, the most challenging aspect in the entire Agile framework and philosophy is taking on responsibility, and this represents an important opportunity for us to grow, not only as professionals, but as people too.
Estimates are not defined in a clear way, as they are not quintessential for Scrum. Estimates are an essential part of other means of development that are hard to leave behind. However, we must factor in the goal that estimates have. For stakeholders, the estimates can indicate when they will receive the complete functionality. For the Development team, the estimates indicate the volume of work required for a sprint. Each team can decide which are the methods they need to estimate what they need to meet the requirements. Moreover, regarding the way in which Scum is actually used, I came across the suggestion that we should rather use relative estimates, story points being more frequent, instead of effort estimates (Man Days, Man Hours), but I will not go into details here.
The purpose of a sprint must never change in Scrum. What can be done, but only in exceptional situations, is to stop the sprint and to begin the Sprint Planning meeting with a new sprint. The short duration of a sprint is taken as a measure against the situation (exception) mentioned above: there are rare situations when a new feature can no longer wait 2 weeks, if the 2-week interval was not urgent in the first place. Exceptional situations can refer to major flaws in production, which probably do not need the entire team's attendance in a particular sprint. User stories that are insufficiently specified must be captured by the Sprint Planning step as deviating from the definition of "Ready". It is the Scrum Master's duty to discourage the Product Owner from resorting to sprint stops, breaks or pauses as a general work method, because this may have a demotivating effect on the team. It is the Scrum Master's duty to make sure that both the Product Owner and the team understand and check that the user stories are compliant with the definition of "Ready" before introducing them into the sprint.
Development tools such as IDE or versioning tools are not defined in Scrum for the same reason why they are not defined in other process frameworks or other methodologies either. These details are established within the Development team. Of course, nowadays we cannot imagine working without them. Each team, depending on the project requirements, must define the tools and the way in which these tools are used.
Scrum and Agile do not dwell too much on detailed documentation, because only the people involved in the project can know what the documentation level needed for the project they work on actually is. Different products need different documentation types and different documentation depth. There are projects that get created in a month, get delivered, and then are never heard from again. Other products, which have been developed over the course of 25 years, are maintained and extended permanently, and hundreds or thousands of developers contributed to their development. Create as much documentation as you need, but do not measure progress in the development of the documentation: one user story must be implemented in order to be "Done".
Another aspect which is often discusses is the fact that the architecture emerges slowly, during the process, instead of being defined from the very beginning, as is the case for the famous or infamous Waterfall model. The two situations are not opposites actually. Nothing stops the team from beginning the definition of the architecture. I do believe, however, that it is more than welcome to have the entire team involved.
The most important aspects to be noted here are the requirements and the estimates. The customer, having the possibility to change and add requirements even late in the development cycle and having visibility at the level of the entire team, will be more prone to flexibility.
Technical debt can accumulate using any other skeleton for the process, and this is not a consequence of Scrum. Working as developer in an outsourcing company, I hid under the carpet the hours spent on optimizing and rewriting stretches of code. It was not always easy to introduce a task meant to clear the old or very old stretches of code in the project plan. In terms of Scrum, if you do not have to give an account of every worked hour, I believe that the freedom is a bit wider than what I experienced and that "technical depth" is the consequence of a personal work style rather than a consequence of Scrum as a tool.
It is important to know that there is nothing that can prevent the Development team from being considered a project stakeholder. The team can ask the Product Owner to add the changes the team considers necessary, in Product Backlog, and to ask for them to be introduced gradually, in each sprint. This is related to our mission: taking on responsibility. Only when the team truly takes on the responsibility of their own work, can there be an equilibrium in the relationship between the team and the Product Owner. Only then can we argue that there is collaboration, not subordination.
Being open to change does not mean that the Product Owner or the customer can change the requirements at any time, even during the sprint. Being open to change means that the Agile processes foresee the fact that the requirements of the entire product will be incomplete at the beginning of the development process, that they change and that the processes are organized so as to incorporate all the changes, one iteration at a time. Knowing that requirements change, in Scrum, a user story must be completely specified only at the Sprint Planning stage, when the user story must comply with the definition of "Ready", which must be accepted in advance by all development members to be accepted in the sprint.
The original paper and this Code Red made me ponder for a while. Does Scrum truly make us work in a permanent state of emergency? Does it mean that we no longer have time to breathe because we have sprint after sprint? This problem is common for non-Agile environments too. What makes us feel we are a part of the "Code Red"? We are pressed for time and interpret everything as a state of emergency because of the fact that our work is highly visible in terms of deadlines, sprints, results. Moreover, we are all pressed by the daily meetings and by the knowledge that a sprint will always be followed by another sprint. However, these problems will exist with or without Scrum.
In conclusion, I would like us to remember that Scrum is a skeleton on which we build the things we need for our project. Scrum is here to improve the process at each iteration and to help us analyze what can be improved in the retrospective meeting. Moreover, it is essential to accept the fact that Scrum is a tool and, like any tool, it has a predefined scope. It will not solve the problems regarding open-space discussions and versioning, but the more we understand Scrum, the more we can use it to support our team's work. Scrum will not offer solutions to all the problems, but it offers the proper environment to collaborate with the team members, to improve our process continuously and to orient the Scrum Master's support to understand and use the available Scrum resources to the best of our abilities.
by Ovidiu Mățan
by Vasile Boris
by Vlad Haiduc
