Last spring, I started a new role at my organization when I was asked to become the Development Manager for a team called the Tools Team. This was an exciting milestone of my career, but was bittersweet as well, since taking the new role required me to leave an Agile team that was successfully producing at the performing adoption stage.
I was thrilled at the opportunity to lead a team that consisted of true thought-leaders who are not only known entities at my employer but within the industry as well. In most corporations, my team would represent enterprise architecture, but there is a longer story regarding why that is not the case at my current employer, so let's just stick with referring to the team as the Tools Team.
The Focus of the Team
The primary focus of the team is to provide technology guidance and leadership to the nearly twenty Agile teams that make up Software Engineering at our corporation. Our primary areas of focus are:
Communicating patterns and practices.
Fostering the ability to work smarter, not harder.
Since our team has formed, we have delivered some exciting functionality to our customers. Some of my favorites include:
A security jar that can be pulled from our local Nexus server to simply the security process.
Starter application framework for microservices-based upon the Spring Cloud and Netflix OSS framework.
Common UI component library for ReactJS applications.
A tool to establish a smaller data set for testing purposes, avoiding the need to use a full (and bloated) copy of a production database.
A series of shared microservices to handle things like currency translation to user-based services.
It has been an exciting period for our team and it is a neat experience providing tooling and services for other developers.
Choosing the Right Agile Methodology
Initially, the team was asked to follow the lead of the other software teams at our corporation and utilize Scrum as our Agile management and control process. This wasn't a stretch for me since my prior team was using Scrum and it was working out quite well for us.
However, we soon realized that it was difficult to plan our Sprints since our customer's needs weren't always known prior to a given sprint starting. As a result, planned stories would carry over into the next Sprint and new stories would find their way into our current Sprints after they had started. While we were successful at completing several stories, using Scrum just didn't feel right.
We soon realized that similar teams in our industry had opted to use Kanban instead of Sprints. While our organization was looking into SAFe, I discovered the V3 Scaled Agile Framework site suggested using Kanban for architectural epics, which falls right into our needs.
We made the decision several weeks ago now and the results have been quite positive.
Team members follow the WIP limit and focus on completing a given task without a time-based boundary.
The backlog consistently reflects the next set of priorities to work on as items are completed.
We have the ability to place items On Hold when unexpected tasks require immediate action.
Trying to use Scrum and sprints for the Tools Team was similar to trying to get a round peg to fit into a square hole. With enough force, it would fit, but it wasn't the best fit. Changing over to Kanban was a much better fit and was easily justified by a number of online resources that we were able to find.
For reporting purposes, we continue to maintain a Scrum board behind the scenes and track the work in two-week Sprint cycles to report back to management, but from the team's perspective, they are functioning in a Kanban world and loving it.
I am interested to hear about the experiences other enterprise architecture and tooling groups have encountered with respect to software development.