I’ve been trying to reflect on some of the recent successes we’ve had at work. These successes where highlighted in a recent retrospective we ran last week. Increased teamwork/collaboration, and improved built in quality to a certain degree.
How over the last couple of months has the team seen such a rapid improvement?
The answer is pretty simple really – we have been playing by the “rules” outlined in eXtreme Programming & SCRUM (to a certain degree):
- Test Driven Development
- Planning Poker
- Daily Stand Up’s
- Continuous Integration (to some degree)
- Reflecting on Agile In A Flash cards
- Watching Clean Coders
As one of the Agile In A Flash cards said the other day – we have been playing by the rules, which is something we must keep doing until as a team we are more mature. Once more mature we can start to review the “rules” and adapt them to our situation if they do not fit. Hopefully this will allow us to further satisfy the needs of our customers. In my opinion the most important part of software development.
As a team we probably need to refine our pairing, and having properly defined roles during pairing. How to ensure that both driver and navigator are working together. A common problem is the navigator is distracted. We could simply do the write a failing test then swap, scenario which I have seen work well at XPMan. Another way is to use the Pomodoro Technique. As I’m writing this it’s probably the case that as a team we should decide on a way to pair and follow this for a couple of weeks an retrospect on it!
Test Driven Development is another area that we need to get better at, but I think we know what we need to do – we just need to start doing it!
As you can see there is still much to do, a recent mind map highlighted just how far our team has to go. Some of this is in relation to rules we’ve not implemented and some of this is just to enusre we keep applying the “rules”
We recently had a discussion about what the state of the development community at the moment. I’ve also had a blog post with a comment, where I stated is there a need for a BA!? This centred mainly around the make up of the team and who or what key skills you need in a team. As I’ve become accustomed to being just a developer over the past couple of years which has included either of the following: writing code, or supporting production code. Although this has been my primary role over the last couple of years I’ve come to realise – probably since discussing and studying Agile & XP especially that this is simply cannot be the case anymore.
The main reason for this is due to the fact that XP & SCRUM just has a concept of a team – this includes everyone who is needed to deliver a product or rather something of value to the customer. The idea that when the time comes to deliver everyone needs to be able to help to deliver the product – this is mainly because there is not one person responsible for the delivery – the team is responsible. So this means that if there are tests to complete before the iteration completion date and no development work – then everyone needs to “muck in” to complete the tests.
This leads to teams of individuals with multiple skillsets – as an individual you might for one day have your developer “hat” on – the next day your “hat” is firmly in the “test” ring. Traditional role definitions are probably not well used here and are probably redundant. You are essentially just a team member who has more experience in development than testing, BUT you must be able to help with testing if the needs arise. If there is a bottle neck you must be able to relieve the pressure on the bottle neck – otherwise the “team” will not deliver.
This ability to learn different skills leads me to another important asset of any team member – you must be willing to learn. I think Agile especially encourages this, since everything is an experiment? I was listening to a Podcast with Lisa Crispin and a couple of her final thoughts centred on the need to learn and willingness to learn. It must have struck a chord – because I was skiing at the time! I believe these are key skills for anybody working within in an Agile team.
For me this leads to a couple of core things to look for in team members:
- Willingness to learn
- Ability to adapt to the needs of the team