Ours was a typical Waterfall team that believed to the core in the SDLC (systems development life cycle). Our requesters were always adamant about sending countless changes to us at all stages of the project flow. This led to a lot of rework, a decrease in customer satisfaction, an increase in the number of bugs, and other problems.
Hence our leadership thought of bringing in a new methodology, which had proven fruitful when it had been applied a few years earlier in another location: Agile. As the name suggests, the whole framework is flexible. Our group started off as the pilot project, and we finally implemented Agile in the entire service line.
However, our team faced numerous stumbling blocks while we were attempting to adopt Agile. I'll focus below on the most prominent ones:
We're performing so well, we thought. Why would we change? Why are we giving liberty to the client to change the scope at any time? How will the projects be completed?
To be honest, it is very difficult to tame the inertia of a team. We ran several rounds of meetings to educate the team about the Agile (specifically, the Scrum) framework.
2. Lack of discipline
Discipline is the core of Scrum. We all needed to be on time for all meetings, and we soon found that this was a problem. So we set up a "Softy meter," which meant that whoever was late for a meeting (without advance notice) would have to bring Softy ice creams for the entire team. This was advantageous: We enjoyed a lot of Softies in the initial phase, and gradually the Softies were abolished as there were no more latecomers.
We also faced a problem in not timeboxing the meetings. Our stand-ups lasted for as long as 30 minutes, as parallel discussions erupted and diverted the agenda. Eventually the ScrumMaster learned to intervene so that the team followed Scrum stand-up practices.
3. Learning responsibilities
An Agile team is self-organizing team, motivated enough to work for a common goal for the company. However, during the initial adoption period, we realized people were not aware enough about their roles. A product owner should focus on achieving the client's business piece of the project. A ScrumMaster should act as a facilitator to help in removing the impediments. The team should be self-organizing and have the liberty to size the stories, pull them individually, and assign them in the product backlog of the sprint.
4. Learning the prerequisites
The product owner and the ScrumMaster should not be the same person, nor should either be the direct reporting manager of teammates. A product owner needs to be a single person, not a committee. Both of PO and ScrumMaster should be dedicated 100 percent to the project. In case someone must work on multiple projects, he or she needs to draw the line to protect each individual project and team so that they're always taken care of.
5. Expectation setting
The expectations of the client need to be set wisely. That is, if the client is finicky about the budget, then we should communicate clearly to him or her that we will give a daily, approximate cost estimate. However, if there is a nonnegotiable cost, we will clarify that we'll forward the product in its current state to the client once that cost is reached.
6. Learning empiricism
Scrum is empirical in nature. Never make it too calculated or mathematical, or you'll destroy its core purpose. For example, always draw a rough burn-down chart to keep it simple and meaningful. If we make it too "accurate," using rules and scales, we end up wasting a lot of time and missing the real work.
Sizing the story is another example. Never size a story for the estimated time involved; sizing is a measure of the complexity of the task. The size shouldn't depend on whether a senior developer takes it or a junior developer takes it. Sizing should also be relative, meaning that stories should be sized relative to each other.
Finally, the ìDefinition of Doneî needs to be set. Acceptance criteria needs to be outlined so we can judge if a particular story is done or not.
7. Possible need for customizations
Agile hates people working on multiple projects simultaneously. If a PO doesn't have the needed bandwidth, then a proxy PO must be set up to fill that vacancy.
A few companies don't have ScrumMasters and so the PO handles the dual roles of being the "clientís person" and the "teamís person" (ScrumMaster). This leads to internal conflicts, as those roles need distinct people. Sometimes a person acting as PO for one project is ScrumMaster for another project, which can work well as long as schedules are respected.
Our team today
Now we are a purely Agile team. Truthfully, the transformation from Waterfall to Agile practices was extremely difficult. It took us several pilots; extra hours; weekend trainings; regular and ongoing coaching; and learning to deal with ego clashes, inertia conflicts, and more. But today we are a happy Agile team. Scrum, sprints, retros, review meetings, discipline — they're all now part of our DNA.