Ipsum lorem
Wednesday, 2 June 2010
Sunday, 27 September 2009
Change is difficult
If you have read my previous blog entry you will know that I was running a programme within a large organisation and decided to move away from the Waterfall approach and use the Scrum methodology instead.
Employing the Scrum methodology on a large and strategic programme did indeed make my life more exciting and challenging. I would like to thhink that this goes for me as well as for the team and I suspect for the whole organisation.
The programme started out as a traditional waterfall attempt to update our systems in order to rectify some of the deficiencies left over from the initial implementation. By embracing the Agile approach we managed to turn the programme into a vision for the future, a pathfinder for projects and programmes to come and it has effectively started a minor Scrum revolution within my company.
Even though I had some experience with using XP methodologies for large scale development programmes I quickly recognised that I had a lot to learn. The challenges around implementing Scrum for us were many but probably focussed on how to get started, how to design, how to test, roles and responsibilities, what tools to use, how to report and track progress across many teams and projects, how to scale it, how to live peacefully with waterfall projects, trusting the teams to get on with it and changing the corporate culture of the business representatives, developers, testers, IS operations, business analysts and managers involved.
The hardest part for me initially was introducing such fundamental change to a very large and complicated organisation which – frankly – wasn’t in the mood for change. It is said that corporate culture eats strategy and plans for breakfast. That was certainly the case for me here. Early on, I realised we would go through four distinct phases and I spent a lot of time preparing and supporting my team through these phase:
Phase 1: Ridicule
What happens next?
I know that we still have a very long way to go to fully implement Scrum. Within the programme we have obviously done quite a lot of experimenting, made a lot of the necessary mistakes and built up valuable experience of how Scrum can (and cannot) work within our organisation. However, I also know that we as an organisation will need to go through exactly the same four phases as listed above.
Having just implemented Scrum in a team of 200+ people I know we will be able to employ and scale the same learnings, methods and techniques to cover the entire organisation. Also, we already have 200 ambassadors for Scrum and we need to consider carefully how best to use that asset in the further roll out of Scrum across the organisation. An important thing to understand is that whatever we as an organisation decide to keep or put in place now will definitely change over the next months and years.
Employing the Scrum methodology on a large and strategic programme did indeed make my life more exciting and challenging. I would like to thhink that this goes for me as well as for the team and I suspect for the whole organisation.
The programme started out as a traditional waterfall attempt to update our systems in order to rectify some of the deficiencies left over from the initial implementation. By embracing the Agile approach we managed to turn the programme into a vision for the future, a pathfinder for projects and programmes to come and it has effectively started a minor Scrum revolution within my company.
Even though I had some experience with using XP methodologies for large scale development programmes I quickly recognised that I had a lot to learn. The challenges around implementing Scrum for us were many but probably focussed on how to get started, how to design, how to test, roles and responsibilities, what tools to use, how to report and track progress across many teams and projects, how to scale it, how to live peacefully with waterfall projects, trusting the teams to get on with it and changing the corporate culture of the business representatives, developers, testers, IS operations, business analysts and managers involved.
The hardest part for me initially was introducing such fundamental change to a very large and complicated organisation which – frankly – wasn’t in the mood for change. It is said that corporate culture eats strategy and plans for breakfast. That was certainly the case for me here. Early on, I realised we would go through four distinct phases and I spent a lot of time preparing and supporting my team through these phase:
Phase 1: Ridicule
- “Ha-ha, this will never work!”
- “This may work somewhere else but we are different – you will see”
- Escalations, rebellions, anger and frustrations in the teams and even from people not involved with the programme
- As I started to become more and more familiar with Scrum my confidence returned. Looking back this was the point in time where I stopped managing and started leading
- “I will do what you ask, but it won’t work – and I won’t enjoy it”
- The individual teams themselves went through their own distinct Storming, Forming, Norming and Performing stages
- “This is the obvious way of working and the way we want it to stay”
- In effect you are back where you started and the next change you now introduce will result in ridicule all over again
What happens next?
I know that we still have a very long way to go to fully implement Scrum. Within the programme we have obviously done quite a lot of experimenting, made a lot of the necessary mistakes and built up valuable experience of how Scrum can (and cannot) work within our organisation. However, I also know that we as an organisation will need to go through exactly the same four phases as listed above.
Having just implemented Scrum in a team of 200+ people I know we will be able to employ and scale the same learnings, methods and techniques to cover the entire organisation. Also, we already have 200 ambassadors for Scrum and we need to consider carefully how best to use that asset in the further roll out of Scrum across the organisation. An important thing to understand is that whatever we as an organisation decide to keep or put in place now will definitely change over the next months and years.
Saturday, 26 September 2009
Introducing Scrum
With the obvious success of Scrum and XP many companies and organisations are currently either on their way to introduce Agile methodologies or contemplating how best to go about introducing Agile. This blog is my attempt to share how I introduced Scrum to a large formerly government run utilities company in the UK. This is not meant to be a handbook in how to implement Scrum but rather a collection of random blog entries focusing on different real life experiences. I will try to highlight the lessons my team and I learned as we took the first step into something new and unknown.
I joined the company as a Senior Programme Manager during the summer of 2008. Having worked with projects and project management within the financial services and pensions sector for over 15 years this was quite a change of scenery. My background at that point was almost entirely waterfall although I had managed a couple of projects were we employed many of the XP principles.
My first task was to manage a large programme of work which would turn out to involve more than 15 third party suppliers and 200+ developers, testers, analysts, managers and operational support people spread over many countries on three continents. As part of the programme we made significant changes to more than 10 business critical systems and some of these changes involved changes to industry-wide interfaces. The primary systems were SAP (IS-U) and Siebel 6 but we also had to make changes to bespoke Microsoft, UNIX and mainframe systems. In other words, it was a collection of many interlinked projects potentially causing severe disruption to almost 20,000 call centre agents and potentially impacting nearly 20 million customers.
The programme I inherited had already been scoped at a high level and was following a traditional Waterfall development approach within a Prince2 / APM framework. The next 3-4 months were spent producing requirements and design documents. The individual projects were so interdependent and complicated that we couldn’t really start any development work until all aspects of the design was completed for all projects. The solution at the time was to have very few people involved in the design but this made progress very slow. I was experiencing a sense of "before we know everything about everything nobody can do anything". I was becoming increasingly frustrated as time went by and we were making very little actual progress. Getting to the end of my tether I decided to introduce Scrum as a management and development methodology.
Convincing a very big traditional IT organisation to change course is very hard indeed. The company I work for had a large and complex project management framework with a series of quality gates which were firmly aligned to the waterfall approach. This meant that no design can commence before all requirements have been defined and no development shall be done before all the detailed design has been signed of by all the relevant managers and stakeholders. For a large and complex utilities company with hundreds of systems this takes a long time and because very few people have either the time or the background to understand the vast amount of design documents constantly being submitted for impact the process actually adds very little benefit.
Needless to say this was not straightforward. The issues I faced in my quest to implement Scrum were many but can probably be grouped as follows:
By the way the programme has now delivered and was such a success that our CIO has decided to make Scrum an integral part of the IT strategy. We are now looking to roll out Scrum across the entire organisation – at least for all IT projects. We have already trained and certified more than 100 Scrum Masters and more than 40 Scrum Product Owners and we are changing our project management framework to reflect the transition to Scrum. We still have a long way to go and many bridges still to cross but we are moving fast.
If you have just begun or are about to start out on the Agile journey, I wish you luck and hope that you will find it as rewarding and interesting as I do.
I joined the company as a Senior Programme Manager during the summer of 2008. Having worked with projects and project management within the financial services and pensions sector for over 15 years this was quite a change of scenery. My background at that point was almost entirely waterfall although I had managed a couple of projects were we employed many of the XP principles.
My first task was to manage a large programme of work which would turn out to involve more than 15 third party suppliers and 200+ developers, testers, analysts, managers and operational support people spread over many countries on three continents. As part of the programme we made significant changes to more than 10 business critical systems and some of these changes involved changes to industry-wide interfaces. The primary systems were SAP (IS-U) and Siebel 6 but we also had to make changes to bespoke Microsoft, UNIX and mainframe systems. In other words, it was a collection of many interlinked projects potentially causing severe disruption to almost 20,000 call centre agents and potentially impacting nearly 20 million customers.
The programme I inherited had already been scoped at a high level and was following a traditional Waterfall development approach within a Prince2 / APM framework. The next 3-4 months were spent producing requirements and design documents. The individual projects were so interdependent and complicated that we couldn’t really start any development work until all aspects of the design was completed for all projects. The solution at the time was to have very few people involved in the design but this made progress very slow. I was experiencing a sense of "before we know everything about everything nobody can do anything". I was becoming increasingly frustrated as time went by and we were making very little actual progress. Getting to the end of my tether I decided to introduce Scrum as a management and development methodology.
Convincing a very big traditional IT organisation to change course is very hard indeed. The company I work for had a large and complex project management framework with a series of quality gates which were firmly aligned to the waterfall approach. This meant that no design can commence before all requirements have been defined and no development shall be done before all the detailed design has been signed of by all the relevant managers and stakeholders. For a large and complex utilities company with hundreds of systems this takes a long time and because very few people have either the time or the background to understand the vast amount of design documents constantly being submitted for impact the process actually adds very little benefit.
Needless to say this was not straightforward. The issues I faced in my quest to implement Scrum were many but can probably be grouped as follows:
- Understanding how Scrum theory can be deployed within a large organisation
- How to iteratively design and document a large programme of work without causing chaos in other projects and programme
- How to test before everything is complet
- How to ensure communication between Scrum teams and with projects and stakeholders outside the team
- How to operate Scrum with onshore as well as offshore teams spread over three continents (not including the odd person in USA, Australia and New Zealand)
- How to arrange the sprint heartbeat (i.e. sprint planning, Show & Tell, retrospectives etc)
- Optimising the programme structure to enable sufficient progress
- Who should be Scrum Master (PMs, lead developers, testers or others)
- How to plan and execute operational readiness activities within a Scrum framework
- How to run a programme with significant waterfall project deliverables as well as significant Scrum deliverables
- How to scale Scrum to the programme level
- How to deliver software into a very complex system environment
- How to get started
- Where do we start? Do we just go on and start experimenting or do we arrange for training first?
- How do you make people who doesn’t understand Scrum throw away everything they believe in and follow you into the unknown?
- How to keep going
- How do you keep away doubt and loss of confidence in whether we will succeed?
- What about all the questions from the team you don’t know the answers to?
- How to convince the team that it is OK to make mistakes in a cut-throat corporate culture?
These are but some of the issues we had to wrestle with. I intend to discuss each and every one of these items on this blog in the near future.
By the way the programme has now delivered and was such a success that our CIO has decided to make Scrum an integral part of the IT strategy. We are now looking to roll out Scrum across the entire organisation – at least for all IT projects. We have already trained and certified more than 100 Scrum Masters and more than 40 Scrum Product Owners and we are changing our project management framework to reflect the transition to Scrum. We still have a long way to go and many bridges still to cross but we are moving fast.
If you have just begun or are about to start out on the Agile journey, I wish you luck and hope that you will find it as rewarding and interesting as I do.
Subscribe to:
Posts (Atom)
