Why slow sometimes is fast
I am working with a small scrum team which consists of 4 software engineers , 1 product owner and 1 scrum master. Our scrum master is a very active agile development advocator and always trying to introduce new concepts and practices to the team, and then apply them. Currently, we are practicing kanban in developing our software. Briefly speaking, a user story travels through kanban from state to state, which includes backlog, prepping , ready, work in progress ( WIP) and done. We only allow certain and relatively a low number of stories in the WIP so we can focus on getting them done ASAP.
Although kanban emphasizes providing a visualization of your current work for your whole team so they can always swarm together to quickly clean up the stories, that’s not always true. Kanban, like almost all the other agile practices, always ignores the fact that engineers are at different levels, accidentally or intentionally. However, this is always the key point to determine whether a practice will be successful for a team.
As far as I can tell, having engineers with different skill levels in a team is usually the main reason why Kanban actually slows down the whole development, or at least in my team, so we are always trying to get everybody involved in the WIP story. First of all, you, as a quarterback of the WIP story, have to figure out how to split it into several big enough workable pieces and to spend more time on explaining to your teammates the design (and the implementation if they are junior). This communication and coordination takes a lot of extra time. Furthermore because the story is small enough most of the time, the workable pieces depend on each others quite closely. If any of the engineers couldn’t follow the schedule, they unavoidably would slow down others’ progress, which consequently leads the story into a negative feedback loop. This could happen to both senior and junior engineers because of many possible reasons that cause the work not to be finished on time. Compared to the situation that a senior person works alone, this approach in most of times is much slower.
Though this seems bad at first glance, it actually does have many pros that may or may not be able to be evaluated.
1. No engineer could block the story.
2. Force people to think the story through in attempt to split it into measurable pieces
3. Require people to design interfaces beforehand so they won’t step on each others’ toes
4. Involve more people to brainstorm and communicate
So, every coin has two sides and you have to pick up the one that benefits you the most. I think the way we choose is actually better than the “speedy” way in which a senior hero takes over everything. Here are some ideas that I think might make this work better.
1. Have a kick-off meeting with all members on the story and daily ( even hourly ) sync up meetings. Communication is very important here because having more people to work together most likely would lead to miscommunication and confusion if you don’t sync up frequently. In our team, we try to use all possible ways to make the interactions easier. For example, we use skype video calls , instant messages and adobe connect screen sharing for one on one communication. In the meanwhile, we also chat in IRC channel and conference call for group discussion. We have found that these various communication opportunities make the better understanding among the team members.
2. Pair programming. Though I intentionally uses Pair programming , it doesn’t necessarily mean that people need to physically sit together and work on the same screen. The pair could coordinate by using adobe connect , skype screen sharing or even Linux screen session sharing. Paring experienced engineers together could boost the productivity since there are more eyes for sanity check, brainstorm ideas and peer pressure. Pairing Jr. and Sr. engineers is actually one of the most effective ways to improve Jr. engineer’s skill because s/he is able to ask questions about what s/he is lack of and get instant response and training. Pair programming doesn’t mean that you need to work and share your screen with the other 8 hours a day. I always find it’s very useful to spend my time writing unit tests for others’ code alone. Of course, if you are the big fan of TDD, this won’t be necessary. I will show you later how you can make the best use of your time.
3. Fast turn around. Briefly speaking, this means checking in our code fast, breaking the pipeline fast and fixing the bugs fast. Continuous integration is required in our daily development. We setup Jenkins CI server to continuously check out code from source repository and run unit/smoke/functional tests along the build pipeline. These tests and jobs not only give you a chance to verify your code that works on the environment other than your dev box, but also provide a way for your peers to have a brief idea about the quality of your code and how confident they could be when trying to integrate your work.
Nonetheless, no matter how well you prepared, some Sr. engineers still have to wait while the Jr. counterparts implement their work. Here are somethings you may do to kill your time.
1. Work on your tech debt. For example , refactoring your code. In my use case, I would work on putting reusable code into Perl module so it can be shared and benefit more people.
2. Write documents. As mentioned by Dick Brandon, “Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing”. There are various way of documentation, including twiki and perldoc/javadoc.
3. Write unit tests for the Jr. engineer. Get the Jr. people to get used to writing unit tests takes time. They also need to spend time getting their work done. Therefore, writing unit tests for him helps maintain code easier in the future so it’s a win-win situation. However, you need to communicate before he starts his work and define the interfaces / methods. In this way, you can keep a contract between him and you to make writing unit tests easier.
4. Prepare tech talks for your team or your community. You can always learn something from work and would like share the knowledge with your teammates or other folks in or out of your company. Nothing is better than giving a tech talk or lightning speech to improve the whole team’s productivity.
5. Write automation tools. This usually isn’t included in your story, but you always feel so frustrated that you have to manually do some stupid and tedious work repeatedly. As Larry Wall mentioned in his masterpiece Programming Perl, “Three Virtues of a Programmer: Laziness – The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer. Also hence, this book. See also impatience and hubris. Impatience – The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to. Hence, the second great virtue of a programmer. See also laziness and hubris.”
In summary, slow sometimes is fast. With well-prepared coordination plan and better use of time, slowness will be eventually paid off in the long run and make the whole team to be a better one.