If you came up with the choice of software development methodology, then you have already seen our article about the comparison of the Waterfall and Agile models. It's about time to move on and dive into the details! Today we’ll let you know about the difficulties of working in a one of Agile techniques – Scrum. Building equally effective processes in each iteration can be tricky, while screwing up the whole thing is a breeze.
What’s Up with Scrum?
Scrum is a project management method, allowing creating and adapting the product to the changing market conditions through the fixed short time iterations. To accomplish the task list within the one iteration, the team selects the fixed time interval from 1 to 4 weeks called sprint.
Each day of the sprint includes meetings – short talk-ins timeboxed to no more than 15 minutes. During the meeting, each team member reports the work performed since the last briefing and his plans on the period until the next talk-in. Meetings are designed to keep all the team members in the loop on project’s progress and make adjustments on the go.
To determine the relevant scope of tasks, each sprint uses the backlogs - the daily planners of general use, so to say. There are two types of backlogs:
And here we are with the basic Scrum roles.
The product owner is the voice of the both end user and stakeholder. He or she understands how the finished product should look and work. The product owner sets priorities and sits on the sidelines not being the actual part of the team.
The scrum master’s role is to comply with the principles of correct work in Scrum. Master holds meetings, deals with controversies, distracting influences and helps the team to get on board with the Scrum philosophy.
The development team includes coders, testers, analysts and other specialists depending on the project. The perfect volume of cross-functional team is 7 people, give or take 2. The team is responsible for the results as a whole, and no other role may interfere with the development process during the entire sprint.
Rocket Men
Many projects in Scrum start like a rocket - quickly and with a good zest. Then the team starts to slow down, the tasks pile up, iterations turn into a useless chitchat. In this situation, it’s easier to abandon the Scrum once and for all.
Let's figure out why the work in Scrum falls apart, and how can we avoid it.
At the beginning, you have a small code base. Adding new features, making alterations and keeping it neat and beautiful is not difficult. However, the longer the code becomes, the more struggle it takes to maintain its quality at the proper level. Developers slow down under the weight of poorly written system. Efficiency disappears somewhere; the team is heading straight into the chaos that killed many ambitious projects.
And the fact is that for a smart work under the chosen method the developers have to do just two things, but at the same time:
But why should the coders be interested in that? Each team might take in a few individuals, habitually programming in a slapdash manner, without thinking of clarity and conciseness. The principle of fast and shoddily programming works at first somehow, but then the whole build goes down in flames. So how should we award the team for the beautiful code and fast delivery of the working functional?
Motivate people with achievements, using the gamification in work process. And as soon as game accomplishments are frequently connected to ratings, we’ll need numbers.
Let's measure the development speed and purity. If the team works in a good pace, but piles up unnecessary lines of code, it doesn’t get any goodies. If the code base is in order, but the development struggles, no reward either. And when the team works quickly and in tune, it is appreciated!
We can measure the "code chaos" using the test-driven development (TDD).
Accountants, double entry bookkeeping and TDD
Any code base, even the crystal clean, is chaotic without tests. Here’s an example from the accounting. As the accountant makes a mistake in calculations, the developer fails the code. Therefore, the accountants check everything twice and avoid misenter.
They use the double entry bookkeeping. It is a recording of each operation at least once on the side of the debit and once on the credit side. These values are calculated in its own way, but the difference between two numbers as a result should be zero. Accountants surely disqualify any recording without the double entry.
The test-driven development (TDD) is an analogue of double entry bookkeeping in programming. If your team is using the TDD practice, you’ll find what to measure:
Okay, so what should we do with all these measurements? Let’s make a graph, draw a colorful infographic with metrics and hang some motivating huge posters on the walls of kitchen, every office and even in lobby!
Celebrate the meetings of your objectives with fun parties and inspire your teams with pleasant and personal things. Show your people that they have goals to try hard for; their own success means general project success and the productivity will be noticed and rewarded!
As you can see, work in Scrum is not as simple as we would like to think. And one of the greatest nuances here, as in any other development methodology, is the human factor. Remember that any effective (in word) method fails in the real world without a proper team management, close relationship between the development and testing and, of course, the clear concise code.
qa.webmart 
+375 (29) 740-06-29