I don’t believe in agile development anymore.
Our company applied agile practices from day one. We’ve started agile usage in 2006. We tried almost everything: Extreme Programming, Scrum, Kanban and many many small practices. Did it stick? Hell no. Let’s review the lessons.
Daily Meetings
They are just worthless. We used to gather together at 11 am in a single room and report what was completed, what is not, whether there are some blockers. Well, when there are about 30 people in a room these meetings are not fun. They took up to 10 minutes usually, but sometimes they took as long as 15 minutes (I think this duration just can’t be tolerated). After the meeting, people go and grab coffee, chat about problems, chat about ideas… These useless activities distract people and they spend less time on coding.
We’ve replaced daily meetings with a weekly status reports sending via email. The format is very simple with just 7 questions like “Please, enumerate all tasks you’ve completed last week” and “How you estimate your personal productivity on a scale from 1 (low) to 10 (exceptional)”. We collect all emails, process them and have a real stats per person, per week, per project, etc. Really cool!
Iterations
We tried 1 week and 2 weeks iterations. Neither worked out. With short iterations there was a constant pressure to get shit done and technical debt accumulated like a huge garbage heap. It is impossible to squeeze a good solution into a short timeframe. There’re so many meetings like iteration planning, planning poker sessions, iteration demo, iteration retrospective… These meetings are killing productivity, you know.
QA were struggling with short iterations as well. It is impossible to test a user story thoroughly in few days. We tried mini-waterfall in a single iteration — didn’t work, testing phase started just 2 days till the end of the iteration with miserable outcome. We tried to write many unit tests and acceptance tests — didn’t help, since requirements were changing so rapidly. We tried to force developers run manual tests… Well, we lost some very cool developers as a result and removed this practice.
The last nail in the coffin was a loss of a Scrum Master. He fed up with constant rants and got back to coding. He refused to play a Scrum Master role. Without a Scrum Master everything was doomed. Developers reverted to hack-and-fix mode, QA reverted to post-bugs-and-forget mode. Chaos replaced everything. Then we decided to try Kanban.
Kanban
We draw a very cool board with 23 states and placed everything into it. It looked awesome. We used color coding, we used real photos and some clever rules. For example, when a user story stayed too long in some state, we stick some funny blame words above the assigned person’s photo (like “stupid snail” or “you’ll never complete this task, hahaha!”). This really motivates to get shit done faster, you know.
With Kanban you have a luxury to implement feature as slowly as needed. No pressure at all. Well, we didn’t like the overall velocity though and decided to bring deadlines back. Deadlines were set by top management. All features started before the deadline should be completed and released. It lead to quite a few games between developers and managers: developers resisted to take new features when deadline was close, managers tried to put as many features as possible before the deadline. Sometimes developers had to work 100 hours per week to make a release. And that is NOT a joke!
We tried to put limits in states and review the flow (23 states are too many). It helped a little, but managers decided that limits restrict them and removed the limit from the In Progress state. A month later everything was In Progress.
So Kanban didn’t help us as well. However, we learnt that visualization is good and tried to apply it everywhere. We’ve tried various visualization techniques to increase transparency and productivity. For example, we tried to visualize builds statuses, work progress, future plans and roadmaps — without any success.
Here are the things that are really helpful:
Wall of Blame
We had a nice and visual “Wall of Blame”. Developers with the worst individual velocity for the last month were mentioned in a Dilbert-like comic strips. It was updated every 1st Friday of the month and this day even got a special name in our company: ”Blame Day”. People that appeared on a Wall of Blame were no rights to defend themselves in a Nerf Battle this day. Oh, these days were so funny!
Wall of Heroes
This board was right opposite the Wall of Blame. Naturally, top coders and top performers occupied this board. Their photos were very professional (we hired a good photographer to make them). The photos were in gold frames with engraved titles like “Jonny Summer. Top Lead Developer. March 2012”. Well, some photos required a serious makeup, it is hard to look good after a 100 hours work-week.
Curses Chart
We invented Curses Chart to measure fuck ups in projects. Every room has a recording device. We record everything. Speech analyzing software is used to extract curses from all records. These records are accumulated and a day-by-day chart shows how many curses there were. This chart is displayed on a large TV in the kitchen. Also it rotates recent exceptional curses. We found out that the correlation between curses and fuck ups is perfect.
Pair Programming
We tried to enforce pair programming and decide how good it is. Did it work? Nope. People were constantly arguing about things, trying to find the best solution. In the end they we reluctant to talk to each other at all. There was a case when a lead developer hit his teammate with a Microsoft keyboard and broke his nose. After this incident we replaced all Microsoft keyboards with Logitech keyboards (with soft keys) and banned pair programming practice forever. Now people can’t talk near a workstation, they have to walk into the meeting room and talk there, sitting in soft chairs.
We tried many more other practices, but this post is already too long. I’ll post more exactly a year later.