In a previous post, I shared a method of Software Development & Integration that component teams adopted for a very large scale project, where the development & integration team spanned in excess of 250 people, geographically dispersed across the world, where the system software stack was a Set-Top-Box Middleware product, consisting of eighty (80+) software components, each component owned by individual component teams, a component team size being anywhere between five and twenty people (all software engineers). These component teams implemented Agile/Scrum at their own individual team level, and had to also deliver their components into project integration streams, with multiple project delivery timelines overlapping simultaneously using a common iteration heartbeat of six week cycles.
This was grand-scale, iterative development & continuous integration that did come with an enormous infrastructure overhead as well as quite a structured implementation of Agile Product Management. Please refer to my earlier post that introduced that particular case study.
In that case study, I maintained that the principles of development & engineering strategies equally apply to small, singular component teams as well as large-scale, distributed teams. In the end, it is just managing a component development & delivery stream.
The purpose of this post is to drill into some of the challenges that impact Set-Top-Box Software Development projects, regardless of the component impacted - especially when component teams have to maintain a common product code-base, yet at the same time manage multiple project deliveries to customers, often with overlapping timelines. I will touch on some of the scenarios development teams face, and highlight the implications of co-ordination & control aspects, in relation to how going Agile/Scrum possibly makes it simpler or more complicated...
This post is structured as follows:
This post is structured as follows:
Traditional Project management processes demand a level of resource (people) planning, often expecting people are assigned & dedicated to projects, i.e. the traditional ring-fenced team approach. Every project must have a dedicated team assigned. This way, the project budgeting can be estimated and to some level controlled, and timeline estimations can be based on man-days. It also gives management a comfort feeling of control, "these are my resources, they do as the project demands".
This traditional stance is often imposed upon development teams, who have to figure out how to satisfy their customers, at the same time, do what makes sense to their own team. Traditional management are not used to the response "We have a shared team, we manage customer priorities based on load, supply & demand, capacity. We don't create separate project development streams to manage project deliveries. Our people are cross-skilled, the knowledge is shared and we can deliver on multiple project requirements simultaneously. Leave it up to us to plan, if we think we need more people we'll let you know. But for now, rest assured that at any one time, there will be at least two heads working on your project..."
A strong development manager with a passion for Agile and known for protecting his/her team will maintain this ground and push back on traditional project demands. Depending on the past successes as well as trust and respect earned by the team (met commitments on previous projects, delivered on time and met quality) - this approach would most likely work. The traditional project manager will allow sufficient time to play itself out, instead of trying work the resource plan, will focus more on building the relationships required, getting to know the team better, fleshing out the backlog, wait a couple iterations and then re-ignite the discussion if required.
Yet, some teams do opt for splitting the component development teams up according to the different project deliveries, form scrum teams for each project as well as other activities. In this way, the development team feel they've responded to the requirements from traditional management of ring-fenced team, and will implement methods of control internally within the team to manage this development challenge.
Visually the picture generally looks like this:
 |
| Typical Product Structure |
This picture is typical of many STB product breakdowns, especially when trying to map within Agile Frameworks:
Regardless of Option, some Administration Overhead will be Unavoidable
No matter what option one chooses, if the aim is to maintain a common codebase or architecture, some bit of discipline in administration cannot be avoided. Firstly, the software architecture must be fully understood by all team members. The architecture must lend itself well to be tailored and configured to support multiple project or feature combinations without difficulty.
That multiple projects can build upon a single, unified codebase and produce different builds or releases is something that is really difficult to achieve in practice - not specifically from a technical complexity view, but from a people view - it is really difficult to get people to maintain consistency and harmony of implementation without recourse for regular communications and tracking in place.
Hence a level of administration around maintaining the integrity of codebase / architecture is fundamental, and a shared challenged regardless of the development team being a single entity or distributed entities.
Another administration challenge is maintaining code deliveries to the component tip. Please refer to the full implications of multiple code delivery management in this post here.
When code is delivered back to trunk / tip, especially when there are multiple projects involved - care must be taken to control the code deliveries. This requires some bit of co-ordination. When the team is just one unit, this is easily controlled through the daily stand-up where the entire team gets briefed of which code deliveries are "Done" and ready for delivery. This way the team can use the white board to know what user stories are coming in for the day, how and when is the best point to do the code re-merge or re-base, and know the timetable for the next set of deliveries for the week.
Definition of "Done" (DOD) becomes important for the team to fully adhere to - especially when multiple projects are involved, care must be taken that changes for one project doesn't break other projects, etc - that in the DOD, includes checks and balances for regression from other projects, as well as proving all tests are passing for the new feature, before delivery back to trunk. And on delivering back to trunk, and additional set of tests, usually the nightly tests will pick up overall regressions on the main codebase.
Again, this becomes practical to manage when the team a is a single entity - although co-ordination is still required. But, when the teams are split into separate project teams, then communication, co-ordination and administration will be expounded in relation to the number of teams involved. It will be quite a job to manage co-ordinating timely code deliveries from various teams, ensuring common design is maintained, and no code breaks happen in areas that require simultaneous changes to common areas of code, for different projects. I have written in the past about Air Traffic Control metaphor in managing code deliveries, this will still apply to both small-and-large teams alike.
So in a nutshell, it is not always straightforward to assume a split in development teams to run multiple projects. It is up to the component development team to choose an approach based on understanding full well the implications of their own choices, and still maintain to deliver according to the demands of the multiple project customers...
- The flow on the Left-Hand-Side shows the typical Roles involved
- The flow on the Right-Hand-Side shows how a Product, that is really built on a common Platform Technology, splits up into one-to-many Projects, each delivering a different kind of product-variant.
- For example, the common platform supports a PVR configuration for High-End Set-Top-Boxes, or can be a Low Cost Zapper, a Home Gateway Server, and so on.
- Each Project maintains a high level Project Plan or Project Backlog
- Each Project consists of multiple Release Cycles, with Release Backlogs delivered per cycle
- Each Release Cycle impacts multiple software components that make up the product
- Each Component will deliver in multiple iterations within that Release Cycle
- Each Component will maintained detailed iteration (sprint) backlogs
- The Roles involved:
- Product Director maintains the Executive/Strategic Business Requirements at the highest level, the long term roadmap - big feature items
- The Product or Platform Manager maintains the Product Backlog required to deliver on the Business Roadmap
- Release Managers work with Product Manager to plan the Release Deliveries
- Agile Product Owners work in unison with Product Managers & Release Manager to flesh out the detailed requirements
- Scrum Masters work with various component teams to deliver on the component requirements
- Feature Owners maintain consistency of features across platforms and across product-variants
So because of this Project-View bias, there generally is one Release Project Manager assigned to deliver one Project Delivery, for example: Delivery of a PVR. The Release Manager works with the Component Vendors to produce a plan for delivering the Release to market. [This process requires a post for another day].
So how does the component-team view look like?? When faced with this structure, the component team, for example the EPG Application team, are left with the following options, and assuming single shared codebase is used:
- Separate team per project implying separate, Unique Backlogs? OR
- One combined team supporting multiple projects, but with a single unified Backlog view? OR
- Common backlog, multiple project teams?
Visually, the options manifest themselves as:
Option A essentially follows the path of traditional Ring-fenced team approach:
I tried to summarize the key pros/cons of the above options using the table below. This is non-exhaustive, but meant to highlight the salient issues for consideration only: |
| Options/Implications for structuring Component Development Team |
Option A essentially follows the path of traditional Ring-fenced team approach:
- Spawn off separate project teams per project
- Each project team maintains their own unique view of their project backlog
- The development team is split up into core project teams, working off the same codebase
- Each team will have its own Scrum Master, Developers, Testers, Integrators
Option B essentially promotes the a purer Agile implementation of projects:
- Since there is only one architecture and one codebase delivering features to different "projects", you just have the development owned by just ONE complete team
- A common backlog is maintained that shares all the stories from all other projects
- There is only one development team, probably with just ONE Scrum Master
Option C is not shown but is basically this: Maintain a common backlog unifying all project stories but maintain separate teams per project delivery. This is a hybrid of A & B, which might be more appealing to some teams, based on the challenges as I'll touch on in the next section.
Regardless of Option, some Administration Overhead will be Unavoidable
No matter what option one chooses, if the aim is to maintain a common codebase or architecture, some bit of discipline in administration cannot be avoided. Firstly, the software architecture must be fully understood by all team members. The architecture must lend itself well to be tailored and configured to support multiple project or feature combinations without difficulty.
That multiple projects can build upon a single, unified codebase and produce different builds or releases is something that is really difficult to achieve in practice - not specifically from a technical complexity view, but from a people view - it is really difficult to get people to maintain consistency and harmony of implementation without recourse for regular communications and tracking in place.
Another administration challenge is maintaining code deliveries to the component tip. Please refer to the full implications of multiple code delivery management in this post here.
When code is delivered back to trunk / tip, especially when there are multiple projects involved - care must be taken to control the code deliveries. This requires some bit of co-ordination. When the team is just one unit, this is easily controlled through the daily stand-up where the entire team gets briefed of which code deliveries are "Done" and ready for delivery. This way the team can use the white board to know what user stories are coming in for the day, how and when is the best point to do the code re-merge or re-base, and know the timetable for the next set of deliveries for the week.
Again, this becomes practical to manage when the team a is a single entity - although co-ordination is still required. But, when the teams are split into separate project teams, then communication, co-ordination and administration will be expounded in relation to the number of teams involved. It will be quite a job to manage co-ordinating timely code deliveries from various teams, ensuring common design is maintained, and no code breaks happen in areas that require simultaneous changes to common areas of code, for different projects. I have written in the past about Air Traffic Control metaphor in managing code deliveries, this will still apply to both small-and-large teams alike.
So in a nutshell, it is not always straightforward to assume a split in development teams to run multiple projects. It is up to the component development team to choose an approach based on understanding full well the implications of their own choices, and still maintain to deliver according to the demands of the multiple project customers...
No comments:
Post a Comment