A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Engineering Practices Not Taken Care of by Scrum – Some details

Scrum never talks about engineering practices which is a good thing but this sometimes lands teams into trouble. The teams not only adopt the Scrum practices but also the principles which makes their progress sluggish and results in the code base being in a mess. This is a situation which is present in most of the cases where a failure has happened and the teams state that they have been implementing Scrum. Given that it is far easier to blame a process rather than do the necessary hard introspection, teams blame Scrum about not being able to provide engineering practices but they miss the entire point; Scrum is not about engineering practices, it’s about management. Engineering practices are whole and sole responsibility of the teams. Scrum only creates organized teams. They organize themselves, they organize their tools and they organize their engineering practices, and Scrum then opens up the entire process in terms of more information that teams have to learn to handle, and use to improve the way that they do things.
Consider some examples: The definition of Done (DoD) is defined by the development team. The criteria for done can be different for different teams; some teams might consider a piece done once the code has been reviewed others may consider is done only then functional tests are carried out and still others may call it done when the documentation is also done. It becomes necessary to keep an optimal level of done so that technical debt does not come into picture too much. And what is ‘technical debt’ ? Well, the concept of technical debt states that while adding a piece of functionality, two different approaches can be used. The first one is doing a quick job and the other one is a clean design. The quick design would mostly be messy, and one of the bigger problems is that making further changes become harder in future. So doing things in a quick and dirty way, results in technical debt which in turn requires extra effort to be put when future development is done. Doing a quick job is useful when you need to meet a deadline and can afford the extra effort later. However, you need to be sure that this is the approach you want to take, and not be surprised at the extra effort needed to be put in later.
The main difference between classical approach (Waterfall, etc) and scrum approach of development is that in scrum developers have more freedom to define level of done and amount of work to be done. They decide on the User stories to work in each of the sprint (through the estimation, although the priority comes from the Product Owner). Developers who do not use professional practices fail; but they fail independently of the processes used; blaming the processes of Scrum is convenient, but some inspection by external parties can easily reveal problems in the way that they do things.
There is sometimes a talk about too much quality being pumped into the product. Sometimes it may be a cause of concern for the owner if the team takes too much time for quality. The concept of iron triangle comes into picture here. This concepts states that Scope (features, functionalities etc.) , Resources (cost) and Schedule (time) can be considered to be three vertices of a triangle and Quality is the area enclosed by this triangle. Different groups have different priorities: users want more scope, senior management wants cut in time, financial team wants cut in budget and development team wants more quality. The end aim is to strike a balance into all the four entities. Scrum sets resources and time and lets developers decide the scope. Speed is scope/time and it’s a measure of output. If the product owner wants a higher velocity then he must work towards removing impediments; but dropping of engineering practices is not a solution. Compromise in quality is a slippery slope best avoided, and can result in so many problems later that any benefits from reducing quality are to be avoided. Consider advising a stuntman to drop safety equipment; he will never and so should be the case with developers (and even more so with the people responsible for the quality of the features and the product).

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>