visualization
Setting out to write a series of articles on agile retrospectives, I looked at some of the sources currently available on the subject. It turned out that most of the books, articles and blog posts have been written by external facilitators or agile coaches, and sometimes in quite a complicated language. I somehow got an impression that – at least in their writings – they prefer to go with the generic recommendations cut out for hypothetical dummy John Doe teams.
So, I’m not going to list someone else’s how-to’s, telling you to blindly follow the techniques acclaimed as best practices. Instead, I’d like to focus on some heuristic essentials for a team to be self-sufficient with their retrospectives. When the essentials go home, the how-to’s are not a problem, they come effortlessly as your team intuitively knows what to do. That being said, I will still mention some of the techniques, questioning their practical value in a team-specific context.
Heuristic Approach
Heuristic refers to “.. experience-based techniques for problem-solving, learning and discovery. Examples of this method include using a rule of thumb, an educated guess, an intuitive judgement, or common sense” (a quote from Wikipedia). Let me reiterate that “experience-based” does not refer to the experience of external facilitators, but to the hands-on experience of a team as they try, discover, fail, learn and move forward. Maybe I’m a bit biased, as we’ve never hired an external consultant or facilitator at TargetProcess. It’s always been our own trial-and-error, common sense and intuitive judgement.
I’m a fierce proponent of heuristic approach to anything, agile retrospectives included, as this approach is about what delivers. No facilitator will do the job for a team, if their goal is to facilitate good retrospectives only. This is similar to using surgery on some body organ, instead of finding the real reasons for a disease, more deep down. Like, the problem manifests itself in the heart malfunctions, but what it gets down to are the extras of the cortisol hormone, caused by stress. So, stress is the reason, not the heart.
Anyway, common sense and critical thinking are not the only universal best practices. Trial-and-error is a great best practice as well, but it does not apply to the heart surgeries (*black humor*).
Feedback Cycles
Retrospectives are one of the best practices for any agile software development methodology with a team-centric approach. You look back, evaluate what’s been done, see what could have been done better and make decisions for the future. Basically, a retrospective meeting can be visualized as a climax of a feedback cycle in a series of loops.
When there’s enough or more than enough feedback, then it’s high time for a retrospective. In Scrum, you can run an iteration-based or a release-based retrospective. If you do Kanban, a retrospective can be run, when a new build is released, or on a just needed basis. From what I’ve seen and read, quite often retrospectives fade out in Kanban, that’s also been the case with our team.
First, as we were doing XP, we used to run retrospectives by the book, for each iteration and for each release. Then we switched to Kanban and experimented with the retrospectives. Now, as we’re about to deliver the completely new TP3, the dynamics has shifted. We’ve seen that the things that used to work for smaller releases, don’t work now as we’re on our way to the new product. So we’ve called ourselves on a retrospective, although we haven’t done one in about 7 months. I’m using this as an example to make a point that there’s no boilerplate rule of thumb for retrospectives. No one, less likely an outsider, can sense the dynamics of your team as well as you do.
The following visual is an anti-pattern for agile retrospectives. If it happens this way in your team, it’s a sign of a serious disease. I’ll cover possible reasons and cures in the next part of the series.
Visualize Retrospectives
When at a retrospective, you need to create a context for discussion quickly. That’s where visuals come in handy. We use screens, wall boards, colored stickers; certain colors may stand for critical-mild-urgent issues to address, etc. But there’s no need to make too big of a deal out of it. Obsessing over colors for stickers will not compensate the lack of team spirit, so first things first.
In fact, there can be a case when the context is already in place, e.g. a team comes to a retrospective already aware of the problems they should discuss. All the same, visuals will display the picture, and people’s brains will be busy making conclusions about the events, not keeping in memory all the events that are the basis for their decisions.
Visuals at a retrospective (or post-retrospective) support the following 3 activities:
1. Discover problems
Historical data needs to be reviewed at a retrospective. The data can tell that everything is going great, or that you’ve got some problems. The trick is to spend as little time as possible on retrieving the data, and focus on the actual problem solving more fully.
Take a look at the cumulative flow chart below, I’ve pulled it from our previous history. It shows that there was a bottleneck at the beginning of December.
As we tracked down the bottleneck, we were able to identify its reasons. The bottleneck was caused by a rather complex user story. One developer worked one month to implement it. During this month we did several releases, and everything went smooth. Then this user story was QAed, and all the acceptance tests were passed. So we decided to merge this story to the main code line.
Unfortunately, after the merge quite many bugs were found in the build. It took more than a week to fix those bugs, and during this time we were unable to release anything, since the merge was already done, and the rollback was quite hard as well.
The lesson learned is to put more effort into testing complex user stories. This particular story affected many places in the application and usual smoke testing was not enough. So we decided to introduce a new class of service (something like a “technically complex story” ) which would require a more in-depth testing and verification before the merge.
The cumulative flow diagram works good to identify bottlenecks. We’ve got another chart, the timeline. It zooms in on the details of a user story life cycle.
This chart gives answers to a number of questions, such as:
- For how many days has this User Story been in this particular state?
- Were there any delays?
- Was there any re-work?
- Who was responsible for the User Story?
- When were Bugs and Tasks added and closed?
- How much time was spent each day?
- Were there any impediments?
So, this user story was in the Open state for 25 days (that is, in the Backlog). Then it jumped right into the In Progress state. Two developers (Alla and Vladimir) started working on it (so it was pair programming). They’d been working for 3 days, and then the story was moved into the Re-open state. This is quite surprising, most likely they had to switch to something else (no good). Then they got back and spent 15 days working on this user story. That’s way too long. Most likely there were switches as well, so this should be investigated. Starting from Oct-18 the progress was very good: development went smooth, the tester found several bugs and they were fixed in 2-3 days. Finally, the user story was released to production with no more delays.
I’ve given 2 simple examples of how we use TargetProcess to support retrospectives. Another great visual we’re using is TargetProcess card rotter.
Historical data can be visualized in many-many ways ( check this article for some inspiration).
You can also go from human moods and emotions to discover problems at a retrospective. Here’s a very simple diagnostics chart, the Happiness Radar (by Paulo Caroli):
People made some marks for the areas they’re happy, neutral or pessimistic about, and we can see that process and technology clearly lack happiness.
2. Solve Problems
As the problems are identified, you need to think about the solutions. Mind maps work great to visualize problem solving. In fact, we do a mind map subconsciously whenever we discuss something and sketch the thoughts on a piece of paper. This simple yet powerful technique can be used at retrospectives as well, and that’s what we’ve been doing. Mind maps can be drawn on a board, or on a screen, or just on a piece of paper.
Check out this mind map. It has been used to think about the problems and activities that influence the speed of development.
Looking at this sketch, you can make a conclusion that only two things can improve the velocity directly: fast feedback and experienced developers (while there are many waste things, such us unplanned work, interruptions, multi-tasking, rework, high coupling and technical debt).
Visualization brings the issue of speed on a plate and breaks it down into smaller pieces:
- How to deal with customer requests and reduce unplanned work?
- What should we do with the urgent bugs?
- How can we do more training?
- How do we break work into smaller batches?
- What should we do about noise and interruptions?
If you ask questions like these at a retrospective meeting, you can expect many good ideas. If you just ask: “How can we work faster?”, the answer might be silence and confusion.
In the previous example, the mind map is built as a network and inspires the goal-oriented questions. The 5-Whys root cause analysis looks into the reasons, so the map would be sequential, going from one Why to another:
I picked up this image from Sandy Mamoli, as the problem they’ve been working on at their retrospective is quite common, and the answers to the 5 Whys are typical.
Now, in line with the Happiness Radar above, that’s how they visualized possible solutions using the “What will increase happiness?” chart with the “keep it”, “more of” and “less of” sections:
3. Follow Through on the Action Items
You’ve identified the problems, pondered over them and come up with some action items after a retrospective. I’ve searched the web through and through, but to my surprise, it seems that very few teams are using kanban board as a visual tool to track their retrospective action items. It appears there’s a reason for that. With kanban, you need to have an opening state and a final state, it’s for straightforward one-time actions. Contrariwise, retrospectives often reveal the need for recurring actions, of which not a single person is accountable, but the whole team. These are the collective ownership items.
For instance, you see that inconsistencies in user stories are discovered only at the final testing phase. You run this issue by a retrospective, and you decide that a user story launch meeting should be done before the start, and the inconsistencies should be taken care of at this very meeting (e.g. the specs should be discussed and approved). So, the action item here would be to include writing functional specs as a task for a user story AND check if all the stories that are currently in progress have the specs.
Back to the problem of over-promise and under-delivery featured above (a very common problem, by the way). Now, you decided to set limits to your work in progress. Someone needs to write mash-ups so the limits can be tracked easily on the kanban board. This is a one-time actionable item.
You also decided that urgent bugs deserve more attention. Someone should think over the process for such bugs.
Here’s a very basic kanban board with these tasks:
On the kanban board below, you clearly see the limits of your WIP, and the red light turns on any time when your WIP rules are violated. No need to keep the limits and the details in memory, the kanban board would send a visual signal about the problem - a helpful follow-through for your retrospective.
Next, about the bugs. They are now tagged “urgent” and “sup”, and they should be tracked closely+comfortably=visually. On the snapshot below, the red cards stand for the “urgent” bugs and the salmon cards for the “sup” bugs (“sup” means “support”). This custom visualization has been done with one of our mash-ups.
There’s also the Team Load mash-up, that shows how much work, and which work, is in progress for every team member. Another good follow-through technique for retrospective action items. Blue stands for user stories, red stands for bugs, team members are on the pics (including Voltaire :)
Continue to Retrospectives, Part 2: In a Sentimental Mood
I started to dig into visualization about a year ago. The topic is fascinating; visualization can be used in a wide variety of applications, including agile software development. I’ve read several books related to information visualization, and I’d like to share my reading experiences. Hope this list will be helpful to someone.
by Jacques Bertin
5/5
This is a remarkable book. It provides a very clean and beautiful theory of data visualization that you can apply to practice immediately. Yes, the book is quite old, but absolutely relevant and has a fresh feeling about it. Bertin and Cleveland are great thinkers, as they’ve come up with some breakthrough data visualization concepts.
The most efficient constructions are those in which any question, whatever its type or level, can be answered in a single instant of perception, in A SINGLE IMAGE.
by Nathan Yau
2/5
This book was far from being at the top of my reading list. Maybe that is why I find it quite dull: very simplistic, useless information on data mining, etc. Maybe it can pass as someone’s first book on the subject, but I think that if you’ve previously read at least one book on information visualization, this one can be skipped without hesitation.
I have to admit. Data checking is definitely my least favorite part of graph-making. [...] But this is what good graph designers do.
by David Sibbet
5/5
The main thing that I’ve learned from this book is: you’d better visualize everything. Yes, everything you say. When you explain your idea, work to support it with some visuals. When you discuss a solution – sketch it. When you create a roadmap or a plan – draw it. Visuals are great helpers and communicators. Even one picture can spark a good discussion and bring new ideas.
Visual language … born of people’s need, worldwide, to deal with complex ideas that are difficult to express in text alone.
by Stephen Few
2/5
A really disappointing book. Examples are so awful that I can’t even look at them. The information continuously repeats itself. I haven’t learned anything new from the first part of the book and just skimmed the last chapters. Anyway, this book is severely outdated.
Dashboards almost always require fairly high-level information to support the viewer’s need for a quick overview.
by Edward R. Tufte
5/5
The famous Tufte books. I can give just one advice: read them all. You should savor the aesthetics of their design, typography and great illustrations. These books are crafted with care. I love crafted things. The content is great as well. Tufte’s work is based on Bertin’s teachings, but it has some novelty and passion.
This book is all about how to visualize things. It has examples from various domains.
There’s a book that you simply must see. Riveting ideas on how to tell compelling stories of cause and effect using numbers and images.
by Edward R. Tufte
5/5
How to display various types of information? This book is not about just numbers, but about many things.
If the numbers are boring, then you’ve got the wrong numbers.
Clutter and confusion are failures of design, not attributes of information
by Edward R. Tufte
5/5
This book gives a great start for any data-specific visualizations. Data-to-ink ratio and sparklines are novelties invented by Tufte. I think this book is the most useful one of all Tufte’s books.
Allowing artist-illustrators to control the design and content of statistical graphics is almost like allowing typographers to control the content, style, and editing of prose.
by Colin Ware
5/5
This book gives answers to how, why, and what we see. Visual perception, encoding channels, color, memory — these things may sound pretty advanced. This book can hardly be considered a straight help reference on data visualization, but it provides a very good basis for understanding various techniques, and understanding is priceless.
If we understand the world through just-in-time visual queries, the goal of information design must be to design displays so that visual queries are processed both rapidly and correctly for every important cognitive task the display is intended to support.
by Bill Buxton
5/5
I purchased this book at the UXLX conference in Lisbon. I did not expect too much of it initially. But after several dozen pages it paid off every cent I’d spent and exceeded my expectations in every possible way. This book is for UX designers, yes, but I’d say every executive should read it. There’re so many gems inside.
Well, this book gives no specific frameworks. It’s just extremely inspiring. Read a complete review.
Without appropriate design, yesterday’s success is tomorrow’s failure, since today’s great applications are tomorrow’s legacy systems
by William S. Cleveland
5/5
Cleveland’s books are not an easy read. They are full of terms and even include some maths. Still they are a must-read for any serious data visualizer. Cleveland has described many useful principles. The book is very practical.
It is hard to imagine anyone reading this book and not getting some good ideas to put immediately into practice.
by William S. Cleveland
5/5
Quite many concepts in this book have already been described in “The Elements of Graphing Data”. This one is more advanced and has more maths inside. I recommend to start with “The Elements…” and then grab this book to learn about the quantiles, Q-Q plots, jittering, coplots and dot plots.
We need more than just the logarithm in our arsenal of transformation methods. Logs cannot be used for data with zeros unless the data are adjusted. And a transformation other than the logarithm is often the one that leads to a simple data structure; in many cases the logarithm can fail to cure scewness and monotone spread, but another transformation does so.
The book ends the same way it begins, with dry data.
by Wolfgang Aigner, Silvia Miksch, Heidrun Schumann and Christian Tominski
4/5
This could be the first book that aggregates all the body of knowledge on visualizing time series: good theory, historical excursus and many real examples. The authors have categorized time-oriented data visualization patterns, and this is a major – and very practical – achievement. The book has no examples, though (it’s quite small for that type of information).
As visualization researchers, we are intrigued by the question of how this important dimension can be represented visually in order to help people understand the temporal trends, correlations, and patterns that lie hidden in data.
Which books on visualization have you read? Can you share your experiences?
How do people perceive information? How designers can thrive on this process to help people understand data faster? Let’s try to look into this complex field and explore some basic principles.
The visual encoding is the way in which data is mapped into visual structures, upon which we build the images on a screen.
There are two types of visual encoding variables: planar and retinal. Humans are sensitive to the retinal variables. They easily differentiate between various colors, shapes, sizes and other properties. Retinal variables were introduced by Bertin about 40 years ago, and this concept has become quite popular recently. While there’s some critique about the effectiveness of retinal variables, most specialists find them useful.
The goal of this article is to provide an engaging introduction to visual encoding, and to give some hands-on examples of how it helps to present data in a meaningful way.
Read the article
About 2 years ago I’ve become very much interested in UX and everything about UX. This interest has eventually evolved into strong awareness of presenting information, visually in particular. One just can’t help thinking in terms of visualization when reading Tufte, Cleveland and Berten. Ideas come pouring in all the time: how to make things more visual, easier to grasp, more clear (in our product, in particular).
I will try to share this feeling and tell more about the principles of information visualization based on some very impressive stories. I beg your pardon for a couple or two boring definitions. There’re no jokes in this article, intentionally. It’s a deadly serious business, so scrape up all your patience and read on.
Disclaimer: the article is quite lengthy. Even so, it’s my sincere hope that you will get over it in no time, as I can’t stress enough how engaging and fascinating the subject is.
Almost 2 years ago I published the Flow. Discover Problems and Waste in Kanban post. The idea was quite simple: visualize the flow of a single user story or bug, and track their life cycle to Done:
You can spot such problems like delays and re-work very fast this way:
Now we’ve brought this idea to life. The Flow chart for every user story, bug and feature will be available shortly in TargetProcess v2.22.9.
The chart gives answers to a whole lot of hands-on questions:
- For how many days has this User Story been in this particular state?
- Were there any delays?
- Was there any re-work?
- Who was responsible for the User Story?
- When were Bugs and Tasks added and closed?
- How much time was spent each day?
- Were there any impediments?
Let’s look at some examples. The user story on the chart below has been in Open state for 25 days (it means, in the Backlog). Then it jumped right into In Progress state. Two developers (Alla and Vladimir) started working on it (so it was pair programming). They’d been working for 3 days and then the story was moved into Re-open state. This is quite surprising, most likely they had to switch to something else (no good). Then they got back and spent 15 days working on this user story. That’s way too long. Most likely there were switches as well, so this should be investigated.
Starting from Oct-18 the progress was very good: development went smooth, tester found several bugs and they were fixed in 2-3 days. Finally, the user story was released to production with no more delays.
You immediately get a high-level overview: delays and up/down state transitions. It is a clear sign of some problems, the systematic ones or not known so far, but we already have some background info to start an investigation).
Let’s check another example. It looks like the user story on the chart below was taken to development right as it was added. That’s true in fact, since it was a customer request to which we reacted immediately. It was implemented in a single day, and there was a small delay before tester took it to the testing phase. We found quite many bugs and fixed them in 2 days, everything is fine. But then the completed user story was hanging in Release Branch state for 11 days, and that’s no good.
We’re planning to extend this Flow Chart and put more information there (comments, attachments, etc.) The goal is to provide the complete production timeline uncovering hidden malignant patterns and problems. You should be able to get a high-level overview in an instant and dig into as many details as possible.
At TargetProcess we develop by feature. This means that all the user stories and bugs have multiple branches. We maintain quite many builds, as branches should be tested one by one. Visual Builds Board shows statuses for all the builds. This simple .NET application retrieves data from Jenkins and TargetProcess and makes it visual.
See the screen below. Passed builds are green, orange builds are running now, failed builds are red.
The board shows where exactly the build is failing. For this one, it’s Unit Tests:
The build below is in progress and 3 phases have already passed. Functional tests are running now:
Here’s a full build history for a particular branch:
That’s how it looks live:
The Visual Builds Board has been created by @AlexSane, @eugenekha and @AlexTsayun
2 weeks ago we made a large roadmap poster out of four A2 sheets of paper and put it up on the wall in a highly popular place, that is kitchen. The poster shows 2 years in a row:
You can see initiatives (or epics) rows. Red line is for an epic start date, green line marks release date. Yellow lines show previous and future expectations about releases, but since we are not estimating stories, these are just expectations. Blue line indicates beta-release. Stories and features are represented by yellow sticky notes inside each initiative. The current day is marked by a thread with a marker attached (yes, we utilize gravity force). Future initiatives are marked with large orange sticky notes.
Here is a quick overview of 2010. We completed only 2 major epics and started 3 more that are still in progress.
Currently we are working on Plugins (this epic has been in production for almost 9 months already) and new Views (the current “in progress” time is 6 months). As you see, we expected to release new Views in April initially, but full JS architecture redesign changed the plans. Quick Add UX activities will be started soon.
Finally, an overview photo:
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.