Although he hadn’t heard of the TargetProcess contest beforehand, Robert just had to win the iPad for his autistic daughter. We never imagined that a simple contest on our Facebook page would bring such joy to someone — but we are delighted and touched that it did.
Robert J. Walker from Mindshare Technologies happened to be making some adjustments to their Kanban board, when a colleague of his suggested that he submit his board to the competition. ‘What competition?’ wondered Robert, but went ahead and submitted it anyway — and won. What of the iPad?
TargetProcess: How do you use the board?
Robert: At my company, we wanted to make use of a kanban board as a passive “information radiator,” something we could have up somewhere conspicuous, allowing anyone to walk by and see the status of the user stories and bugs we were working on. Our first pass on this was using a whiteboard and sticky notes. This fulfilled its purpose, but it meant that Jon Grover, our project manager, had to maintain the same items in both TargetProcess and on the whiteboard, which felt like a pretty significant waste of effort for someone who already had plenty to do. TargetProcess comes with a kanban page, of course, but its design is geared more for interactive work at a computer, and not so much as an information radiator.
Because I found the project interesting, I spent some free time writing what eventually became our kanban board. It periodically queries TargetProcess for the data, so Jon doesn’t have to worry about keeping a separate board up-to-date. Assignable items are shown as little numbered “tickets,” blue for user stories and red for bugs. Effort for those items is shown as a colored “tail” on the item; the longer the tail, the more effort that item has. The boards columns represent phases in the development process, and the effort in each phase is subtotaled at the top. This view is great for seeing the big picture across the entire development department, especially for seeing where bottlenecks are occurring.
It can also be filtered down to a particular iteration or team. In this view, there are fewer items on the screen, so the board allows you to expand the tickets to display the description of each item as well to make better use of the available space. This is great for our individual team stand-up meetings. You can also click on a ticket to view more details, jump directly to that item in TargetProcess, or change its state. We have a new development area with a touch screen in the meeting room, and with a few tweaks I was able to make the board work very nicely with a touch interface.
TargetProcess: How you learned about the contest?
Robert: If I remember right, I had made a couple of changes to the kanban board and was showing them to Jon. He said, “You really should enter this into TargetProcess’s contest.” I didn’t know about the contest, or even that TargetProcess was on Facebook! He filled me in, and he and others on our dev team urged me to enter.
TargetProcess: How do you feel about winning?
Robert: I have a 5-year-old daughter with autism. She’s very bright and my wife has worked very hard with her to help her improve, but she still struggles with communication and social problems. The iPad has been in the news a lot lately as being a remarkable tool in autism therapy. When I heard that the prize for this contest was an iPad, I knew I had to try and win the contest for my little girl. I’m so excited to be able to give this to her and am really looking forward to seeing the things that she can do with it.
One last thing:
Robert does have one request though, one which we are more than happy to help with – April 2 is the fourth annual World Autism Awareness Day. In commemoration, prominent buildings all over the world will be lit in blue light and many people will wear blue to raise awareness of autism and the struggles of those who have it. You can learn more about the event at their web site:http://www.lightitupblue.org.
Once again, thanks to Robert for sending this in, congratulations on winning, and we would love to hear how the iPad works out for you!
Hiring is hard. It really is. There are not so many talented and smart developers in the world, but there are lots of inexperienced, boring, exhausted developers. Surprisingly, so many developers can’t even provide a decent architecture of a simple system! I don’t know how a person with 5 years experience can’t create basic designs, but that is a true fact.
Hiring is about matching. You should find a candidate that matches your company and vice versa. It is not easy. We’ve interviewed about 30 developers over the last several months but hired only 3.
Here is our hiring process.
Initial Email / CV
I pay much attention to introductory email and CV. Things like that make me cry:

Holy shit! Does anybody think I really care about this “2-pages-long-list-of-skills” bullshit? I don’t care how much Linux you did. I don’t care about years of experience in some programming language, platform or framework. What I care about is whether developer can do stuff we need. If we state that we are looking for .NET developer and describe his real job, it means we are looking for a person who can do this job perfectly. No more, no less.
As per our job description, .NET developer is supposed to create architecture for independent components, improve business layer etc. I expect a human friendly email with some useful information e.g. previous projects, problems that were solved, reasons to apply for a job with us and experience and roles outside main job. This email should be quite short.
In fact I’ve never seen a good candidate sending a long skills list. I did invite many people that send such emails and all of them were quite weak for our needs. So, this skills table and a boring CV format are the first sign of a candidate level.
The First Interview. Projects History and Practical Task.
We don’t run phone interviews with developers, we’d rather invite them to a live interview right away (if the intro email is good enough).
For about half an hour I ask questions about previous experience, real problems and solutions. The goal is to find out if this person can really solve problems and to get a general feel about his attitude and personality.
Then we give a practical task — design a simple system. It is a pure business layer design that should be abstracted from database and UI. The system should be easily expandable and simple. Candidates have 2-3 hours to create the design and present it to us on whiteboard. We expect basic knowledge of UML to speak the same language, but it is not mandatory. Ideally we want to see a Class Diagram and (pipe dream!) a Sequence Diagram. How many developers from several dozen candidates draw Sequence Diagram? What do you think? Zero.
Usually 3-4 developers from our team take part in design review. We ask questions, raise challenges and see what happens. How candidate fights for his vision, how he accepts critics, how he explains his solutions. If the result is positive and candidate has some spare time, we do pair programming for 1-2 hours and try to implement the design idea.
This first interview does one thing perfectly: it filters out 95% of candidates that can’t work in our company.
The Second Interview. Theoretical Knowledge.
The second interview is slightly superfluous, but still required, I think. We have a second chance to make sure that this person is really good. We ask questions about various technologies to understand knowledge. Typical questions are “Are you familiar with SOLID principles?” and “What is ORM?” with ongoing discussions. This is not as important as practical skills, but still gives a good overview. I don’t think this part can be skipped altogether.
We ask some questions to tap on how this candidate learns new things. My favorite questions are “Which books have you read recently?”, “What are your favorite web resources?”, “Have you learned something new over the last month?”. Answers to these questions are crucial, as we are looking for people who learn continuously and crave for new knowledge.
We also do more of a personal talk to make sure we can trust candidate and he can trust us.
Then we give candidate a chance to ask as many questions as he wants. Usually people ask 3-5 questions, but one candidate asked about 20 questions after the interview :) (We haven’t hired him, but not for this reason).
That is it. We’ve been using this approach for over several months and it works very well.
Humans receive 95% of information through visual perception. We spend countless hours staring into laptops reading, analyzing, interpreting and feeling information flows. I think visualization is something we lack in many disciplines and project management is not a lucky exception.
Interestingly, latest trends in agile project management do care about visualization. Kanban success heavily depends on great visualization. Everybody loves Task Boards and Burn Down charts in Scrum. As you can see, there is some progress, but I think it is not systematic, just a side effect of other activities. It would be fascinating to create an orthogonal movement in agile project management community that focuses on visualization, I call it Visual Project Management.
There is only one really important rule about visualization:
Visualization should reveal problems, states and trends
Sure, we can add more rules, but they’d be secondary. Imagine you can see a Backlog and diagnose a disease right away:
too large
contains too many old user stories and
grows too quickly
Imagine you see a Board, and at the same instant you grasp all the bottlenecks:
overloaded people
problematic stories
quality problems and
overall development speed
I can’t provide quick visual solutions right away, but I think this approach will change the way teams make decisions and improve their development process.
I wonder why we still have no good visualization tools for project management. I think the answer is that project managers are not strong in design, and designers are not strong in project management. Separation of responsibilities leads to basic, trivial decisions. PM should learn design and data visualization techniques to really invent new visualization. Designer should learn PM domain to invent new visualization. The ideal mix is a team where PM knows design and Designer knows project management.
Let’s review some examples to get a basic feeling of how visualization re-define things.
Why Kanban Board is a Great Step Forward
Information presentation really affects the ways we run projects. Here are two screenshots that contain exactly the same information. You can easily say which one is better.
This is a simple list of user stories taken from TargetProcess (I am working at TargetProcess, so forgive me biased screenshots). It contains quite many data about user stories like state, assigned people, effort, etc. However, this data is hidden. To make some decisions, you need to dig and put some effort into it. It means you have a higher cognitive load. It means you’ll miss some details and sometimes make a wrong decision.
Next screenshot is a simple Kanban Board. While it is not the best example of Kanban Board, still it is good enough to reveal the difference. You see the same user stories on this screen. However, you can quickly identify there’re too many user stories in In Progress state, but it is not critical, since there are no holes in development flow. You can somehow feel that most likely the team is doing pretty good. In some cases you can’t even quickly explain why you think so, you’ll need to analyze your own feelings to provide logical answers.
But the truth is that you have arrived to some conclusion with enough accuracy, really quickly. That is why visualization is so important in any discipline, including project management.
I believe we can have something much better than a simple Kanban Board. Kanban Board visualizes development flow, but misses other important things like people load, local problems, overall progress for all projects etc.
What happens if we have several teams and want to see their work on Kanban Board? Definitely, the board above will not show that. So far, I haven’t seen good solutions to such problems. Software products are not good in presenting large amount of data in an interesting, meaningful manner. This should be changed.
Why Gantt Chart is Misused All The Time
Gantt Chart is a great tool as well. It is heavily used in traditional project management, but often with poor results.
Most of the project charts look the same and make the same mistakes: analytically thin, bureaucratic grid prison, not annotated, little quantitative data.
E. Tufte
This Gantt Chart is quite good and useful:
This Gantt Chart is bad and useless:
Stop. Think a little bit. Can you define the difference? Can you say why I’ve made such a conclusion?
First chart shows quite large project phases. Second chart shows very granular tasks. Gantt Chart is not a good tool to handle granularity. It works best to visualize long project phases, like releases or iterations. It just plain fails to visualize 500+ tasks in a project.
Gantt Chart has a large white space, it lacks information density. Thus it should be used carefully to visualize important information, not everything you have.
I think the frustration with Gantt charts arises more because of tool issues. People’s contexts of use may require information that is obscured by a Gantt chart. But Gantt charts are the dominant (sometimes only) visualization in many tools, and it’s difficult to impossible to extract and present the data in other forms.
Brian de Alwis
These were just two examples of visualization in project management. I believe we can be more creative to provide better tools and concepts, invent new ways to present project information and improve transparency. We definitely can do better. And we should.
I will post more about visual project management. This topic is really intriguing and promising to me.
