Categories

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: Inability to prioritize the architectural and design tasks – Part 2

In the previous post (Not putting design priority), I had talked about how a Scrum team can face challenges in terms of prioritizing the architecture and design tasks. In this post, I will continue my previous discussions and talk about how teams do actually place a lot of emphasis on the design part, and how this has to be driven by somebody.
I was recently talking to an engineering manager who was part of a team that was working on a product (or rather, the people in the Scrum team reported into the engineering manager). When I asked the same question, about how the team managed to ensure that they did not get into a situation where the design work was not planned for, the engineering manager was quite emphatic on this subject, that the team ensured that all the required architecture and design work was planned and the team ensured that in discussions with the Product Owner, these were incorporated into the Product Backlog and actually implemented as part of ongoing Sprints.
Sometimes, such an approach can be problematic. Part of the philosophy about Agile that I have heard often enough is the need to avoid doing unnecessary work. Sometimes, it does happen that the architecture work that is planned for the cycle is actually an overkill, and when the work is done, you realize later that the feature for which this architecture was planned and executed was not required. This can be painful, and when such a scenario occurs, there can be disagreements with the Product Owner. We had a case once before where we were supposed to be building a great new feature that dealt with the interaction between the client server application and an internet based client chat and forum system. This system was not in place earlier, and hence the entire application layer that dealt with integration of the API’s of the web application was integrated, so that in later cycles, the user interface would be built and tested. However, in a change of plan (caused due to new features integrated by an opponent), we dropped the internet based system integration and built in a new feature that was a core feature.
As a result, all the architecture work that we built in had to be dropped, and all the time that was spent in this work was also wasted. Also, there was no certainty that the work that was done would be used sometime in the future, since the feature may or may not be needed in the future. On the other hand, if we needed to put in the feature, it was necessary to make the architecture change in earlier Sprints, so that the software had the base built for the user interface feature. This was a ‘necessary evil’, and in the end, if the feature was needed to be done, the necessary architecture was required to be in place in advance. For most features that are big and require such architecture work, such planning is required.

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>