Everyone has a need for stability, so there have been attempts to translate manufacturing management methodologies into IT. Thus, there is a temptation to think in the following way:
I did what the known methodology told me to do. The developers must not have done what the methodology told them to do. Maybe they didn’t report their progress accurately. Maybe they didn’t follow the methodology’s directions. They had failed to successfully complete a well-described process that should lead to a predictable result. Those developers are to blame!
So, I encourage you to read a brief summary of why I think your Manager is not God and the only thing you can trust is working software that the team can DEMO.
Don't Get Attached to What You Know
Software development is like new product development, not manufacturing. The assumption that software is manufactured and that it therefore should follow similar processes to manufacturing is incorrect. Manufacturing is assembling the same model of something (radio, TV, toaster) over and over again. Software is about creating something new because – even if reusable parts are used – the configuration or arrangement of them will be new. Creating something new requires research, creativity, and learning. Research and creative activities are much less predictable. Because software requirements are never specified identically or even completely, software development always involves research.
Expect the Unexpected
The empirical model of management expects the unexpected. It provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. Less time is spent trying to plan and define tasks, and more time is spent with the project team understanding what is happening and empirically responding.
Complex Work
Scrum starts with the tenet that very few activities in system development projects are identical and will generate identical outputs. If the process cannot be described in enough detail to be repeated, if there is so much complexity that any attempt to model the process results in different outcomes, the process is a complex process. If I operate a complex process two times in a row, the results are more likely to be different than the same. Even the same person won’t generate the same outputs two times in a row. The activities in the process and their output cannot be predicted with an adequate degree of reliability. Empirical process control models are used to manage and control complex processes. Management and control are exercised through frequent inspection and adaptive response.
Focus on Possibilities
Scrum is the art of the possible. Scrum instructs teams not to dwell on what can’t be done but to think about what can be done. Every time managers hear the word “Impediments”, they should think “Opportunity”. It is important to focus on what can be done and how the problem can be solved with the available resources and encourage the team to have done the best that it could rather than sitting around and doing nothing. The Scrum Master is responsible for making decisions immediately, even with incomplete information. It’s usually better to proceed with some decision than no decision.
Inescapable and Constant Change
Requirements never stop changing, so it makes little sense to pretend that this is not the case and attempt to set requirements in stone for the beginning of an iteration, or Sprint, of incremental development of the product. Unanticipated work is often discovered and uncovered by the team and by the users themselves as they build the product increment. Then, the team is responsible for creating new backlog items for this work and estimating the work to complete each of them.
Focus on the Goal
Producing a valuable product increment out of somewhat vague requirements and unstable technology is hard work. For the product owner to succeed, everyone in the organization has to respect his or her decisions. No one is allowed to tell the Scrum Team to not respect his or her decision. No one is allowed to tell the Scrum Team to work for a different set of priorities, and Scrum Team aren’t allowed to listen to anyone who says otherwise. Why? Because it’s the Product Owner who sets up the goals and leads towards their realization. He is the captain on the ship towards the product vision. So if you have doubts about the product development line, this is the first and main person to talk about it.
Estimation's Indication
The Product Backlog estimate is not binding on the Scrum Team. The estimate does not mean “this is how much time there is to build this functionality, and no more”. The estimate is a starting point, a best guess, from which the Sprint can be empirically constructed and managed. The Team modifies Sprint Backlog throughout the Sprint. As it gets into individual tasks, it may find out that more or fewer tasks are needed, or that a given task will take more or less time than had been expected. Teams become better at Sprint Planning after the third or fourth Sprint. At first, a team tends to be nervous about taking on responsibility and it under-commits. As it becomes more familiar with the Scrum process, as it starts to understand the functionality and technology, and as it gets into a team, it commits to more work. Then the Scrum Team commits to turn a selected set of Product Backlog into a working product.
Productivity
The Scrum Team meets daily for a 15-minute meeting called the Daily Scrum. During the meeting, the team explains what it has accomplished since the last meeting, what it is going to do before the next meeting, and what obstacles are in its way. It’s all about improving the level of project knowledge. Anyone who needs to know what’s going on with the project can come to the Daily Scrum and listen. The Scrum Master’s job is to increase the productivity of the team in any way possible and to make sure that productivity remains as high as possible. Their main duty is to find ways to help the team be more productive, both as a group of individuals and as a cohesive team. So, during Scrum Events, silence is always a bad sign. Software development is a complex process that requires lots of communication. Highlighting the help that anybody may need is an art of getting things done.
Feedback
Feedback does not mean testing your software product. Feedback is the transmission of evaluative or corrective information about an action, event, or process to the original or controlling source. That's why you should inspect the creation of your product as soon as possible, and that's why, during Sprint Review, everyone visualizes the demonstrated product functionality working in the customer or user environment. As this is visualized, consider what functionality might be added in the next Sprint. No one should prepare extensively for the meeting. In order to enforce this rule, PowerPoint presentations are forbidden.
(True) Transparency
Scrum always tells the truth about everyone because it provides transparency at every step. You can see the assumptions for work, you can see the performance of your team, you can see the progress of the work, you can see the work done in a systematic and structured, yet simple way. There are no sophisticated processes, only a maximum of 30 days of Sprint, and you can change your mind at any time. If you disagree with actions that the Scrum Master takes guiding the team and facilitating the process, you should offer suggestions and guide so that the software implementation can be tailored to your needs and preferences.
In summary, projects are complex, unpredictable affairs, and management should always expect the unexpected. That's why the people inspecting the process expect this unexpected situation, monitor it, and adapt as needed. Besides, Scrum Team members don’t have job descriptions other than doing the best possible. No titles, no exceptions. It's not the titling that matters, but working productively. To do it, your IT team needs clear goals, a decisive Product Owner, and your frequent feedback. It's as simple as that.
If you are interested in this topic, I encourage you to read the books: Ken Schwaber and Mike Beedle Agile Software Development with Scrum”.
Source of graphics: www.pexels.com.
