How to Break the Rules of Scrum to Achieve Operational Agility
5 Thoughts on Theory vs. Practice
According to the 2011 CHAOS Manifesto from the Standish Group, Agile projects are three times more successful than Waterfall projects. But what happens if you try to break the rules of agile software development as well? See how we do it in PIXERS.
Thought #1
Building a Bridge — What is Project Management at All?
Managing the IT projects is a subject of many discussions, analyses and publications. In fact, I should rather say, “implementing the IT projects”, because the managing is merely a small part of the teamwork. It’s commonly considered that the success of any project depends on the quality of the management, but this way of thinking is analogous with a statement that a construction manager is able to build a beautiful and solid house only if he directs the works properly.
“Software development may seem to have a lot in common with construction or engineering projects, such as building a bridge. A set of activities must be carried out in what seems to be a natural order: requirements gathering, design, building, testing, and finally putting the bridge into general service. From then on, the bridge goes into operation and maintenance. For software, the usual activities are recast as requirements analysis, architecture, design, code and unit test, integration, and system test.” — Murray Cantor, “Software Leadership: A Guide to Successful Software Development”
The truth is that a good project includes management and the work of every single person in the team: each individual (programmer, tester, graphic designer, analyst, scrum master, product owner, etc.) and all them together as a team, with in the entire crucible of inner relationships between them. The key question that comes to mind of every project manager (not only the IT one) is how to best and most efficiently provide the customer (the external and the internal one) what she/he needs? One of the techniques is the scrum method of managing.
Thought #2
Waterfall — How It Came to Be as It Is Now?
Several years ago, everything seemed easy. One had a project to complete and in order to realize it was indispensable to gather and analyse necessities, write a specification, divide tasks, realize them, test, implement and supervise. Such a waterfall model was promoted at the technical universities and performed in companies. The analysis phase was the first step, followed by a phase of specification, implementation, testing and so on. It sounds good and looks reasonably clear in diagrams. However, the problem is that it not always works. Even worse, it often doesn’t work at all. The effects are classic for the IT industry, and this fact is well illustrated in the picture below:
Projects exceed the established budget and deadline, and the implemented result is often far from what the customer expected.
Why does it happen? First of all, because it’s difficult at the start to foresee what the final result should be. It’s very difficult to imagine exactly what you want your target system to look like at the end. As a result, the necessities are evolving as the project progresses: during this time the developers’ and client’s frustration grows bigger and bigger (because part of the source code is a dead loss and because the client must pay for additional changes beyond the budget), and in the end both parties are dissatisfied.
Likewise, it is impossible to estimate the real time and costs of developing a system that is executed by the particular team for the first time. You can compare this to doing something for the first time — you never how long it will take to complete the task. Therefore, all the estimates while creating any software are inherently subject to a greater or lesser margin of error.
“Another potential danger is that you won’t know if the solution is successful until very close to launch, leaving little time and room for correction. Oversights and flawed design work can seriously affect your launch date. Other criticisms of this model include the fact that there’s no room for feedback anywhere in the process, except at the end of a phase. Also, there’s no room for changes once development has begun. Finally, if system testing shows that capacity or performance isn’t up to snuff, it may be impossible to correct.” — Shelley Doll, “Waterfall development for new managers”
Thought #3
Agility — A New Way of Managing IT Projects
Such situations have become so popular that at certain point, a group of wise people gathered their experience in order to change it. It was when the Manifesto for Agile Software Development came to life.
“That absolute alignment of purpose and trust is something that creates greatness.” ― Jeff Sutherland, “Scrum: The Art of Doing Twice the Work in Half the Time”
In short, we can say that agile methodologies emphasize the adaptive and iterative processes, rather than the “rigid” model of the waterfall. Adaptation means that it’s possible to adjust to the changes that inevitably advance over the course of the project. In other words — instead of stubbornly adhere to the “A” plan that prove to be impossible to realize after the first few weeks of work, try to work as effectively as possible to reach the anticipated goal, which is a working software, i.e. the one that meets the key business objectives set by a customer. It should also be realized in a fixed budget and time.
There are plenty of methodologies and techniques that are assigned to the group of agile ones — kanban, lean, TDD (test-driven development), FDD (feature-driven development), XP (extreme programming), scrum and many others.
Initially they were received quite cautiously, but with time they’ve become very popular, especially the scrum method. We can even say that there’s a certain fashion for agility nowadays — the fact, which carries some rather interesting collateral phenomena. For example, people who, a few years ago, I knew from running workshops firmly rooted in the realities of PMP (Project Management Professional) or Prince2, suddenly became advocates of agility. Even the Project Management Institute started certifying the agile techniques and now issues of readers and schoolbooks on the subject, runs courses etc. Moreover, in many corporations agile/scrum became an obligation and it was unthinkable just until recently.
Thought #4
Mistakes of Agile — Paper Tiger & Dogmatism (or DONE IS BETTER THAN PERFECT)
On the one hand, it sounds optimistic as you may think that, finally, something will begin to change in the rigid organisational structures of corporations. The reality doesn’t look so bright, though — the fact that the management of a company wants to boast about implementing agility unfortunately doesn’t mean that they really want to change anything. Usually, it’s just an attempt to show off without significantly modifying the process and structures. Full and effective entry into the world of agile software developing usually means changes in the whole organization. It cannot end up on the IT team, but should also include the management level — and often there is neither the time, nor the desire, nor the money to do so. The result is that the vast majority of companies that declare themselves to be agile, they are not. In such situations scrum is a paper scrum in reality, with just several rules implemented that in fact don’t change much.
Another extreme, which fortunately is less customary, is treating the scrum methodologies like a religion. Sometimes it manifests itself in a rather obvious and absolutely entertaining way, eg. if the time box for planning is set for two hours, the meeting is expected to take two hours, no less and no longer. Conversely, some other symptoms much more problematic — such as when members of a team focus on specific techniques instead of using them rationally, in order to achieve the agility. They become advocates of a “holy war”, quoting the Scrum Guide and declaring fight with business, to prove their point. They use tools and methods that they consider perfect, but whose use at some stage of the project is simply too expensive.
When you order a taxi, you would be very pleased if a limousine comes to pick you up. However, if you had to pay several times more for such ride, you would rather choose a regular car. It’s not the best, but it’s sufficient. You don’t need to do unit tests for the whole code — to begin with, you can do it for the key functionalities, and with time you can add other, as needed.
Thought #5
Breaking the Rules to Achieve Operational Agility
Team
This is exactly the way I understand agility and rules of scrum. We don’t have to stick to them literally all the time. Another example to prove the point: Scrum Guide defines the maximum size of the team as 9 people. In PIXERS, the IT team had 11 to 12 people and it worked perfectly. Should we have divided the team into smaller teams just because such a team size didn’t work elsewhere? I don’t think so — it just has to WORK. Currently, the IT team counts 17 people and it was split into smaller groups; nevertheless, we try to act as one team. Some of the meetings we do together, some separately — depending on the needs and purpose of the meeting. This model works much better than the more rigid division, which I experienced in one of the companies I previously worked for. Such division led an antagonism between the teams that formed a whole before and it was difficult to solve this impasse.
“Scrum embraces the fact that in product development, some level of variability is required in order to build something new.” ― Kenneth S. Rubin, “Essential Scrum: A Practical Guide to the Most Popular Agile Process”
Sprints
The unspoken rule of sprint goal is that it should determine in several sentences what is the key aim of sprint. What is expected product, that brings some business value.. In the Scrum Guide though we won’t find any tips what to do in a situation when a one part the system is developed by one part of the team, another part of the team corrects errors, and yet another performs administrative tasks. Trying to connect all of these activities in one common goal would be imprudent. In turn, the division into separate scrum teams is also pointless, because they would have to exchange from sprint to sprint — the division of roles changes. What seemed best to us in such a situation was to create a list of targets of each sprint — one that includes the most important topics from different areas — and it works in PIXERS.
Time Estimation
The eternal problem of IT projects is estimating how time-consuming they are.
- Dear programmer, how long it will take you to perform a function that will do for me this and that?
- I don’t really know, because I have never done such a function before (if I did, probably it could be used).
- But I have to say something to the customer and I can’t tell him the price after the project is finalized.
- I see… then, it will take more or less… 2 weeks.
Developer alone or with the help of colleagues tries estimating the working time most accurate, but we are often wrong. Interestingly, this is usually an underestimation of the time — so called, optimistic version. There are always many methods to solve a particular problem: story points, scrum poker, white elephant (for larger topics), etc. Even so, unfortunately, there’s no magic method that will give us the guarantee of the accuracy of our estimation.
I used the scrum poker in the previous company: the entire team sat down and, using the cards, presented their valuation until we got a consensus. The disadvantage of this method is its cost — because it requires the involvement of more people. Moreover, a large part of the team reluctantly accepted this technique because everyone had to evaluate users’ stories they had no idea about and they also knew that they wouldn’t work on them. Therefore, in PIXERS we adopted the easiest option. Developers are free to choose the tasks that will carry out (according to the priorities, competences etc.), and then they valuate the subjects they’ve chosen. What’s important is that they do this in the units of time (hours/days), except for abstract story points that then you still need to convert to time/money.
“Envision, create, and believe in your own universe, and the universe will form around you.” ― Tony Hsieh, “Delivering Happiness: A Path to Profits, Passion, and Purpose”
Don’t get me wrong. Story points, scrum poker, one-week sprints, common goals will certainly work in other teams. It’s the question of people’s different personalities and attitudes — and a team is exactly such a group of different personalities and skills. Therefore, there is no silver bullet, only one right operating methodology that works always and everywhere, regardless of the team and the work they have to perform.
Perhaps, the solutions I presented, for some experts, would equal heresy, because they significantly differ from the standard tips. Anyhow, for me, agility, flexibility, and the adaptation process should serve precisely this — the effectiveness and optimality of the work performed — and should allow to achieve the goals simultaneously with the satisfaction of both the IT team and the client.
