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.

Problem in Scrum: Looking at technical debt, which will cause more problems as you move ahead ..

What is technical debt ? Well, I will not try and give a definition for technical debt. Instead, consider that you have 2 approaches to build some great new features. You can do something in a quick way without trying to build a great design, or you can build it the proper way through the required design. Now, if you need to get features done quickly, then trying to build in the proper design and architecture can stretch the possibility of getting the features done in time for the need (say, if the team is under pressure due to market requirements, or due to external stakeholder pressure). In such cases, it is a business need to build the feature done quickly enough, but one of the problems of taking such an approach is that you need to build a structure in order to build more and more features, and as you neglect the design work, building features becomes even more difficult. To put it in another way, in order to save some time in the beginning, you spend more time later. This is what is called technical debt.
In the case of the Scrum process, what I have seen in practice in many teams is the concept that because of the pressures, because of the way that the team seems to work from a Sprint to Sprint, the tendency to think about architectural change can slip by. The whole team is driven through a process whereby the Product Owner defines a set of features, prioritizes them, these are broken down into discrete tasks and estimated and then implemented by the team. There can be a lot of pressure to ensure that the teams are delivering a set of features on a regular basis; further, people are occupied on ensuring that all the features are delivered on time. It can get pretty difficult to insist that architectural tasks are delivered, since there can be a lot of resistance to putting these tasks into the Product Backlog. It would typically need somebody of the stature of an engineering manager to have those discussions with the Product Owner, to explain the need to put in the engineering time for putting in design for building for more features. It can be difficult at times, and in our case, it took us a few months and one round of feature failure to explain the engineering design process in detail to the Product Owner, and now we are in such a condition that the Product Owner totally understands when we push for some architecture work. However, it can take time for the Product Owner to be comfortable with these details.

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>