Session title: Agile is a journey not a destination.
Session type: Case Study / Experience Report
Session duration: 45
Speaker: Paul Grenyer
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 description: I work for 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 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. 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 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.
Session type: Case Study / Experience Report
Session duration: 45
Speaker: Paul Grenyer
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 description: I work for 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 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. 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 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.
Comments
Post a Comment