Do you already have an “Extreme Culture” in your XP project?
Do you lead an XP project? Do you know everything about the XP process? Are you aware about the need for the “extreme culture” in your project? Culture is the way things are seen and done.
Your team might not be used to the way things need to be done in an XP project. That has to change and cannot be done by an e-mail or some stand-up meeting.
Changing a culture is difficult and a very long-term task, independent from XP projects – we are talking about humans having to change. And behaving like always is usually easier. Apart from the normal team building process some things implied by the project model XP need to be addressed actively - by you – the project manager.
- Specification-Freeze: Specifications are never finished – make sure you complete them and start developing. Make sure you get to a precision level of 80%, which is necessary for developing a small design and code from that. If you have the right developers they will squeeze the rest out of your customer or yourself during the implementation. If not, then you have a problem – get the right people!
- Change-Budget: Specifications or Requirements will change during implementation – as always - take care about your budget. When you are bound to a strict budget (or even in a fixed price project) you can only handle these changes with a “change-budget”. This budget is necessary to cover specification changes as well as changing already implemented functionality that has to change. If you did not initially agree about the necessary changes in later project iterations, do it now! My recommendation: never start a fixed price project for XP without complete analysis and specifications – without proper specs you will have absolutely no chance to create an estimation that will be sufficient. And if you would be, nobody would believe you.
- Finish It-Attitude: a project iteration of only a few weeks to delivery requires every developer to focus on the small sets of functionality that really needs to be done. It can be a painful mind-change if your people are used to doing everything right the first time. Of course doing it right is necessary, but you can get working solutions without having a full application framework implemented. Try to focus your developers every day on what is really needed.
- Non-Perfect mindset: Many senior members (like the architects) are used and always required to creating perfect solutions. This habit can cause problems because it’s an opposite of the “Finish-It Attitude”. Work with them and give them a clue that their initial design – even if it needs to be redesigned – can be refactored later. It’s a pain, but necessary, to release something that’s not perfect from the own point of view to others – you will maybe know this feeling very well. Your project’s “extreme culture” must allow such non-perfect releases. Explain that from the project kick-off on.
- Non-Can-Do: Make sure you have a good idea of what your team can accomplish. Involve them in estimates whenever possible. Team members with a “can-do”-attitude that work all night and weekends can help you in some phase and you will need them. But please make sure that a team that already works hard for their capabilities does not loose morale because of their direct comparison to your 7/11 workers. And make sure the later don’t spend all their power in the first iterations. Also adjust your project controlling and budgets for 8 to 10 hours max per day (that’s a 25% buffer already) – more shall not be necessary.
- Pragmatic Bright-Minds: make sure your team has enough bright mind developers. The people ware of your project is essential. Pragmatic decisions are essential, as well as the capabilities to analyze problems and create solutions by themselves. Ignore cheap developers or developers that are “available”. Your budget or time constraints are important, but having a B-team to start early and never finish is worse than waiting and rushing to your goals. If you don’t have your bright-minds on the projects you have a problem.
Conclusion:
- it’s about your team – it’s members and their skills and experiences
- the rest are good ideas that they have to incorporate. “Bright-Minds” are needed as converters for changing team culture if necessary
- if you lack professionalism and/or experience in your team you have a problem
How many bright-minds do we need? Let’s try an estimate: at least 60% of your project should be “bright-minds”. Being sarcastic I would estimate that half of them can then do the real work and the other half can coach the remaining average developers. Right, 100% bright-minds would do it perfectly, but that’s far from reality.
How do you define a bright-mind? It’s not only about job years or education. Not completely, but close related. Avoid developers that are programmers by their education, you need those that are born programmers. Make sure you talk to enough experienced developers to understand the difference.
Wish list for your bright-mind developers
- pragmatic and enthusiastic, interested in changing environments
- good analytic capabilities , combined with many years (my minimum are 5) developing experience (hands-on work of course)
- creative and challenged by problems to solve – needing the programmer’s kick.
- thereby often high performance programmers and self-motivated – they bring at least a bit of “Extreme Culture” or result oriented culture with them
- responsible not only for themselves but for the overall result and their colleagues performance
Make sure you have multiple interviews with each developer before project roll-on. Then let the bright-minds help you create an extreme culture over time. You cannot accomplish that alone. If you should have the feeling that you made a false personnel decision after some weeks take the consequences ASAP. Don’t let anyone else do that – it’s your project and your team. Waiting for team problems to vanish or being solved is a major project risk induced by you.
Finally, cheaper developers are more expensive for your project than you might think. They can cost your project.