kanban Blog

5 years ago

Retrospectives, Part 1: In Your Own Sweet Way

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

5 years ago

TargetProcess v.2.23.2: RESTful Storage

RESTful Storage

Now you can store your custom data in TargetProcess and use it for various mashups. See the specs. This opens new possibilities in Mashups creation and TargetProcess customization.

GET storage/v1/{StorageGroupName}

Avatars in Kanban

Now you can see avatars for all assigned people.

Better Context Help

Context Help was improved. Now it has links to related articles, blog posts and videos

Other Fixes and Improvements

6 years ago

TargetProcess v.2.23: Git and Bugzilla Plugins, Visual History, Mashups, Tasks on Kanban Board

TargetProcess v.2.23 is already available to all On-Demand customers. On-Site customers will be able to download it later this week. This is the last major release before TargetProcess v.3.

Git and Bugzilla integrations

Git Integration

The long-awaited Git Plugin is finally there! You can integrate both with your local/remote Git repository and with GitHub repository; bind source code to User Stories, Bugs and Tasks, change states, add comments and update times on the fly with a simple Git commit:

#7754 comment: will not be fixed state: invalid time:0.5

  • Change defect states
  • Add comments to defect
  • Update time spent and time remaining

Read more about Git Integration setup

Bugzilla Integration

Bugzilla Integration

The new Bugzilla Plugin is fast and smooth. It imports bugs from Bugzilla showing all the relevant  info right in TargetProcess.

Read more about Bugzilla integration

Visual History for Features, User Stories, Bugs, Tasks and Requests

The visual timeline shows overall progress including all the state changes, time spent, responsible persons, impediments, added and closed bugs, and tasks. It helps to discover problems and waste in Kanban.


Mashup Manager

Mashups help to extend and customize TargetProcess. If you know some JavaScript, you can have fun and create cool customizations right here.

Mashups manager

Quite a number of mashups are available in TargetProcess Mashups Library, for example,  Classes of Services, Quick Add, Kanban Board Comment Counts.

Tasks on Kanban Board

Now you can work with Tasks on Kanban Board! No need to switch to Task Board. Just turn on the Show tasks as cards option in the Customize menu.

Other Fixes and Improvements

#34157 Beta Views: Project view added
#38857 Beta Views: Duplicate bugs functionality support
#37170 New sample project generation

#40866 Retain tags when copying user stories, bugs and features
#41178 Comments missed from old views (Internet Explorer)
#41850 Exception on redirect for OnDemand users if "https only" access is turned on
#17619 Line breaks are not preserved in the required comments on state change
#33264 Test cases: inline image won't appear in test case run
#38088 Release Plan Backlog filtering with phrase tags
#38796 Show Test Run Name in the 'Run History' tab for Test Case view
#39318 ZIP archives corrupt if uploaded via HelpDesk portal
#39852 Permissions: can't delete User Story without admin rights
#40405 Sender email swaps for add/edit comment email notifications
#40620 Exception on clicking the 'Owner ID' link (for a custom report with Requests)
#40703 Filter by Entity Type of ToDo list on Dashboard doesn't work
#40801 "ASP.NET ISAPI is disabled" message after installation
#40873 The Move action for user stories ends incorrectly
#40878 Wrong pages count in some custom reports
#40999 The "Expired" label disappears as the "End Date" field in the Allocations report is cleared
#41004 SVN plugin hangs when someone tries to connect with SSH
#41060 Cascade import doesn't work: session is reset after the first cycle

#41363 Mashup editor shows only first 125 lines of code
#39748 Mashups Manager: Preview mashup (for saved changes only)
#39842 Mashup Manager: Auto convert pasted URL to Placeholder

#40803 REST: exception if custom fields contains "-" (hyphen), : or "
#41284 REST: the count of programs in response on /api/v1/programs depends on Context
#40189 REST: multiple select custom fields support
#40658 REST: create/update/delete Requester

6 years ago

Enjoy Mashups Management and Visual Flow in TargetProcess v.2.22.9

TargetProcess v.2.22.9 is available to all On-Demand customers and On-Site Free users. Public release for On-Site customers is due in several days.

This release is quite significant as it includes a number of major improvements.

Beta Views: inner lists with inline edit and prioritization

Order bugs and tasks inside a User Story. Inline edit on the fly. Read more about improvements in lists.

Ordering and Inline Edit in lists

Beta Views: Implementation History for Features, User Stories, Bugs, Tasks and Requests

This visualized timeline shows full progress including all the state changes, time spent, responsible persons, impediments, added and closed bugs, and tasks. More on how the Visual Flow can help you.

Visual Flow

Mashup Manager: basic release

On-Demand users can create their own mashups in minutes or re-use out-of-the-box mashups. Note: you need Admin rights to create and manage mashups.

Mashups manager

Multi-select custom fields (not available in Beta Views so far)

It's finally there. If you need a custom field with multiple choices, you can now use it.

Multiple Selection

Burn Down calculation when Time Tracking is not used

Now you can have accurate burn downs even if you don’t use time tracking at all. Just update the remaining effort in Task Board and check the progress on Sprint Burndown chart.


Tasks added to Prioritize screen

Order Tasks, Stories and Bugs by their priority for your developers


REST API fixes and improvements

  • REST: Test Plan Run collection for Test Plans added
  • REST: HTTP 500 error for requests if user logged with Windows Authentication
  • REST: exception on resetting custom field value to NULL
  • Plugins: Logs and Data Folder not deleted when TP is updated

Other Fixes

Try for free

Account url: *.tpondemand.com
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy