January 02, 2017
This is part three of a series on how teams are organized and how they work together within this set of conventions and constraints. This post describes a team that creates software with members that work on multiple line items on the same projects within a fixed time period. It can be described as a group in a box unified by schedule. Over the last few posts, I have written about a team hierarchy that aligned with operations
and a federation team unified by process
. This “group in a box” team, like the others, is from my life experience in IT.
About the Team
This team is generating new software functionality and fixing defects that arise during development. The team has an overall plan organized by categories of needed functionality with the work planned and held together by collections of work tickets in a workflow application that offers different view of the work to be done. Over the years, many of us have seen diverse and imaginative use of ticketing applications and this is not exception.
The team uses an agile approach
to development of new functionality. The releases are developed within a pre-established time period or schedule often called a timebox
. Any line items that aren’t finished, tested and accepted within the timebox are moved to the next release.
What Works Well
Working at the “ticket level” is a good fit because the unit of work is often small in scope and not burdened by too many formal documentation requirements. Team members grab a ticket, do the necessary design and get inputs from colleagues as necessary, and code and unit test the solution.
The ticket system provides flexibility by allowing tickets to spawn new tickets as necessary. This could happen when working on a new function requires new capabilities of an existing legacy capability. The new ticket is a request to enhance a component so another new component can move forward. New tickets can also be generated as a way to track fixes needed to new functionality. In this way, it’s a dynamic and useful fix-tracking tool.
What Doesn’t Work So Well
One challenge is that it’s difficult for individuals outside the team to get up to speed on what’s happening with a release. There are often as many as 400 tickets for a given release so there are a lot of details floating around, tickets with tickets related to one another and just a few executive functions organizing them for the outside world.
Working this way—tickets as a unit of work—allows functions to be developed quickly but the process doesn’t leave a significant paper train for others to use to develop presentations, blogs, whitepapers, podcasts, videos, technical explorations and other needed elements to get the message out to existing and potential clients.
There are some challenges working inside and outside of agile teams. The teams move quickly but sometimes existing processes get in the way of productivity. Removing these obstacles requires working together with the goal of forming new processes that meet the needs of everyone. Communicating with customers and business owners can be another challenge that can be overcome by simply putting more focus on communication or communicating in new and innovate ways. Lastly, adapting to changes in business requirements can be a challenge while the team is in a timebox, so extra focus (e.g., exercising the requirements management discipline) is needed to minimize wasted effort.
In the next post, I will complete the series by examining the characteristics of teams that make them effective regardless of the way they are organized and carry out their work.
Posted January 02, 2017 | Permalink