Published on: Mar13, 2019

Abstract

The Agile Project Management has been making a lot of positive noise in the Software Development industry in the last 5-7 years. No doubt, this still innovative approach helps overcoming a good number of issues related to limited flexibility and reluctance to accept changes attributed to “waterfall like” methodologies.

Based on internal experience and available skills, 2 years ago here in Rokitech we decided to use Scrum framework as the pillar for our iterative development. It’s very lightweight and it perfectly welcomes scope changes which projects’ stakeholders are known to generate during an entire lifecycle. So far, it has been meeting our expectations - it allowed our teams to communicate better and become more flexible addressing sudden needs of stakeholders.

But is it really that easy and straightforward to adopt the agile approach and start enjoying all benefits it delivers?

Yes, but …! There are a few important considerations which need to be taken into account while thinking about going agile.

In this article we’re not going to compare the agile methodologies with traditional frameworks, but we rather highlight the most essential observations we have encountered on our road to the iterative development.

Hourses for courses

Due to its nature of developing a product with its final qualities and attributes “as we go”, Scrum is very effective when it comes to accommodating changes (including those that no one has thought of prior to a current sprint). This perfectly fits into mechanics of the Software Development and into many projects we run in Rokitech.

Many, but not all… Unfortunately, Scrum cannot be used to manage all types of projects. There are still projects which from the very initiation require a substantial amount of planning to define a very detailed scope, and with serious consideration for budget/schedule/quality constraints. Typically, those project are not so flexible when it comes to accommodating changes - any proposed change has to go through the Change Control process as a result of which, such changes can be either accepted or rejected. In our case, most of such projects are IT Infrastructure related projects where requirements and milestones are clearly defined with not much room for deviations. The traditional waterfall approach is still our weapon of choice in those cases.

If your Company also has a similar separation of project types, then to address that, a formal selection of the most suitable development approach during a project initiating would be essential. And that selection decision needs to be taken by people with sufficient expert knowledge and experience (program managers, portfolio managers, head of PMO etc.).

Unexpected obstacle

To be able to successfully adopt a new framework in an Organization, you need to secure a support from key people involved in adoption and implementation activities. Company's Project Managers normally would be the group which participation and cooperation is needed in the first place. Usually they get excited about upcoming transition. However, at times instead of positive participation some PMs can be initially identified as resistant stakeholders requiring continuous engagement. Most of the time it may potentially apply to experienced PMs which have been managing projects for years in a traditional manner. They can be unwilling to change how they plan, estimate, communicate and manage documentation due to such a common attribute of a human's behavior as the resistance to change.

A combination of training, persuasive power, effective collaboration and forcing by a senior management was effectively utilized in Rokitech to overcome this slightly unexpected barrier.

Estimating challenges

Usually Scrum uses the story points to estimate activities duration instead of hours. And that is something which many inexperienced team members cannot initially get their heads around. In our case this estimating approach was one of the biggest challenges while working out the Scrum way. More than that, some team members were openly questioning the validity and effectiveness of the story points.

To overcome this obstacle it required some significant amount of mentoring and guidance by a Scrum Master in each team to develop the understanding and to master this approach within the teams. But it didn't take long for our teams to understand main concepts and to start enjoying this collaborative estimating technique - after 3-4 estimating sessions team member felt comfortable with the approach and were able to produce estimations efficiently.

Meetings time

Scrum promotes communications within teams. This framework adds up a number of mandatory meeting activities where majority of a team members needs to participate in. No doubt, that’s essential for the knowledge, information management, and for performance monitoring purposes. It greatly helps virtual teams to collaborate more efficiently. But that as well adds up a noticeable amount of time spent on meetings/communications in formal project’s work-breakdown reports. And that could be an issue for “time and material” contracts (which are very common for the service industry) where clients pay for work on the hourly rate model. I.e. the Project Managers know that additional (useful) communication is the key factor which can significantly improve projects’ performance and prevent various roadblocks, but some clients might consider it as an unnecessary cost from the financial perspective, and could be reluctant to pay for it.

There is no unified standard way to address this aspect, and every Organization would need to come up with their model of balancing this constraint out whether it includes educating clients, limiting meeting participants, or charging portion of communication expenses outside of a project account. And this might need involvement of an organizational senior management. However, from the Project Management perspective it’s important to remember that any meeting should always be well managed and time-boxed to avoid of long, unproductive “waste-of-time” meetings.

Procurement of services

Lastly, there is one more aspect which we haven't quite nailed yet Scrum wise. That involves outsourcing parts of a project to contracted organizations. While the main pillars of Scrum are: transparency, inspection and adoption, it's relatively difficult to impose these values with needed frequency on a contracted service/resource provider, especially if they do not work as per the Scrum framework.

The traditional procurement management and contracts administration still remain as the main principles being utilized to keep the outsourced work in line with the project's objectives.