3 years ago I wrote an article that describes changes in our software development process from 2008 to 2012. Now it is time to review the last three years. Meet the new articles:
Trello is a really cool tool. It is simple, fast and helpful. And free! You can create boards for everything: Hiring, Product Development, Customer Requests, Personal ToDo, etc. Trello has a solid mobile support, real-time collaboration, passionate community and many add-ons.
However, with company growth, you start to feel limitations. You want to see cards better, customize what you see and what you don’t see. You want to manage 100+ cards easily, without constant scrolling. You want functionality that previously you didn’t need, like time tracking, sorting and more.
Targetprocess solves many problems that Trello can’t solve. However, it comes with a cost. Targetprocess is more complex and has some learning curve. Are you ready to put some effort to overcome Trello limitations? You decide.
Trello is not designed to work with huge amount of data. If you have a board with at least 100 cards it looks quite messy. No zooming, no collapsing, limited filtering. You don’t know the solution maybe, but you feel that something doesn’t feel right.
In Targetprocess you can collapse columns and see cards as small boxes. You can hover on boxes to see additional details. You can even drag and drop these small cards into other columns. Collapsing helps you to hide information quickly.
Moreover, you can zoom in and out to see more or less details on cards. If you have 10+ cards in a column that may be extremely handy. Just compare the picture above with the picture below:
Let’s take a more complex case. Sometimes you have a huge backlog with 100+ cards. Not good, but happens. How to manage it in Trello? it is really hard I should say.
Let’s take a look into Targetprocess. Here you see a Kanban board. It looks like backlog management is bad here as well. You see just 7 cards from backlog, while the other 121 cards are hidden.
Now let’s focus on just two columns: Planned and In Dev. You see much more cards on a single screen and can do something with them: set priorities, move into development, etc.
Still it is hard to skim through backlog in this view. People like to skim lists, not 2D boards. No problem, zoom in to see cards in a list-like mode:
Next time I will show you some killer features in Targetprocess like multiple selection and batch drag and drop, powerful filters, sorting and swimlanes.
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.
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!
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.
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.
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.
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.
UPD: OK, it was 1st April post. Truth is here.
My new article about process changes in our company.