Let me tell you a story... once upon, a time there was a software development team doing scrum. One day the manager decided the team wasn't finishing the tickets fast enough, so he got angry, said everyone was not working fast/hard enough and gave each individual more tickets. When the sprint ended, there were even more tickets that were unfinished than before, and stats-wise the team looked even worse! The cycle continued and things spiraled downwards until the team disbanded. That is certainly not the team that you or I want to be on, yet more often than not this is what "scrum" turns into...
Scrum Naively Maximizes "Solo Work"
The main gripe I have with tools meant for scrum (and managers who like doing scrum) is that you can only assign each ticket to a single person. Let's take a look at a totally made up mock-up based on popular scrum kanban boards.
Scrum divvies up all the work to individuals to work on. Nontechnical managers love scrum because it's easy for them! The manager pushes off all the work onto an individual, and if it doesn't get done perfectly then that developer in the manager's scapegoat who gets a finger at as the one to blame when there's a bug, or the tests are not finished, or the code is not merged on time... Good Leaders, on the other hand, focus on getting the thing done correctly. Then aren't afraid to get into the weeds and know that having the right people working together on the right problems at any given time is immensely more effective than having 15 silos all building their own thing in a vacuum.
If Devs Need To Ask Each Other To Pair, They Won't
This is one thing I've learned after years of coding on many different teams. If you don't build pair programming into the process, it doesn't happen properly (or worse, it doesn't happen at all). Even if you enjoy pairing and have done it many times before, putting a person's little icon on a ticket can have a profound subconscious effect. It just feels natural for the person on the ticket to start his or her day by sitting down and working on that thing. It can seem a bit odd to ask someone, "Hey, do you want to pair program with me on this?! I haven't even started yet!", especially when you see the other person's little icon on a bunch of totally unrelated tickets... and so right there off the bat we see that scrum is designed to completely stifle collaboration.
When tickets are scrumly individualized, virtually all pairing turns in "hey, I'm stuck. Can you help me?" at which point the second person is taken out of his or her own current flow, needs to learn all the context around what this other person is doing, and maybe recommends a completely different approach to the problem... it becomes a huge mess very quickly.
Sure, in theory scrum can work if every individual completes his or her isolated task perfectly so that it matches up with everyone else's isolated task. Each card leans on the next to form the overall tower, but it's just that- a house of cards. Any little thing that goes wrong or person who gets stuck throws everything in the entire world off. Scrum only works if you have a team of extremely introverted coding all-stars who can read each other's minds.
That way of having a team code is not fun, not productive, not efficient...
When tickets are scrumly individualized, virtually all pairing turns in "hey, I'm stuck. Can you help me?" at which point the second person is taken out of his or her own current flow, needs to learn all the context around what this other person is doing, and maybe recommends a completely different approach to the problem... it becomes a huge mess very quickly.
Sure, in theory scrum can work if every individual completes his or her isolated task perfectly so that it matches up with everyone else's isolated task. Each card leans on the next to form the overall tower, but it's just that- a house of cards. Any little thing that goes wrong or person who gets stuck throws everything in the entire world off. Scrum only works if you have a team of extremely introverted coding all-stars who can read each other's minds.
That way of having a team code is not fun, not productive, not efficient...
Pair Up At The Beginning of The Workday
I was fortunate enough to work on a very high functioning XP team before, and one of the things I can remember is that we announced what the pairs of coders would be for the day. We very purposely did not assign tickets to individuals, and we tried to switch up the pairs often so that everyone was always working on something fresh, and it was impossible for someone to be all alone by themselves stuck on something, or to do some odd implementation that no one else on the team would understand. A key tip to doing XP well is to make breaking into pairs a ceremonial part of the standup meeting.
Of course, working on a remote team presents its own challenges, and generally I would recommend aiming for about 2 hours of pairing before and after lunch. This leaves a bit of buffer for preparing before the pairing session, pushing the code or tying up loose ends afterward, taking breaks (which you should do often), fitting in other meetings, and taking care of routine busywork like doing timesheets and compliance courses.
Announcing what the morning and afternoon pairs will be during standup makes it feel a lot more natural to ask other devs to pair, see the work through to the end with them, and not feel there is something else you should be doing.
Another interesting thing to note is that the standup meeting doesn't necessarily need to be "at the beginning of the day". For example, you could have a standup meeting at 1pm in the afternoon, and at that time you announce the pairs for the remaining hours of the day and also the pairs for the next morning.
Of course, working on a remote team presents its own challenges, and generally I would recommend aiming for about 2 hours of pairing before and after lunch. This leaves a bit of buffer for preparing before the pairing session, pushing the code or tying up loose ends afterward, taking breaks (which you should do often), fitting in other meetings, and taking care of routine busywork like doing timesheets and compliance courses.
Announcing what the morning and afternoon pairs will be during standup makes it feel a lot more natural to ask other devs to pair, see the work through to the end with them, and not feel there is something else you should be doing.
Another interesting thing to note is that the standup meeting doesn't necessarily need to be "at the beginning of the day". For example, you could have a standup meeting at 1pm in the afternoon, and at that time you announce the pairs for the remaining hours of the day and also the pairs for the next morning.
Don't Convert a Current Scrum Team To XP- Let Those Who Want To Break Off And Do XP
Trying to come into an existing scrum team and convert it to XP is a mistake, possibly even a worse mistake than doing scrum in the first place! People are biased in thinking everyone is and thinks like them much more than is actually true. XP is not for everyone, and you can't expect good results from those who you force it upon unwillingly. When you have a team of developers who "gel" together and enjoy pairing together then XP really shines. If people are not happy, it's not going to go well. That's why I believe you need to start a new team. Invite individuals (whether internal already or new hires) to join, and be very up-front that you do XP and expect them to be pairing for at least 4 hours per day. It can be very draining and challenging sometimes, and no one likes feeling tricked into something they didn't sign up for.
3 Hours of Agile Meetings Per Sprint
There should only be a total of 3 hours of regular "agile" meetings that developers need to attend.
These are:
These are:
- 12-minute standup meeting at the beginning of each workday.
- 1-hour sprint planning meeting
- 1-hour retro meeting.
XP Feedback Loops
When in doubt, follow this nice diagram that shows the different XP feedback loops. At the very heart of agile development is the idea of shorting the feedback loops, shrinking the time it takes to get feedback and maximizes the number of iterations. Indeed, the word extreme in eXtreme Programming stems from the idea that you have extremely short feedback loops, and since pair programming is just constant, instantaneously short feedbacks loops in the 90s Kent Beck and Martin fowler looked at each other said, "this not only works well- it's totally extreme, dude!".
Image By DonWells - Own work based on: XP-feedback.gif, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=27448045
https://commons.wikimedia.org/w/index.php?curid=27448045
RSS Feed