Change is fundamental to life, it is said. Paradoxically, there is often resistance to change. Well, let me be more specific. I am sharing a few pointers coming out of early retrospection meetings during the transformation of a software development team from waterfall methodology to agile methodology.
There has been an industrywide move from waterfall to agile. Organizations – large or small – have been equally embracing this trend for the last few years. We also adopted agile some five years ago and have been sailing through well – I would say, very well, and are close to being called a mature team practicing scrum-based agile. There were a lot of apprehensions and doubts over the path we had taken and if we would ever transform successfully.
I had almost forgotten all that till it all came back to me again recently during an engagement with one of our clients. They decided to follow scrum-based agile, which was unusual for their waterfall conditioned team(s). The team was supported well through the agile workshop and an agile coach was assigned for an extended period of time. The team adapted well – and it gave them an opportunity to understand concerns, myths and reasons for resistance to change.
I have listed them here and added some perspective.
1. Daily reporting:
a. In a mix of junior and senior resources in a team, senior members sometimes are not comfortable with this exercise. From the agile point of view, each member should update others on what has been achieved regardless of the experience of the resources.
b. Some may see this as a waste of time. Why should anyone know about the progress made in areas not relevant to them? However, it must be noted that the scrum meeting is not for one person. The updates may not be relevant to everyone all the time, but some may find it useful. Also, it enables the team to be abreast of the overall progress and gives a preview of what is being achieved within a sprint. Thirdly, it provides an opportunity to understand the dependencies, impediments and potential risks so that the scrum master can be prepared with a mitigation plan.
2. I don’t see a big picture of the project:
By nature, agile goals of a project are met through smaller milestones that are achieved through smaller sprint size durations. A team member must discuss with the product owner or refer the available documentations to understand the project goal. The scrum master should also ensure that the team members are aware of the project goals and objectives.
3. Why are milestones spread over sprints?
This compares to the waterfall model. Isn’t each sprint a milestone in itself? Why is there a need to have milestones every few sprints? On closer examination, milestones are a good practice to focus on a set of related features/functionalities that can be achieved in a few sprints and released during production. This is a little different approach from releasing shippable features during production at the end of each sprint. Teams customize the releases based on what suits them best and milestone-based approach is a good measure of progress.
4. Running sprints like a mini-waterfall project:
It has been observed that stories taken for a specific sprint are sometimes carried over to the next sprint, and sometimes even spill to further sprints. This makes it look like a mini waterfall project. The problem lies in how the story has been sliced/created. To avoid this, the stories should be sized such that they can be completed within a sprint. Exceptions happen, and they should remain as exceptions. Spillovers should be contained within the next sprint.
5. Always running, but never reaching the destination:
This can happen when teams move from waterfall to agile. Every project has its objectives and deliverables. All deliverables have to be mapped to a deadline, which is a milestone. The work to be done to achieve the milestone should be broken down into tasks. During agile planning, the deliverables have to be in sight and tasks aligned to achieve the deliverables. High level of forward planning for each milestone and granular detailing for the work to be done in the next three sprints at any point in time are necessary for the successful completion of the milestone, and thereby, the project.
6. Components completed, but assembly failed:
Every successful sprint enables delivering as planned. Despite that, the milestone may not have been achieved. This typically happens when integration and regression testing for the components developed have not been planned for. Provide for integration and regression testing to meet each milestone.
7. Multi-team Sprints:
It is quite normal for multiple vendor and client teams to be part of a large sprint. All members of this agile team may follow a single plan, but there would be instances where this plan is at a higher level and each vendor and client team follows a ‘sub-sprint’ aligned to the larger sprint. For both the larger sprint and the ‘sub-sprints’ to be successful, identification of the dependencies much ahead of time is needed. A steering committee that oversees the larger plan and reviews it periodically can bring in the required checks and balances.
8. I do not get time for personal skill development:
A few members complained that they did not have time for skill development. I am fairly certain that agile never stops anyone from learning new technologies or pursuing certifications. It is just that it has to be planned and accounted for.
I believe you too may have experienced this, in parts, if not fully. Please feel free to add your comments and insights. Thank you for reading.
