Many development teams implement scrum and call themselves “agile” when in reality their process is not working for them. The principles of agile are sound and make sense, but the many permutations of agile implementations don’t work for everyone. Over the past year, my team has continuously iterated on our development process to improve the efficiency in which we build products and the quality in which those products are released. By shelving existing agile implementations and building our own hybrid version from scratch, we were able to create a development process that worked for us.
Here at CBRE Build, each product team has the autonomy to figure out what processes work best for them. Rather than adhere to any one agile framework, we try to keep the principles of the agile manifesto in mind as we define these processes. We learn what’s out there and create a healthy mix of traditional agile ceremonies and project management concepts that keeps us efficient and aligned towards our goals.
The original principles behind the agile manifesto are all about delivering products quickly, adapting to changing requirements, and communicating effectively both within teams and to external stakeholders. Most importantly, the twelfth principle states:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This essential principle is often forgotten by teams that blindly adhere to the implementation details of a particular agile framework. Too frequently teams forget to be retrospective about their own agile process. My team, which is responsible for the spacer product, attempts to rectify this by observing our own workflows and seeking improvement by:
We find that the best quarterly retrospectives happen over a delicious brunch.
By following these steps and always keeping our agile goals in mind, my team has been able to continually improve multiple areas in our workflow. We realized our standup meetings weren’t helpful to us, so we eliminated them. We wanted more insight into engineer work progress, so we added engineering demos to our schedule. We saw that engineering tickets were held up for too long in the code review pipeline, so we streamlined the process to increase efficiency and decrease strain on our engineers.
After much iteration, we’ve reached a process that pulls heavily from kanban while sprinkling in some scrum ideas as well as ideas of our own. We use a kanban board to manage tasks and work without sprints. We have quarterly retrospectives but aren’t afraid to grab a room when we need to iron out some kinks, and we meet once every two weeks to assess our progress towards quarterly goals. It’s a healthy mix of light structure that works for us and was born from applying agile principles to our development process itself.
Now in Q1 2019, our new processes have enabled us to easily meet our goals and deliver quality products on time.
Our team is working better than it ever has, and we continue to improve. Sometimes our attempts to fix things don’t always work out, but with our system in place, we are able to reflect at the end of the quarter, eliminate the pain point, and try something new. Being agile is about communicating, adapting, and iterating, and we pride ourselves in applying these guiding principles to both our products and our product development processes.
Joe Forzano is a Tech Lead Manager at CBRE Build with a passion for processes that make sense. When not combing through engineering workflows with a fine-toothed comb, he co-leads the CBRE Build Diversity and Inclusion committee and chairs the tri-state chapter of the LGBTQ&A employee resource group, so he really loves all things queer. He is also the manager of the esteemed @puzzledesk instagram, chronicling all puzzles assembled at CBRE Build.