This is a guest post by Yves Charreire. Some insightful, practical thoughts on transitioning from Waterfall to Agile in large-scale complex product development. Thanks so very much, Yves, for this post!
Thoughts and Facts in Agile
I am just a frenchy 🙂 , who gets a great chance to share professional culture with North American and Chinese colleagues. I am not at all an Agile Guru, but I would like to share some thoughts and facts about Agile on Raj’s forum.
When Dave Packard and Bill Hewlett invented their very first audio oscillator, or when Steve Jobs and Steve Wozniak created their first computer were they Agile or waterfall? …. Probably none of the two.
They just succeeded in giving valuable real working innovation: In the Steve’s story, the very first computer deal was very clear: In the planning phase, Paul Terrell, their first customer, said he would order 50 of the machines and pay US $500 each on delivery, while HP’s founder was dealing with a 50 dollar stable oscillator breaking state of the art that needed a 200 dollars bill for an unstable one. Innovation was made possible also by a cross functional very small team focusing on one single objective with an obvious sense of survival (i.e for the company) including accepting risk to fail.
Difference to win, in that Darwin, like culture, is leadership excellence; I am not a specialist, I will just give here my personal feeling on what makes for me, successful leadership: charisma, intuition and self confidence (the step to self-esteem not far): “yes we can” or “Impossible n’est pas français.” Fortunately those two example show how this is strongly carved in 100% of worldwide culture (equality of chance even if I think multicultural teams are probably a bit advantaged there). Note that this is not exclusive to a manager role even if a manager has a clear duty there. Note also that critics and conflict are needed even late in a project (Better late than never). Do you know any ”yes man” succeeding to lead a project?
After those roots reflections, let’s now give a few facts about my personal modest experience: I lead a small department (30 to 60 engineers) dealing with cross functional development mainly on software solutions and user support. Our customers are internal customers but we serve people working on very different technologies and in an amazing multicultural surrounding: All big companies are complex. It is important to understand that even if development is internal the competition with external vendors is harsh. For obvious cost reasons I am strongly engaged on converging development in order to share knowledge and assess and avoid valueless internal competition (so easy to say…) .
After agile training and meeting with people like Raj, I decide to transform the department into agile. That decision has been taken in April.
As all projects are involving from 1 to 7 designers (support is not counted here). I wrongly thought we were not so strongly waterfall as that team is almost responsible for all tasks from initial business case, product definition to test, customer support up to end of life of software and solutions. I have first expected that not to be very difficult, I was totally wrong, for several reasons:
Some people were working on more than 2 or 3 projects, lots of people were first to refocus on one ( exceptionally two projects),
Some small project ( 2 to 4 engineers ) were engaging expertise in worldwide virtual team with all lag issues that are in any international project , so need to rethink some project repartitioning ( what we call site-marketing)
Difficulties to find product owner mainly. We also depend on training possibilities and vacation windows.
Agile cannot be proclaimed top down, as a leader I showed clearly the intents, explaining reasons for transforming. But projects choose their own schedule, and could even decide to stay waterfall. This of course needs to be commonly understood and strongly motivated by operational constraints.
Logistics has been easier than expected due to the flexible way to manage offices with common shared open space already available on site ( flex-office).
Today, transformation is in progress and hopefully in quite good shape:
In North America where the team is quite small, training and spirit of Agile has been done for in advance, but they reuse lots of Agile practices (like stand up meeting) even in multi-site projects.
In China, fortunately one of the biggest project designs was already 100% located in China and product owner and scrum master has been quite naturally designated, I will come back on that.
In France where there are lots of strong experts, we succeeded to start the first scrum in June 2010. The team has chosen 2 weeks Sprint duration. As project was initially planned in waterfall this is probably where facts are more interesting to share:
First Sprint has been very positively felt by all team members. The key facts has been to discover within the first 2 weeks Sprint that a one year long development planned in waterfall was not really needed; Product owner discover just that in the Retrospective. Another key positive impact has been influence of the demo to the few users we have. Users are very busy and could not spend lots of time even with the product owner, but we finally succeed to have 2 recognized experts who have been able to give feedback and give so precious input. This was far above my expectation.
One of the drawbacks we clearly have is communication to stakeholder. We need to commit on features sometime in a higher place that the Scrum.
As lots of customers have strong dependencies to our deliveries, they need to know the committed schedule for their needed expressed feature, and it is difficult for them to come to a dedicated meeting: I’ve not yet the solution, but to be honest waterfall was even not matching this too but gives the false impression that since this is planned this will be delivered on time. Here are actions launched after discussion with lots of Agile masters.
We already put on our intranet the Sprint Backlog, but we decided to put the full Product Backlog. For longer term, Product Owner will have a duty to works on theme on Epics so that we get at least something similar to what was done in Waterfall. We need to demo it as working.
Another topic we are facing is organizing level1 and 2 support. As local presence is mandatory this is quite impossible to have co-localization. So for the moment I decided to keep a workforce separated from Agile projects. Overall coordination, training and keeping high motivation is difficult. They are helped by highly skilled coordination people responsible to find solution for end user. For the moment this is not Agile, but I believe that introducing a bit of agility would probably help. Probably need time.
So, I will not today advocate Agile is the waited Grail, but I am known for my strong determination to go further and remove impediments of those who go that way. I will not go into detail, but the road to Agile could not be paved only with good intent: Reality and very rigorous methodology such as Test driven development and other Extreme programming practices to be used every day.
Despite our Heroes, no one dreams to work 24/24 7/7 just for fun. We all know how in reality waterfall project leads some to an unhealthy life, to get just similar to the competition which is just not fun enough.