A few years back, I had updated my Resume (CV) and as part of the headline included the text "experience with large-scale, geographically globally distributed-development projects spanning 200+ people, using Agile principles, multi-project" and was rightly challenged by a colleague as to exactly what message those words were actually trying to convey? Of course, CVs supposed to contain all the attention-seeking buzzwords, but it really did sound and read like a mouthful, most people would not understand what I hoped it would mean, it sounded too arty-farty and dressed up - advice was "Please remove it, it makes no sense" - and this was coming from this guy who I hold in great esteem, one of the best software system architects I know (and worked with closely); and so removed that sentence from existence...until now.
In the next series of posts I aim to describe my experiences from a very large-scale software development project, that was not only based on agile principles in general but also adopted a highly structured & rigorous approach as well. Whilst I was not part of the original group that conceived and instigated the processes & framework foundations, I joined the team to take over the mainstream project management (relieving the founding team to concentrate on product management and future customers) to help get the first major product release delivered. This was at a stage when the founding management team had already experimented with various agile strategies twelve months into the project, having made numerous mistakes and having learnt from those mistakes, were just transitioning to their third attempt, which actually ended up proving itself as the final methodology; and was used for the subsequent two years with only minor, natural evolutionary updates to accommodate new needs and demands as the project evolved through development into delivery & final release phases. However, the underlying fundamental key principles were solidly embedded and continues to work reasonably well to this day IMHO. So I ended up being an executioner of the process for a period of just over two years, and then joined the product management team in promoting the methodology for new projects, providing teaching, training & coaching to other projects as well as introducing new tools and concepts, until I figured I'd seen enough and moved back into mainstream software development.
However, in those solid 3+ years of working on that programme, I had learnt quite a bit about the theory of Agile versus appreciating and adopting much of spirit of Agile, taking into account organisational & project maturity, structures and processes, theory vs practice, resistance vs acceptance, people vs management, processes & controls vs fluidity & flexibility, not forgetting customer focus vs ideal product management (customer always comes first). So now I'd like to communicate the guiding principles that made and continues to make the above-mentioned endeavour (could this become a model for other companies perhaps?), which the industry refers to as "Large-scale Software Development", work in the real world: where a truly geographically dispersed, distributed multidisciplinary team of developers, architects, integrators and testers, project & programme management teams are all synchronised on a common development & delivery methodology having its roots in Agile -- are actually sustaining high profile, time-critical, multimillion dollar projects of an exceptionally high quality and complex nature, including the challenges of using just one single codebase to support multiple independent customers -- a case study in Distributed Development using Disciplined Agile Methodologies for a Digital TV Set-Top-Box Software Project.
The underlying reason behind this post however, like all my previous posts, is a focus on Digital TV projects specifically around Set-Top-Box UI EPG & Middleware development initiatives, where increasingly organisations are embarking on implementing Agile end-to-end, even on my current project which I've inherited, Agile had been chosen as the development methodology. Don't get me wrong, I am all for agile, I respect its philosophy; as someone who loves autonomy myself, I wouldn't have it any other way. But nevertheless, as I've written in the past, Agile can go very wrong if being implemented for the very first time. This is why (and this is not just my opinion, see this report), Agile should not be chosen on a mainstream project that is the company's crown jewels, instead, the recommendation has generally been to start with a pilot programme that you can afford to throw away, fail and start over, expect to fail many times before getting the ingredients just right....but I digress...getting back to the purpose behind the next series of posts:
I have seen a model of Agile (Disciplined Agile Delivery) implemented successfully in the real world on a large-scale development & delivery project - and would like to share this experience with others as I think it would be useful & helpful, at the very least can be used as input material if you're considering adopting Agile in your own DTV projects.
I've broken down the concepts into several themes/parts - I'll update with links to each post as each is published:
However, in those solid 3+ years of working on that programme, I had learnt quite a bit about the theory of Agile versus appreciating and adopting much of spirit of Agile, taking into account organisational & project maturity, structures and processes, theory vs practice, resistance vs acceptance, people vs management, processes & controls vs fluidity & flexibility, not forgetting customer focus vs ideal product management (customer always comes first). So now I'd like to communicate the guiding principles that made and continues to make the above-mentioned endeavour (could this become a model for other companies perhaps?), which the industry refers to as "Large-scale Software Development", work in the real world: where a truly geographically dispersed, distributed multidisciplinary team of developers, architects, integrators and testers, project & programme management teams are all synchronised on a common development & delivery methodology having its roots in Agile -- are actually sustaining high profile, time-critical, multimillion dollar projects of an exceptionally high quality and complex nature, including the challenges of using just one single codebase to support multiple independent customers -- a case study in Distributed Development using Disciplined Agile Methodologies for a Digital TV Set-Top-Box Software Project.
The underlying reason behind this post however, like all my previous posts, is a focus on Digital TV projects specifically around Set-Top-Box UI EPG & Middleware development initiatives, where increasingly organisations are embarking on implementing Agile end-to-end, even on my current project which I've inherited, Agile had been chosen as the development methodology. Don't get me wrong, I am all for agile, I respect its philosophy; as someone who loves autonomy myself, I wouldn't have it any other way. But nevertheless, as I've written in the past, Agile can go very wrong if being implemented for the very first time. This is why (and this is not just my opinion, see this report), Agile should not be chosen on a mainstream project that is the company's crown jewels, instead, the recommendation has generally been to start with a pilot programme that you can afford to throw away, fail and start over, expect to fail many times before getting the ingredients just right....but I digress...getting back to the purpose behind the next series of posts:
I have seen a model of Agile (Disciplined Agile Delivery) implemented successfully in the real world on a large-scale development & delivery project - and would like to share this experience with others as I think it would be useful & helpful, at the very least can be used as input material if you're considering adopting Agile in your own DTV projects.
I've broken down the concepts into several themes/parts - I'll update with links to each post as each is published:
- Part 0: Introduction: this post - Objectives
- Part 1: The Stage: What is a Large-Scale Software Development Project (LSSDP) anyway?
- Part 2: Organisational Structures for Large-Scale Software Projects
- Part 3: Implementing Large-Scale Agile/Scrum Model - Product Management Methodology
- Part 4: Implementing Large-Scale Development, Integration & Delivery Model
- Part 5: Implementing a Large-Scale Architecture Model
- Part 6: Implementing Large-scale Continuous Integration (including Config Management)
- Part 7: Evolution of the Model - Dealing with Growth, Scaling the backlog, etc.
- Part 8: The challenges with Continuous Delivery
- Part 9: Conclusions
No comments:
Post a Comment