In my previous post I introduced the subject of LSSDP: Large-Scale Software Development Projects.
In this post I'll try to describe what I've come to understand as a Large-Scale Software Development Project (LSSDP) based on my real-world experience of successfully delivering such projects. There are many buzzwords flying around, recapping my own attempt to capture headlines on my CV: Experience with large-scale, geographically globally distributed-development projects spanning 200+ people, using Agile principles, multi-project
In this post I'll try to describe what I've come to understand as a Large-Scale Software Development Project (LSSDP) based on my real-world experience of successfully delivering such projects. There are many buzzwords flying around, recapping my own attempt to capture headlines on my CV: Experience with large-scale, geographically globally distributed-development projects spanning 200+ people, using Agile principles, multi-project
- Large-Scale Software Development Projects
- Global Software Development Projects
- Multisite Software Development Projects
- Globally Distributed Software Projects
- Geographically Distributed Software Projects
What do I mean by Large-Scale?
I consider a project as being "Large-Scale" where the project in question has the following ingredients:
- Significant financial investment in the project spanning tens of millions of dollars
- Technology being produced by the engineering team is of a complex nature
- The engineering team (developers/testers/integrators), product and project management teams span in excess of 200 people
- Exceedingly high Expectations placed on the project team to ensure a successful outcome
- Strong implementation of processes & methodologies to co-ordinate and steer the project along
- Globally Distributed teams (where co-location impossible)
- Commercial/Proprietary
What do I mean by Globally Distributed?
Let's start with defining "Distributed" by using its opposite, which in software terms, we usually use "Centralised" - single point of control. This isn't strictly applicable here, we are instead focused on the physical locality of the the project's team members, i.e. the Locality of the team. Locality in my opinion, has many variations, at the highest level, we sometimes say a team is co-located when all the team members are physically present in the same region/area (e.g. Office park, Campus R&D building, third-floor, west-wing) - but that is quite specific. Some might say that a team is co-located if they're all present in the same office park, for instance, your company might have a campus with many buildings on-site, just being on campus can be interpreted as locality local, co-located. But I prefer to depart from this view and rather choose to say that a distributed team is one where the team are not all housed together and are separated by one or more arbitrary barriers.
How deep does one go? If my team are not all in the same building, on the same floor, then my team is distributed: Same building, different floor. Different buildings same campus park. Same country different province. Same province different campuses. Get my drift? As soon as there's some barrier that's going to impact communications, co-ordination, team building and coherency -- we then have a distributed team.
We have a Globally Distributed Project where the team consists of participants located from other geographic areas: Same continent, different countries. Different Continents, Different Countries - i.e. a Geographically Dispersed Team.
A Quick Note on Open Source Projects
Before anyone jumps up and down and wax lyrical on how the big-name open source projects are all large-scale and distributed and that we should learn from this community, etc. etc -- I accept, respect and admire the open source movement myself; but as we all know, the corporate world is an altogether different machine. Distributed projects can be run along the same principles as the open source movement, in the context of the corporate shell. Delivery large-scale, commercial programmes come with a lot of risk to the business (which is not applicable to open source projects), and as such these projects have to be run a little differently.... All I would like to do is share my exposure in running such projects, not really advocating one methodology over another (although when you dig deeper into how decisions are made in open source projects, there is usually a single entity, some call it the BDFL that eventually calls the shots, much like a commercial programme!)...
Case Study: Developing Set-Top-Box Software, Large-Scale, Globally Distributed Project
Case Study: Developing Set-Top-Box Software, Large-Scale, Globally Distributed Project
The remaining posts are all based from a past project, which I can can truly say was one of the best project experiences in my career-to-date, that allowed me to grow in more ways than I can imagine. It is no secret that NDS is on a mission to becoming the world's leading Middleware provider with its MediaHighway Portfolio. Like all successful software product companies, there is always the challenge of supporting your existing customers using legacy technology, and trying to work on cutting-edge innovative new products & features. NDS was no exception, over the 10-25 years of providing Middleware to many different customers, satisfying the various needs and demands of these customers, the products started to fragment and reach their maturity. With development centres situated across the world (US, UK, France, Israel, India, Korea) each supporting a slice of the product (Basic, Evolution, Advanced), each centre wishing to innovate and move the product forwards in their own way. To cut a long story short, the company decided to use the vast knowledge-base and experience from its global technical team to produce the next generation, advanced Middleware platform, which was known at one stage to the outside world as "MediaHighway Advanced", but this often changes whichever way the marketing wind is blowing. Internally we (and for a short while, the press) referred to this product as MediaHighway Fusion, I'll stick to "Fusion" for the remaining posts.
Fusion was not just about new technology and new architecture. Yes, it was borne from learning the hard lessons from its' predecessors (Core4, Evolution, Pantalk, XTV), taking the best design principles, merging with modern Linux & general operating system architectures, changing some models up-side-down, for example the concept of CDI (Common-Driver-Interface) that departs from the classic HAL (Hardware Abstraction Layer)-STB manufacturer tight coupling....(future post will discuss STB architecture)....Fusion was more about improving response times to deliver new features to market: Agility, Flexibility and Continuous Delivery. Faster time to market, can we deliver new features in three week sprints, i.e. sustain product increments every three weeks??
So what made Fusion a Large-Scale Project anyway?? The core Fusion architecture and principles were conceived by a small team of technical experts. The first major milestone was the production of the CDI specification, which is a 1500+ pages of technical specifications aimed at Chipset Vendors to comply with the underlying broad platform infrastructure, the low-level interface definitions. That was the ultimate starting point as it laid the foundation for services supplied to the upper layers of the software stack. The Middleware architecture was component based, consisting in excess of 100 components. The components were to be written and owned by development teams, located throughout the world: Two sites in UK, France, Israel & India (Note that language and cultural dynamics!). The CDI team located in Korea. The architecture was very complex, and was owned by a team of 20-30 architects, with a team of 3 chief architects controlling the overall decision making process. We referred to those 3 elite techno gurus as the Trinity. So IMHO, we have all the ingredients for a LSSDP...In fact, I think the method of Agile implemented, although not purist in its form, was very disciplined that proved itself well in managing this LSSDP project...
Even in the R&D phase, this internal product development project was considered large-scale: ticking boxes of complex architecture and geographically dispersed teams. On landing the first customer win, Fusion switched focus to becoming both a development and delivery project (the Middleware was not complete, but we had to submit to project urgency). The customer (BSkyB) being quite bullish and demanding in its launch targets, resulted in an overdrive focus. The Project teams grew and expanded, new component teams were created, methodologies were introduced to control multiregion planning, management, development and integration. In a relatively short period of time the core development team scaled from 50 to 250 people. Two years later, there would be between 300-700 people all engaged on project deliveries (for major customers) all on the Fusion platform (that was still maturing).
In the next post I'll go deeper into the organizational structures - but for now, lets summarise how Fusion meets the requirements for LSSDP:
- Complex Architecture: 100+ components, new technologies, strict architecture rules
- Trinity of Chief Architects - Geographically Distributed Globally
- Group of System Architects (20-30+) - Geographically Distributed Globally
- Development & Integration Team (250+) - Geographically Distributed Globally
- Project Management Team (10+) - Geographically Distributed Globally
- Product Management Team (5+) - Geographically Distributed Globally
- Financial Investment (Tools, Infrastructure, People) - Circa $100 million or more
- Delivery Pressures - Customer Launch delivery in 2-3 years
Do you agree this is an LSSDP?? Read Part 2: Organisational Challenges of LSSDP Agile Projects...
Fusion was not just about new technology and new architecture. Yes, it was borne from learning the hard lessons from its' predecessors (Core4, Evolution, Pantalk, XTV), taking the best design principles, merging with modern Linux & general operating system architectures, changing some models up-side-down, for example the concept of CDI (Common-Driver-Interface) that departs from the classic HAL (Hardware Abstraction Layer)-STB manufacturer tight coupling....(future post will discuss STB architecture)....Fusion was more about improving response times to deliver new features to market: Agility, Flexibility and Continuous Delivery. Faster time to market, can we deliver new features in three week sprints, i.e. sustain product increments every three weeks??
So what made Fusion a Large-Scale Project anyway?? The core Fusion architecture and principles were conceived by a small team of technical experts. The first major milestone was the production of the CDI specification, which is a 1500+ pages of technical specifications aimed at Chipset Vendors to comply with the underlying broad platform infrastructure, the low-level interface definitions. That was the ultimate starting point as it laid the foundation for services supplied to the upper layers of the software stack. The Middleware architecture was component based, consisting in excess of 100 components. The components were to be written and owned by development teams, located throughout the world: Two sites in UK, France, Israel & India (Note that language and cultural dynamics!). The CDI team located in Korea. The architecture was very complex, and was owned by a team of 20-30 architects, with a team of 3 chief architects controlling the overall decision making process. We referred to those 3 elite techno gurus as the Trinity. So IMHO, we have all the ingredients for a LSSDP...In fact, I think the method of Agile implemented, although not purist in its form, was very disciplined that proved itself well in managing this LSSDP project...
Even in the R&D phase, this internal product development project was considered large-scale: ticking boxes of complex architecture and geographically dispersed teams. On landing the first customer win, Fusion switched focus to becoming both a development and delivery project (the Middleware was not complete, but we had to submit to project urgency). The customer (BSkyB) being quite bullish and demanding in its launch targets, resulted in an overdrive focus. The Project teams grew and expanded, new component teams were created, methodologies were introduced to control multiregion planning, management, development and integration. In a relatively short period of time the core development team scaled from 50 to 250 people. Two years later, there would be between 300-700 people all engaged on project deliveries (for major customers) all on the Fusion platform (that was still maturing).
In the next post I'll go deeper into the organizational structures - but for now, lets summarise how Fusion meets the requirements for LSSDP:
- Complex Architecture: 100+ components, new technologies, strict architecture rules
- Trinity of Chief Architects - Geographically Distributed Globally
- Group of System Architects (20-30+) - Geographically Distributed Globally
- Development & Integration Team (250+) - Geographically Distributed Globally
- Project Management Team (10+) - Geographically Distributed Globally
- Product Management Team (5+) - Geographically Distributed Globally
- Financial Investment (Tools, Infrastructure, People) - Circa $100 million or more
- Delivery Pressures - Customer Launch delivery in 2-3 years
Do you agree this is an LSSDP?? Read Part 2: Organisational Challenges of LSSDP Agile Projects...
No comments:
Post a Comment