When I first started as a ScrumMaster with my current employer, the team was excited about the concept of rapid and quick development cycles that would provide incremental value to our customers in short development sprints. Although some members of the team were a bit hesitant to follow the Agile ceremonies and related meetings, by and large the team was well on board with our Agile Scrum framework. Within a month after my joining the company, we merged with another company and our management changed. The new management team was more inclined to use formal project management practices and tools to manage their projects. But the good news was that the SVP of technology was open to change and gave our team some space to do what we were doing until he had all the data points to make the appropriate changes.
As the team continued with its Agile development, engineering teams around the company began to take notice of the work we were doing and thus embarked on an Agile journey that began to scale beyond our team. The hardware engineering teams were forming small teams to handle their projects, which were often more complex due to external dependencies with onshore and offshore contractors and related external constraints. One of the primary stakeholders in our engagement was the product management team. The SVP of product management was a big supporter of PMP-based project management and put in place a stage-gate-driven process to handle projects right from inception all the way to completion. So Agile development was seen as a short-lived venture that would be phased out pretty soon.
As we ventured into the land of uncertainty, the question of Waterfall versus Agile occasionally crept up. Soon, some developers began to complain about the Agile method. I often had to deal with questions or comments, such as:
- It seems childish to have to report to a room and stand there for 15 minutes sharing what we did and what we plan to do.
- Agile stinks at tracking interdependencies, which are better managed through a well-defined project plan.
- Agile iterations never give us a finished product, and we are unable to meet customer commitments, which are date driven as opposed to following our iterative style of development.
- With our move from JIRA to Team Foundation Server (TFS), our tool set does not fully support the Agile framework.
- Agile iterations do not work well with the stage-gate process that project management follows.
- Our estimates should be time driven instead of going by velocity points, since we work with customer’s timelines.
What many saw as conflict looked more like an opportunity to work closely together, educate the team on what Agile means, and meet our commitments. From my team’s perspective, the Waterfall-based approach followed by product management did not conflict with our Agile approach. The Waterfall approach focused on the what
you should do on a project; communication with stakeholders, customers, and related milestones are set at the beginning of the project. In other words, we applied PMP principles to initiate and plan what will be executed in the Scrum.
On the other hand, Scrum applied more to IT application development, or the how
you should create software. This was carried out over two-week sprints and progress was tracked like any other project. Monitoring and controlling of scope, risk, cost, etc., and closing-out the project were managed using PMP principles.
Some tactical steps we took:
- We used tools such as Confluence to build out a project dashboard. This served as a communication tool for the stakeholders to get the current status on features and key project milestones. Internal meetings like retrospectives, sprint planning, and related Scrum meeting artifacts were uploaded to the project dashboard. The dashboard also served as a traceability matrix for our feature requests.
- We used TFS to set up the backlog and create and manage two-week sprints.
- We met with stakeholders once a week as part of the weekly status updates and used this forum to actively engage with impediments, risks, and issues requiring quick resolution.
- We assigned confidence levels for our stories based on the maturity of the analysis and clarity of the features being requested. The higher the confidence level, the higher the likelihood of the feature being implemented.
- We used Skype and Office 365 to record and share quick five-minute videos around the features that were being developed.
- Product demos, although initially very effective, were replaced by video recordings in order to get early, regular feedback.
- We used a combination of virtual and in-person stand-up sessions to work with our onshore and offshore teams.
- Our retrospectives involved some really tough discussion points. We took these meetings seriously and made changes based on recommendations coming out of them.
- We took the organizational culture into account while tweaking our engagement model to consider multiple stakeholder inputs.
- We broke up our teams into smaller sub-teams meeting daily, coupled with a Scrum of Scrums meeting to get the entire team together.
- We used tools, such as Life Map, team lunches, and team outings, to create a positive and engaging team culture based on trust and friendship.
- I combined a personal trip with a trip to our offshore team, spending a week working with them in person. I was able to use this time to not only build good relationships but to also get to know the team better.
- By integrating our custom development efforts into our daily sprints, we were able to better align our product development cycles with our customer commitments.
Breakdowns in the Scrum model
We dedicated a couple of weeks of end-to-end regression testing before releasing our software to customers. The Scrum practices we used during the development cycle became less effective as we got more into bug resolution. Unlike stories that can be planned at the beginning of the sprint, bug resolution was always a moving target, and it proved really difficult to plan on a sprint-by-sprint basis unless we refreshed our priority daily. As a result, the daily stand-up moved to a bug-triage meeting.
On another occasion, our product manager called an “out of bounds” meeting since an important government customer who used our application experienced issues with a high volume of records. This was a line item in the product requirements document that the team completely missed. We spent a couple of additional sprints getting the technical debt under control.
At the end of the day, we saw that the organizational culture and leadership mindset played a critical role in the success of any project. The method needs to be tailored to work in the context of the organization. Our organization, as a whole, is not fully geared to be Agile. It’s not as bureaucratic as some government agencies we deal with; at the same time, it is not as flexible and nimble as a start-up technology company, either. It is somewhere in between, leaning slightly more to the start-up tech side. Hence, our approach needs to be blended to engage in the best of both the Waterfall and Agile worlds. The project management discipline provided the overarching structure or the framework that allowed the application development (Scrum) process to operate and thrive.
Extracting meaning from Scrum
Over the course of working with the team for the past two-and-a-half years, my role has evolved from being a ScrumMaster to a coach and mentor to the team. My title has also changed from ScrumMaster to program manager. More than the change of title, it’s the evolution of the team and the change in dynamics that counts. We are now a strongly knit development and testing team. We regularly meet our sprint commitments. That translates into meeting project milestones, meeting customer’s expectations, and building a culture of trust and integrity.
Recently, my management team has added another offshore team and a mobile application development team to the portfolio of projects I manage.
On a personal level, I have now implemented a diluted form of Agile/Scrum on the family front. We are in the initial stages of building a Scrum-based approach to our family. Interestingly enough, the younger members of my family team have taken this on pretty well; it’s the older members who are struggling. But again, as in my early ScrumMaster days, although the resistance meter is pretty high, I am in the process of supporting our family’s Scrum success!
The Scrum story continues; it’s just a different team and different turf, but the rules of the game don't change. They simply get reinforced and stronger every time we play.
Got to run. It’s time for my next sprint planning!