"Missing Roles in Scrum" and "Holistic Success of the Software Projects"

Recently I had a discussion with one of my colleagues over the definition of Agile Architect role. Scrum doesn’t have any room for such role. The whole idea behind that is – just by labeling a person with a role named Architect, the person doesn’t become Architect. Also architecture creation should be a collaborative effort instead of defined by just single person. That’s why by definition, any/all developers can contribute to shape the architecture of the application depending on their competency.

So the question is – why am I still talking about it? The answer lies in some scenarios I encountered while executing Scrum based projects where I felt the need of having a person with certain responsibilities and competency. In this blog, I am not just talking about the need of Agile Architects but also about some other roles which become very important for holistic success point of view.

Scenario 1 – To keep a tab on overall architecture and non-functional requirements

Developers love coding and many a times they start churning out code from day 1 itself. At the beginning of project, we all talk about non-functional requirements and overall architecture. All that can go for a toss if someone doesn’t keep a tab on it. The much abused KISS principle though looks great from the outset, it also provides you a crutch to believe that things like non-functional requirements will be taken into consideration at the end. So from code functionality point of view, though we continue to talk about Continuous Integration, non-functional requirements are kept to the end. And it backfires sometimes.

Sometimes the entire building you created (by just believing on ‘building bricks and refactoring’ instead of ‘building brick and constantly looking at overall objectives and architecture’) needs to be rebuilt again as even refactoring further makes no more sense for meeting business and non-functional objectives.

So though the project got executed as a whole but it becomes useless. Yet again you’ll say that customer never informed about some hidden non-functional requirements. But then as Agile software service provider (ASSP) it’s your responsibility to bring that out from the customer using brainstorming and multiple questions-answers sessions. In this context I see a need of a person who has a responsibility to look at overall building all the time and doesn’t compromise on end goals. This guy can be called Agile Architect.

Scenario 2 – Challenges of Product Owner Role

As working in Agile environment is a complete paradigm shift for anybody working in Waterfall model before, Agile adoption poses a similar kind of challenge for Product Owner role as it does for a developer role. However in case of Product Owner, the problems become much more visible as they impact overall project. Let’s take a look at some problems which you also might be able collate within your own project:

• No READY Sprint backlog in the Sprint planning meeting
• Not enough information in the user-stories.
• User stories too big to finish in one sprint.
• The project roadmap is not clearly defined. Team has no clear idea where does their current Sprint stand in whole roadmap.
• PO doesn’t have enough technical background to execute technical project, for instance building the backbone for importing data files.
• Similarly sometimes PO comes from a technical background and you miss entire business vision, thinking and farsightedness.

Sometimes these problems come because of paradigm shift from Waterfall to Agile and sometimes they might come even from experienced Agile organization too based on the PO’s capability. Irrespective of the reasons mentioned, most of the times, we say it’s the problem from PO end and customer should fix it. Sometimes, customer also doesn’t find any sure-shot solution to resolve it. Now one approach is – you continue the project as it is and as a result team continues to suffer. Projects may survive this problem but many times they don’t.

Agile software service provider (ASSP) can conveniently term it as a customer failure. But in that way we tend to forget that ASSP has a big stake in customer’s success or failure. It just doesn’t work if you just take the onus of success and put failure either under the wrap or attribute it as customer failure.

There is another approach to handle this situation. ASSP can send someone to help the product owner for figuring out some of the identified problems and in that way contribute towards project success. He doesn’t take the role of Product Owner but does assists him with Sprint planning, release planning, making user-stories READY for Sprint backlog. This guy should have techno functional background which is easier to come from ASSP side as most of the technical people grow towards management roles.

Scenario 3 – Program Management and not just Project Management

One of the best practice and to me a philosophy to learn from Agile world is continuous integration. It came into picture just because it was very difficult to integrate at the very end and things used to fall apart at the time of integration. So instead of integrating at the end we started doing it more frequently.

In many situations, multiple ASSPs are part of a big Program (cluster of multiple projects to achieve a set of goals) in which each vendor focuses on to finish their own work. As multiple project teams deliver output at different point of view, the end-to-end integration of multiple applications also becomes a big challenge.

In such situations, most of the times, ASSP just cares about the success of their own project. So it might happen that as an individual project, your project works but entire Program fails. Yet again, if you as ASSP recognize this problem early and you find yourself in a position to help out the customer, you should definitely do that. One of the solutions could be – having just one single ASSP for the entire program. However many a times, it also doesn’t work. Even if it works, Program management is still a challenge.

So far, I just listed one single problem from Program Management point of view but Program Management means a lot of other things to be managed from corporate governance point of view. So here I see a missing role that could assist the customer from entire program management point of view.