Agile Practices: Burwood's Story

Burwood-Group-180312-4599.jpg

In last week’s post, we discussed the history of Agile, its core tenets, and why Burwood Group adopted it. This week, we’ll dive deeper into the specifics of how we implemented Agile practices, what’s been working well for us, and where we’re going next in this ever-evolving space.

Relatively new group at Burwood, our DevOps group has grown over the last couple of years from one small team to a larger group of four distinct teams. In order to effectively manage the workload of the team at this larger scale, and to ensure that we can stay true to our commitment to our customers and internal stakeholders, we needed to invest in building a foundational approach to work management that would scale with the group; this was Agile.

Several of our team members had practiced Agile at other organizations and “having seen the light” will never go back to waterfall approaches (where projects are completed in distinct stages and moved step by step toward ultimate release) to managing projects and software development. These team members were our champions, advocating for the adoption of Agile across the business.

Selecting an Agile methodology: Finding our sweet spot

There are two primary methodologies considered for Agile, although they are not the only two methodologies available: Scrum or Kanban. Scrum is a well-defined process framework to structure work performed in projects. Typically, work is performed by smaller groups called sprints, which incorporate shorter durations for task completion to make a project more flexible and adaptable to change. Kanban is a visual way to manage workflow where the process is placed on a Kanban board (think “billboard”) and the work is organized into columns. Typical workflow tasks include testing, ready for release, and released columns.

Burwood’s Cloud Services team found the sweet spot between maintaining focus on a certain set of deliverables for a period, while remaining responsive to urgent customer and internal needs. Typical Scrum sprints of 2-4 weeks were too long for us, and Kanban wouldn’t provide us the regular release and feedback cycle that we wanted, so we settled on Scrum with one-week sprints.

Engaging our stakeholders

We started our transformation with leadership and internal stakeholder buy-in, which included educating and advocating the benefits of Agile. We needed this understanding and advocacy to trickle down through the entire organization so that everyone would understand why we would no longer be able to “drop everything” and work on a new urgent priority on any given day, and why our calendars would be blocked out certain days for development work (utilizing the concept of flow / uninterrupted work time).

The four ceremonies of Scrum

Next, we identified key Agile roles such as the Product Owner and Scrum Master, and set up a regular weekly cadence for the Four Ceremonies of Scrum:

1.  Sprint Planning: A team planning meeting that determines what to complete in the coming sprint.

2. Daily Standup: A 15-minute mini-meeting for the team to sync internally, on three questions:

  • What did I work on yesterday?

  • What am I planning on working on today?

  • Am I facing any obstacles?

3.  Sprint Review and Demo: A sharing meeting where the team shows what they've shipped in that sprint, receiving feedback from stakeholders.

4.  Retrospective: A review of what did and didn't go well with actions to make the next sprint better.

Tools selection to support an agile ecosystem

Lastly, we set up the tools to support the Agile process, which included key aspects, such as user stories, sprints, and Agile boards, where work can be easily tracked while it flows from backlog through to completion and release.

As an operational team, we were already very mature with ServiceNow, using it for all IT Service Management (ITSM) and IT Operations Management (ITOM) work. So the adoption of ServiceNow’s Agile module for all our Agile development and projects allowed us to customize the deployment to meet our needs. Having all our work in one system meant that everyone across Burwood could create, track, and provide feedback on requests and user stories.

Summary: Why we chose Agile

  • We want to be responsive to changing requirements and priorities

  • We are collaborative, especially with our customers

  • We have small, cross-functional teams

  • We are transparent and want to provide visibility to stakeholders

  • We strive for a happy team and elated customers

  • With previous Agile experience, we’ve seen the light and wouldn’t go back to other methods

We love sharing our experience with implementing Agile methodologies. Please reach out to learn more.


April 8, 2019