Disclaimer: Again much of the material below is based on talks by Allen Holub and Phil Japikse at the SDD conference in London
There is an analogy used to describe the various different people involved in any project – that of the pigs and chickens.
Pigs and Chickens
It’s not great to walk around calling people pigs and chickens, but the analogy isn’t bad. Pigs are the people who are committed to the project, like the developers. Chickens are involved, they pop in every now and again and ask for a status update, but aren’t committed. The pigs are the ones who should be making the decisions about the nitty gritty details of the project – i.e. the scrum team themselves.
Agile team structure
Cross training is important. Any developer in an Agile team should be able to pick up any task – everyone should be on the same page with requirements. In fact, the entire team should be aware and understand the requirements before anyone picks up the story. There should be no unnatural dependencies where people “own” different parts of the code – if anyone says the words “my code” this is a code smell in itself. If you are part of a team but start using “I” rather than “we”, you’re setting yourself up for failure.
To see how good you are at cross training, figure out your “bus factor” – how many people can be hit by a bus before your project fails? If you have only one QA, and s/he’s hit by a bus, your project will fail, so your bus factor is 1. This isn’t great, to be honest. (Here, Phil was not willing anyone to be hit by a bus, but it’s an effective way of thinking about things.)
Traditionally, IT teams are organised in horizontal silos, and the architecture demonstrates that clearly. We have the DB layer of the app, handled by the Database team who communicate very effectively among themselves, but not so well with anyone else. Next you’ve got the back-end application layer, who develop the code using data from the database. Again, happy to chat among themselves, but not so hot with talking to anyone else. Then we have the UI layer, managed by the front-end team. We have a separate team of QA/testers to make sure it’s all working as expected, and no one wants to talk to anyone else! And so on…
Agile seeks to change this up, by saying that each team should be cross functional, to develop in vertical, rather than horizontal slices. This basically means that each story/feature that gets taken on is developed fully front-to-back, incorporating any changes in the DB/UI at the same time. Every sprint, we then have something to show users and get feedback on. We need to set WIP limits – or a maximum number of stories that we are willing to take on at any one time – Phil reckons this is 1 + {number of people in the role} (so, if you have 5 developers in a team, we can take on 6 stories at any one time, if you have 1 QA you can have 2 in test at the same time.) The reason we have the extra 1 is so that if we experience any sort of blocker, the developer isn’t sitting around twiddling their thumbs, they have something to work on. This limit cannot be exceeded and is non-negotiable once it’s defined. If we have 2 stories in QA, and a developer finishes a third, they CANNOT move it unless they themselves become a QA to help with the backlog.
The QA sits WITH the team, and commences testing the new bit of functionality as soon as the developers are done with it. S/he is involved in the pre-development discussions around the story, and is on the same page regarding interpretation of the requirements (so s/he can easily ascertain that it works as expected). If the QA falls behind, more developers should become QAs to catch up (because nothing is “done” until QA is done). Again, at no point can we exceed the limits set above.
Swarming is the extreme stage of this, when things reach such a bad state, that everyone has to switch roles for a bit to handle the increased backlog and get the team back on track. This is bad.
If you have QA working with the team, and the team are doing TDD, they can build a much better test plan and test continuously from day 1 rather than doing all the testing in a block of 6 weeks at the end of the development cycle. Otherwise, they will spend time at the beginning creating test plans for things that won’t come in until much later, which there’s actually no guarantee of (as, so far, only this sprint’s backlog has been promised – more on this later). Furthermore, bugs will linger until the end when the developer will no longer remember what it was that piece of code was intended to do.
An excellent habit to get into within a team when wanting to work in a more agile way is pair programming. This is where you have two people working on a task at the same time, on the same machine. In this way, we experience several benefits:
- you pick up skills from every other person in the team
- you don’t “own” any part of the code, because you’ve been collaborating throughout
- you pick up bugs faster, because there’s someone looking over your shoulder telling you when you’ve made a silly mistake. Two pairs of eyes are better than one.
- you get automatic code reviews from your partner
- Those who may have less skills or experience (such as myself) can learn from those with more experience – I have learnt a huge amount pairing with the smart cookies on my team, because I see how they go about solving problems, and can take lessons for myself. They also take the time to explain the rationale behind those methods/decisions which is invaluable for my learning (Thanks guys :)).
Don’t just pair program, pair on everything you do – including refinement/writing acceptance criteria. Let the developer/QA write the acceptance criteria together, so they both have a similar understanding of what that story should achieve.
The hardest thing when moving to Agile is the battle against the architecture, which so clearly reflects the more traditional team structure. The most important step when transitioning to Agile is to modify your architecture to withstand the stress of being flexible. Many large Agile companies spent significant amounts of time simply rewriting the whole system with no new features for a while in order to fit better with how they wanted to work – Facebook, Twitter, Spotify. This method stops all forward progress, so the decision of which approach to take to get the architecture in sync lies with the business. Instead of going cold turkey, you can do this instead in an Agile way – by changing your code in short cycles, but this will probably take double the time in the long run. However, it is not optional – if this is not done, you will meet a lot of resistance when you want to make a change, the architecture will fight you!
aspiringtogeekdom 
2 thoughts on “Moving Towards Being Agile – The Pigs”