I have just had confirmation that I will be speaking at Agile Cambridge at 2.15pm on Thursday 14th October 2010. Please come and see me!
Session title: Agile is a journey not a destination.
Session type: Case Study / Experience Report
Session duration: 45
Session abstract: Agile is a journey not a destination describes a software team's two and a half year journey from inception to really becoming agile, the evolving process that was adopted and the lessons learnt in the first iterations.
Session description: This is a success story. A young company that has made a big impact in its market and has quickly established a strong foothold and a growing reputation for product innovation and time-to-market delivery. A stretching but credible business strategy will see the company broaden and deepen its market proposition; a future that is critically enabled through a fully distributable software platform.
A company that at times needed to be “more agile than agile”, as was a frequent refrain of the CTO. In the early days, like many start-ups, requirements were changing on a daily basis and the software needed to keep up with it. Right from the beginning, Agile was the intended methodology, but it was impossible to get the requirements to stand still even for a five day iteration (as is often the way with an owner occupied start-up and the race is on to ‘deliver’). Company growth was phenomenal (11 to 100+ people in a little over two years). However, the requirements did eventually start to stabilise enough for Agile to become a real proposition.
‘Agile is a journey not a destination’ describes a software team's two and a half year journey from inception to really becoming agile, the evolving process that was adopted and the key lessons learnt in the first iterations.
In the first part of the presentation I will look at how the software team grew into one of the most technically proficient and successful teams in the area, examining some of the triumphs and pitfalls along the way. I will describe the market opportunity that the company spotted and how the business responded rapidly to meet and exceed the expectations of its new customer base; and how the urgency to deliver a proposition affected the software development team. I will then describe the period from the heady early days to the a time when the requirements finally began to stabilise enough to enable the team to stand back (for a moment) and consider how Agile could be effectively implemented.
I will look briefly at the agile practices, such as unit testing and continuous integration, that should not be taken for granted in any software development, not just Agile software development. I will then go on to describe some of the obstacles that were encountered and how they were overcome, including how buy-in from more traditional project managers was achieved. Also, I’ll provide some key lessons on how you can effectively manage the transition from a waterfall mindset to an agile one; e.g. how to dovetail a business process map with an Agile story and winning the hearts-and-minds of all concerned.
Finally I will describe the development process followed and the lessons learned in the early iterations; like the need for visibility and continuous and free flowing team communication. No agile process is perfect first time and like software, the process must evolve.
This presentation has been written especially for Agile Cambridge, but will probably be given a warm up at ACCU London.
Intended audience: Software developers and project managers.
Session outputs: None
Biography: Paul has been programming in one form or another for over 20 years. After several years using C++ and a brief period using C#, Paul is now happy somewhere he hoped he'd never be, programming in Java.
After time in industries such as marking machinery, direct mail, mobile phones, investment banking and Internet TV, Paul is currently working for a company based in Norwich where he heads up an ever growing team of senior and highly skilled people.
When he's not programming and family life allows, Paul thoroughly enjoys science fiction, heavy metal and cycling.
Session title: Agile is a journey not a destination.
Session type: Case Study / Experience Report
Session duration: 45
Session abstract: Agile is a journey not a destination describes a software team's two and a half year journey from inception to really becoming agile, the evolving process that was adopted and the lessons learnt in the first iterations.
Session description: This is a success story. A young company that has made a big impact in its market and has quickly established a strong foothold and a growing reputation for product innovation and time-to-market delivery. A stretching but credible business strategy will see the company broaden and deepen its market proposition; a future that is critically enabled through a fully distributable software platform.
A company that at times needed to be “more agile than agile”, as was a frequent refrain of the CTO. In the early days, like many start-ups, requirements were changing on a daily basis and the software needed to keep up with it. Right from the beginning, Agile was the intended methodology, but it was impossible to get the requirements to stand still even for a five day iteration (as is often the way with an owner occupied start-up and the race is on to ‘deliver’). Company growth was phenomenal (11 to 100+ people in a little over two years). However, the requirements did eventually start to stabilise enough for Agile to become a real proposition.
‘Agile is a journey not a destination’ describes a software team's two and a half year journey from inception to really becoming agile, the evolving process that was adopted and the key lessons learnt in the first iterations.
In the first part of the presentation I will look at how the software team grew into one of the most technically proficient and successful teams in the area, examining some of the triumphs and pitfalls along the way. I will describe the market opportunity that the company spotted and how the business responded rapidly to meet and exceed the expectations of its new customer base; and how the urgency to deliver a proposition affected the software development team. I will then describe the period from the heady early days to the a time when the requirements finally began to stabilise enough to enable the team to stand back (for a moment) and consider how Agile could be effectively implemented.
I will look briefly at the agile practices, such as unit testing and continuous integration, that should not be taken for granted in any software development, not just Agile software development. I will then go on to describe some of the obstacles that were encountered and how they were overcome, including how buy-in from more traditional project managers was achieved. Also, I’ll provide some key lessons on how you can effectively manage the transition from a waterfall mindset to an agile one; e.g. how to dovetail a business process map with an Agile story and winning the hearts-and-minds of all concerned.
Finally I will describe the development process followed and the lessons learned in the early iterations; like the need for visibility and continuous and free flowing team communication. No agile process is perfect first time and like software, the process must evolve.
This presentation has been written especially for Agile Cambridge, but will probably be given a warm up at ACCU London.
Intended audience: Software developers and project managers.
Session outputs: None
Biography: Paul has been programming in one form or another for over 20 years. After several years using C++ and a brief period using C#, Paul is now happy somewhere he hoped he'd never be, programming in Java.
After time in industries such as marking machinery, direct mail, mobile phones, investment banking and Internet TV, Paul is currently working for a company based in Norwich where he heads up an ever growing team of senior and highly skilled people.
When he's not programming and family life allows, Paul thoroughly enjoys science fiction, heavy metal and cycling.
Comments
Post a Comment