Agile principles emphasize integrated functioning of teams to deliver value to business in short intervals. IT organizations, however, adopt these principles with varying degrees of rigor. While teams that focus on working in sync with other teams could achieve the true benefits of the Agile method, the teams that focus only on implementing Agile principles to turn around their work quickly would make a limited contribution to the overall success of the project and eventually to the business. This article explores a scenario in which teams implement Agile in silos, and it highlights the limitations of such a way of working and proposes an alternative.
Shared vision and the collective drive to deliver tangible benefits to the business underlie the Agile principles. A cross-functional team of resources dedicated to a project would deliver working software sprint after sprint. Because of the inherent nature of the teams, and teams working on specific features with a holistic approach, the Software Development Life Cycle (SDLC) barriers are blurred or nonexistent in a typical Agile environment. Sticking to phased plans would amount to violating these fundamentals of Agile and result in limited benefits to the business.
The following sections illustrate a typical scenario in which teams work on phase-specific activities without a common understanding of the end objectives.
IT organizations with shared services for SDLC phases
The typical team setup in an IT organization based on SDLC functions would have the following characteristics:
Teams are organized based on their specific role in the SDLC.
The teams are specialized in a given area of the SDLC and they provide their services to a project.
Each team works on multiple projects -- either sequentially when dedicated effort is called for, or in parallel on multiple projects.
Time and effort are shared across many requirements.
These teams provide specialized services but tend to be in silos.
Agile in silos
With time-to-market demands and budget pressures, any IT organization would want to turn around deliverables faster and may want to try Agile. However, teams organized based on their specialization, using the above shared services structure, would see the following challenges in adopting Agile:
The teams are specialist groups and are experts in a given area of the development life cycle, such as coding, testing, or business analysis. These are not truly cross-functional in nature.
The project boundary is blurred, because teams work on multiple projects at the same time.
The Definition of Done would be limited to completion of specific tasks rather than getting a functionality ready. The teams tend to develop a "my deliverables as per my deadlines" syndrome, without clarity on the end product -- the "working solution."
Yes, each specialist group may succeed in reducing turnaround time and may deliver more in a given time using Agile principles. But for what use? Typically, the deliverables of a specialist group would have to wait to be integrated until those of the other groups are available. In effect, each group will end up producing "inventory," which is one of the wastes in the Lean world. An illustrative flow of deliverables in this structure from sprint to sprint is shown below:
As the teams produce isolated outputs, there is little or no scope for continuous integration.
Thus, while Agile will in fact improve the productivity and delivery cycle of each specialist group, the business may not see the gains of faster delivery of a complete solution.
Agile in sync
Now let us consider a situation in which these specialist groups come together and work toward a set of commonly agreed business functionalities. In this setup, each specialist group dedicates a certain number of people to one project. These team members form the cross-functional Scrum team to produce working software sprint after sprint.
In scenarios in which the deliverables from each project have to be integrated and validated before moving to production, a Scrum of Scrums could be organized by identifying selected participants from each Scrum team or specialist group.
The following illustration depicts this structure and shows how a set of integrated skills within a team could provide business value.
With representatives from each specialist group, the truly cross-functional team will be able to operate in sync to deliver tangible benefits to the business, using Agile.
It is to be noted that the team members could continue to belong to their respective specialist groups but would have to adapt to a certain degree of dual reporting -- one to their specialist group and the other within the context of the Scrum team.
Factors to consider
Change management is critical. While maintaining their unique position as experts, the specialist groups have to adapt to working with other experts in a small team focusing on a specific set of requirements to produce completely coded, tested, and integrated software.
Leadership has to provide the flexibility to maintain the specialist group structure as well as cross-functional teams. With consistency in adoption and sustained business benefits, leadership could even consider diluting the specialist group structure and adopting truly Agile team structures.
The CIO and his or her team should also consider budgeting for the projects in a way that will suit the Agile way of working. This will, in turn, impact the budget provisions for each specialist group. In other words, the CIO will have to answer this question: Is it a budget for the specialist group or a budget for a portfolio of projects?
A governance and benefits validation mechanism would be key to the success of this model.
Using Agile within a shared-services specialist group will yield limited benefits, and scaling such a model would be challenging. An integrated team with specialists from each specialist group would enable an IT organization to run projects in the true spirit of Agile and would yield business benefits faster.