One of the most intense and enjoyable events last year was the Ready-set-transfer panel (or: show) at Requirements Engineering Conference. I had the pleasure to present my work on the V:issue:lizer and to argue why I think it was ready for transfer into industry. The following video* (1:46 min) was part of my pitch on why the V:issue:lizer is relevant for software development:
So how can the V:issue:lizer help in this situation? Let’s first look on the visualization of the clarification trajectory derived from the discussion in the video (see a transcript in the making of section below).
To create the clarification trajectory, we start with a simple time line (from left to right). Now, we add each communication event to the time line. We add it below the time line, when it is about clarification and above the timeline, when it is about coordination.
This visualisation is already a very good instrument to discuss the matter with the team during a retrospective. It also allows to compare the clarification trajectory of this feature with trajectories of different features in the project.
But we can do more! Because we know a set of clarification patterns, we can derive recommendations:
We base our recommendation here on the fact that there is late clarification in the project. Using V:issue:lizer in realtime during developing the system could help bringing features with high risk to the managers attention before it is too late.
Note, that I use the video snippets here for demonstrating the concepts only. In reality, V:issue:lizer analyses comments in online repositories. If the organization in our example would like to use V:issue:lizer in future development, their managers and developers as well as potentially customers and end-users should capture their views on the matter as comments to the feature in an issue tracker or similar web-based tool. This might be a good idea: As a matter of fact, we see more and more software projects embrace this strategy of online recorded discussions, and our V:issue:lizer will be able to support these projects in dealing with requirements clarification.
When I announced in the lab that I was thinking about shooting a video, everybody was very excited and helpful. We discussed my vision and several ideas on how to show it. Then, Adrian and I created a storyboard to capture the basic idea. This was also very helpful to assign the roles. The story flows basically as follows:
- The customer comes in and requests development of a specific product. The manager is slightly confused by this request, but does not want to lose the customer.
- The manager assigns tasks to Thing 1 and Thing 2, the developers of the organization.
- Thing 1 starts with developing some safety measures.
- Thing 2 start to develop the product itself.
- During development, observers start wondering if both development streams can be integrated. The intermediate results do not seem to fit.
- After some development, the manager investigates the state of the project. It turns out that development was not well coordinated – not only the two parts do no fit together, but also 180% of the budget was already used.
We quickly found enough volunteers for all roles and shot the video on a Tuesday afternoon in the lab. Another day of work went into editing the video. We were thankful for professional advice and learned a lot. The feedback on the video at RE’12 was great and many people told me that they enjoyed it. The feedback on the overall presentation was good, too – that is: I learned a lot and I am assured that this work will be valuable for industry in the near future. Perhaps I will write about my lessons learned from pitching this work later.
I am very grateful to all participants and helpers: You made making this video fun and it was amazing how fast we were able to put this together. Special thanks to Adrian for helping planning and editing the video!
*) Please note that I do not own or hold the copyright of any music or sound effects in this video.
**) This is a re-post. Read the original article here.