High Performance Team
April 08, 2010
For the last 25 years I have been learning about high performing teams and trying to create high performing teams. Well, I finally got to work with one for 3 years solid and I totally loved it.
For the last 3 years I have been working on the IPS project at Husky Energy with the best team and project I have experienced or reviewed. More of a program than a project, we rewrote a number of legacy pipeline control and billing systems in .NET and removed a clutter of spreadsheets and Access applications that had sprung up to fill the gaps left by difficult to upgrade legacy systems.
I had worked with great people before, I have seen the difference good executive support, and engaged business representatives make. However, as the cliché goes, when you bring them together, and add enough freedom to make big changes, the result is much more than the sum of its parts.
Why So Successful?
Freedom to reset and redo - This was a project restart. After several unsuccessful attempts to kick-off the project and then a failed experience with a vendor to out-source it, the project was brought back in house and restarted. I was fortunate to join at a time when management was open to fresh approaches. Already $1M behind budget and 2 years delayed, we were able to introduce changes into an organization receptive to hearing new ideas and changing process.
Executive Support and Business Champion – These terms “Executive Support” and “Business Champion” are often just titles, mere names or nouns. For our project they were verbs that described their everyday jobs. The sponsor fought to retain our budget during cut backs, the business champion repeatedly went to battle to retain resources, gain exceptions from harmful processes and ensure we had access to the very best business resources.
An experienced, pragmatic team – Most of them had “been there and done that with pure agile”, they had seen the benefits and costs associated with pure TDD, XP, and Scrum. They knew all the theory and had heard the theological debates and just wanted to work now. They were exceptionally strong technically, with mature use of design patterns and layer abstraction. Mainly experienced contractors and some experienced full time staff, humility was high and ego’s low.
Great domain knowledge – We had an insider, an architect from some of the original systems we were replacing on our team. The bugs, the flaws, the big chunks of tricky logic from the original systems could all be highlighted and explained rather than rediscovered, a great time saver.
Embedded with our business users – Being away from the IT group and in with the business was critical in learning their day job and building rapport. By seeing their business cycles, busy days and deadlines we were better able to plan iterations, demos and meetings. Being face to face and sharing a kitchen helped with conversations and quick questions too.
Right Process – Way behind our people’s influence on success was our process, using a relaxed interpretation of agile, we worked with two week iterations, daily stand-ups, user stories, and empowered teams. Given we were replacing existing required functionality it meant prioritization and detailed task estimates were less valuable. From a perspective of minimizing waste we naturally gravitated to do less story point estimation and lighter iteration planning sessions. It was reassuring to hear David Anderson in 2008 talking about Kanban and viewing estimation and iteration rigour as waste. We were not just being lazy; we needed a certain fidelity of estimation for planning, but beyond that got diminishing returns.
High Productivity - The last release contained over 1400 function points that were developed in one month by 6 developers. This is approximately 12 function points per developer per day, over three times the industry average and other releases had similar productivity. This was despite the domain being complex, we had a full time PhD mathematician SME (subject mater expert) on the team to define and test the linear programming, and iterative calculations being used.
Innovative Solutions – Rather than hard coding the complex formulae or storing them in tables we built a calculation engine and language with visual editors and debuggers to allow the business users to manage the expressions in the application. We evaluated a number of commercial offerings, but found them lacking in either flexibility or performance and so wrote them ourselves. This, along with some new approaches for agile earned-value based reporting allowed us to successfully submit tax credit applications to the Scientific Research and Experimental Development (SR&ED) program worth millions of dollars - Husky’s first for an IT project.
Project Results – Despite restarting after $1M had already been sunk, we completed within the original budget, delivered more than the requested functionality, met the Q1 2010 target timeline, and delivered a really high quality product that the business is thrilled with.
Obviously it was not all plain sailing, we had many setbacks, but because of the attitude of the team and the business, we got around them all. It may sound strange for an oil company, but in IT at least Husky is “financially very fiscally responsible”. We had little budget for PCs, our machines were old. Our meeting room had all odd cast-off chairs, two tables of different heights, it connected to the elevator service room, so repair guys would wander through during meetings and demos carrying tools and big bits of replacement equipment. We often had to buy our own stationery and many people brought their own monitors in, but we had some freedom to make changes and with this empowerment came more problem solving ability.
We had a project celebration for the team last night and it was great to have the business and IT managers recognizing the team for the fantastic work that they did. Personally, I am looking forward to future projects and putting in place as many of the factors we had here, to once again be a part of a truly high performance team – thanks guys, it has been great!
Thanks for the post! Sometimes all a team needs to be successful is a real life example of how another team reached success. Featuring this post on AgileShout.
Posted by: Katie McCroskey | April 16, 2010 at 07:33 AM
Thanks for reading and the cross post.
Posted by: Mike Griffiths | April 16, 2010 at 08:50 AM