|#Scrum #Agile #Iterative development|
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.|
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.
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.
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.
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.
|At this moment we’re still in the process of mastering our agile way experimenting with the latest trends and emerging practises. This page will be constantly updated as we progress and have more considerations to share.|
|SEO checklist for website migration...|
|MySQL parameters matter...|
|Using virtual teams for outsourcing...|
PLEASE GET IN TOUCH WITH US!
|EMAIL: [email protected] |
TEL (London, UK): +44 20 3769 2817
TEL (New York, USA): +1 347 630 9717
TEL (Manila, Philippines): +63 2 231 2519