I was excited for the opportunity to be involved in leading our client’s Infrastructure team in their agile effort, which is what led me to the CST class. The manager had heard stories of the gains in productivity from teams on the Application Development side of their business' Technology Services, and wanted the same for his team. Both of us had a foundational understanding of Agile, but we would be the first team on the Infrastructure division side of the house to implement some form of Agile, so while we had plenty of experience to reflect upon from the AppDev side of the business, it quickly became obvious we weren’t really tapped into the cultural change that appears to be happening across the fence.
As part of our preparation I attended the Scrum Alliance Certified Master Training (CST), and having exposure to the agile happening around me, I can say that understanding Scrum is fairly straightforward. A Scrum Team consists of a Scrum Master, Product Owner, and the Development Team. The Product Owner uses a Backlog to collect, prioritize, and manage the team work. A Sprint is the duration of time, usually 2-4 weeks in length, where the Development Team devotes it’s time to accomplishing the work the team pulls from the Backlog.
To manage the Scrum, four different Ceremonies are injected into a sprint to plan the work (Sprint Planning), discuss what work is being done, or blocked (Daily Scrum), what was accomplished (Sprint Review), and how to do the whole process better (Sprint Retrospective). While the Product Owner owns the work in the Backlog, the Development Team decides on how to best get the work done, typically using a Kanban board to track its work in progress. And like all teams, there is a coach (a.k.a., Scrum Master) who acts in the interest of the Scrum Team to facilitate the process of being Agile.
At this point, the newly formed Scrum team has been through two Sprints, each lasting four weeks in duration. Out of the five individuals making up the Development Team, three have really embraced the spirit of Agile and have helped champion the process. Out of the two remaining members, the framework has shed a light on their inefficiencies; one having attempted to manage too many tasks on the plate at once, while the other had very little tasks at all. None of these observations were shocking to any of the team members, rather a continuation of the team dynamic prior to agile. As with most things in life, we were all bringing the good, and bad, to this effort.
In conclusion, the “agilization” of our client’s infrastructure team was really another exercise in change management, where the Lewis Fowler Organizational Change Management Project Lifecycle was key. Following this process allowed Lewis Fowler to quickly engage the client and drive awareness of the change, while also rapidly developing knowledge of the change, and demonstrating the new skills and behaviors to reinforce and drive the change to completion.