For the last 9 months I’ve been working as part of the best project I’ve experienced in my career so far. The project has successfully delivered into production 5 times in the space of a year, with only 2 production bugs (each of which were fixed and deployed in less than a day). The real customers are happy due to the successful delivery (and relatively low total cost), and so are the project team due to being able to deliver successfully while keeping a sustainable pace and good team spirit throughout.
So, what’s been the secret of the team’s success? As I roll off the project, I want to write down some of the reasons before I forget.
Great People
The core team is 14 people – 1 Project Manager (PM), 2 Business Analysts, 1 tester / admin and 10 developers (including 1 developer taking an iteration manager role). Everyone on the team has been top quality. The most important attributes throughout the team have been:
– Desire for team success over personal achievement
– Knowledge and acceptance of own abilities and limits
– Willingness to speak up
– Willingness to accept the team’s decisions over personal choice
Individually, the PM is the best I’ve ever worked with. The way he has worked with the business (in areas such as expectation management) has been crucial to both the happiness of the business themselves, and the rest of the team.
Its interesting to note that even though there have been 10 developers thoughout, there has been considerable rotation of who the 10 people are. This has been possible due to the qualities above, and also because of practices like pair programming.
So lesson number 1 for a successful agile project:
Create a great team, and focus on getting an excellent project manager
Use Business Analysts as Customer Proxies
Having an on-team customer is a great idea since it means that developers can quickly get feedback for questions about how a story should be implemented, and also the customer can give early feedback for how a new feature is being developed. (Note I say ‘on-team’ rather than ‘on-site’ purposefully to show that the customer is part of the core team – a ‘pig’ rather than a ‘chicken’ in Scrum-speak.)
The problem with using a ‘real’ customer though is that ‘real’ customers also need to do ‘real’ work, and so there is a a conflict of interest between getting their ‘real’ work done and helping the team deliver the project. (This reminds me of the ‘context switching’ problems Tom DeMarco talks about in his book ‘Slack’). There’s other problems with using ‘real’ customers too, but this to me is the biggest.
So on our project we haven’t had an on-team ‘real’ customer. Instead, we have 2 Business Analysts that act as ‘customer proxies’. The BA’s need to do (at least) the following:
– Talk with the customer groups to come up with a set of features
– Figure out how these features can be coalesced into a set of stories
– Communicate effectively with the developers to explain the problem domain, and the stories to be implemented
– Work with the customers to get early feedback (e.g. from UAT)
Having the BA’s as part of our core team has allowed us to keep open and active channels of communication, enabling early and relevant feedback to issues.
Lesson number 2 then is:
Use a pair of on-team Business Analysts instead of on-site customers
These 2 areas have been about people, and team structure. I think they’re the most important lessons I’ve learned from the project. In later entries I hope to talk about areas such as how planning worked, day-to-day team practices, and development practices.
Mike Roberts