01 Jan

Engaging software requirements review

A few months ago Catalyst was asked by a potential client to go through the project requirements with them in a workshop. There were about 120 requirements with the majority being “must have”, a few “should have” and a couple “could have”. The requirements themselves were mostly of a high level nature and thus providing them with an estimate that was not a ballpark was challenging. The workshop was to help us understand details of the requirements.

In this blog post I describe the idea that we implemented for the workshop, describe the material needed to run it and present its benefits. We ran this type of workshop for the first time and thus only have anecdotal evidence of its success. Nevertheless, I hope that it can serve as inspiration to you for re-thinking a similar session you are asked to run and try some of the ideas.

Coming up with an idea for the workshop

Since I heard the word “workshop”, I immediately went into workshop thinking mode. I did not want to have a session in which everyone was hunched over their multi-page 8-point font size printouts of the requirements spreadsheet or try finding the line item in the electronic document and waste time searching for items rather than discussing them.

Recently, I had also read the book Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray, Sunni Brown, and James Macanufo and was all excited not do run a “regular” meeting but incorporate more visual and engaging elements.

Thus, I took a fresh look at the requirements. They were categorized according to functional and non-functional areas and labeled “must have”, “should have”, and “could have”. We had also provided information on which functionalities Mahara, the open source software we were proposing for the project,

  • had available out of the box;
  • required only minimal configuration effort;
  • needed some development effort whose scope was pretty well defined;
  • would potentially need quite a bit of development effort depending on what the client envisaged.

Since the vast majority of the items were non-negotiable requirements, I decided to ignore that categorization. It was also of less importance to keep the topical categorization because we needed to look at the entire solution. Therefore, I focused on the third type of information, namely what the software could already provide and where we needed more information in order to determine whether development work was necessary and if so, how much that would be.

Focusing on the software and the elements already available would also help us show the organization how much they would already get by using Mahara as basis. Most of the time, an organization’s requirements are not a 100% match with any software and thus a minimum of customization is required. Identifying the particular items that would need to be customized is important and also having a good understanding of the effort needed in relation to the available budget in order to suggest functionality to start with and then expand on over time.

My expectations for the workshop

In preparation for the workshop, a colleague of mine in Australia and I had a teleconference to discuss what the organization wanted us to do, what we wanted to get out of the session, what information we had available and how much time we would have realistically. This session was very helpful to me in formulating the first ideas for the session and then ponder them over a weekend without the interruption of emails and other work.

The workshop would need to allow for the following:

  • Engage all participants and not have them get stuck behind computer screens or lost in spreadsheets.
  • Allow participants to get up and talk to each other right at the start.
  • Encourage participants to draw ideas and work flows on a whiteboard spontaneously to support their ideas.
  • Have the requirements that we are discussing present at all times and thus easily accessible.
  • Make it very clear what we already know and where we need more information.
  • Use our time wisely: Spend time only on the items for which we don’t have enough information rather than going through every single item. We probably had a maximum of 5 hours and most likely no possibility of extending the session due to the schedules of all the participants (there were nine from the organization and three from us).

I came up with a card-sorting idea that would take all these expectations into consideration and hopefully deliver.

Note: It can very well be that somebody else already described a similar activity in a book or online resource on facilitating meetings and workshops. I haven’t looked specifically for any. If such an activity already exists, please let me know in the comments.

The workshop objective

The objective of the workshop seems simple enough: Remind participants of all requirements, quickly deal with the requirements that only need clarification and then go over to discussing the requirements that need more information in order to understand them better and thus be able to estimate their development effort.

The workshop preparation

The preparation for the workshop consisted of a lot of copying and pasting, sorting of cards and making hand-written notes so as not to forget elements during the workshop.

Things needed

  1. Project requirements
  2. Template file that contains the cards as well as the headings
  3. White 160g/m2 paper
  4. Four colors, one for each category
  5. Printer
  6. Cutting board
  7. Post-it notes in one color that does not correspond to a category color
  8. Highlighter in category colors (or approximations of them)
  9. Sharpie and pen
  10. Two differently colored voting dots (optional)

Set up the main categories

The four categories in which all requirements could be sorted are:

  • Know / configure: Out of the box functionality, configuration, non-application requirements;
  • Double-check: Some changes may be needed depending on the interpretation of the requirements;
  • Clarify: Know what needs to be changed; no major analysis;
  • Analyse more: Need for more information to understand the requirement.

Non-application requirements such as setting up of a hosting contract, offering user support fall under the “Know / configure” category as they are well-understood and part of the contract negotiation rather than software development.

These four categories are then laid out according to their increasing difficulty and receive a different color each. Initially, I thought of using differently colored paper, but I decided against it because none of the colors that were available went well together. Using white paper and printing color accents on them gives a much more professional look in my opinion. You can even use your brand colors if they lend themselves to it. I was lucky that our color palette allowed for such flexibility and thus I did not have to search for suitable color scheme.

Create the requirement cards

This is the part that takes the longest and is the most important. I transferred each requirement onto an A6-sized card and reviewed the category into which it fell. I also transferred any additional notes that we had already provided the client. Remember, I wanted to avoid that we needed to look up information in a spreadsheet and our proposal document. Therefore, all the information had to be readily available on each card.

You can download the LibreOffice Impress template. I set up each card on an A4 slide and then printed 4 slides on 1 piece of paper to get my desired card size. Only the category headings were printed as A4. All cards come out very nicely on 160g/m2 paper because they are easy to grasp and don’t feel flimsy.

A4 paper with 4 cards on them
A4 paper with 4 cards on them

Here you can see the individual elements that went on a card. Due to confidentiality, I cannot show any of the original cards.

A sample requirements card
A sample requirements card

  1. Provide the number of the requirement so it can be found easily in any document if needed, give it a short title and colorize the background according to the category into which this requirement falls.
  2. Write the word “could” or “should” in this circle if this requirement is optional or use any other word that your client uses to identify additional functionalities that would be nice to have. You may need to shorten a phrase to one word.
  3. Paste the full requirement in this box. If it is very long, adjust the font size. Everything needs to fit onto the front of the card.
  4. If you provided a response to the requirement to the client in the proposal document, paste it in here. This is done in a slightly smaller font to set it apart from the actual requirement’s text.
  5. If this item relates closely to another or is a duplicate, note this down here by mentioning the requirement’s number. This will help you group the requirements later more easily, though you don’t have to think about grouping yet. That is done later.

Transferring the information onto the cards also gave me the opportunity to think about questions that I might want to ask during the workshop for the cards in the “Clarify” and “Analyse more” categories.

Once I had transferred all requirements and additional information onto the cards and verified that they all had the correct category associated (represented by the colored bar), I printed and cut them giving me a nice little stack of cards to process further.

I jotted down my questions and comments on the back of cards for which I did not want to forget a question or additional comment during the workshop.

Group the cards

I now had all my cards and could start on grouping them into themes. These were partly themes taken from the requirements document or very loose themes only to help review the cards more quickly during the workshop. For example, I grouped all green cards relating to graphic design and all that dealt with support questions. I laid out all cards, took a Sharpie and my little post-it notes and went to task. I did not print out any little cards for this task because I wanted to be able to stick the notes to the cards easily and also make adjustments on the fly if needed.

Not all cards ended up in groups. I did not force the grouping but only used it where it was beneficial.

The following shows an approximation of what the cards looked like when we had them on the table at the beginning of the workshop.

The cards all categorized on the table
The cards all categorized on the table

You can see that there are a few green and yellow cards in the “Analyse more” red group of cards. I decided to put them there so that they’d be together with the other requirements that were very close so they could all be discussed together.

The workshop itself

On the day of the workshop, my two colleagues and I arrived early so we could set up the meeting room for the card activity. It does take a bit of time to lay them all out. We also brought flip chart paper, flip chart and whiteboard markers, blue tag and voting dots along. Due to the room’s layout and size, we ended up not using the flip chart paper and only had a narrow walk way between the table and the whiteboard.

The workshop started with the usual introductions of the participants and the aim of the session. After we had outlined the idea for the workshop to all participants, they were game for it and we started right away. As we were informed of the time constraints of some of the participants, we made a couple of adjustments to our plan and left out the voting of requirements which I’ll explain as an option later.

We asked all participants to stand up and take a look at the requirements and their categorization. This was to familiarize them with the requirements again and put cards into a different category if we happened to have them categorized incorrectly. This wasn’t the case though and we could move on to the next phase after about 10-15 minutes. This phase was not intended to re-read every single requirement, but to just get an overview again and take in the requirements that were grouped differently now.

We confirmed that we did not need to discuss the cards in green in the category “Know / configure”, and we could put them aside. Initially, we left them on the table, but during a short break, I put them all on a pile to have more space available on the table. This also had the nice side effect that the participants could see how many requirements were already fulfilled in the size of the stack.

Size comparison of the requirements
Size comparison of the requirements

We went quickly on to the cards in the category “Double-check” and could deal with them within a few minutes as we only needed to double-check with the workshop participants that we understood the requirements correctly. Where no additional work was needed, I took a highlighter pen and marked the card green. I also noted down the result of the discussion on the card itself. We did the same with the cards in the category “Clarify”.

This now left the rest of the workshop to focus on the cards in “Analyse more”. Initially, I had wanted the participants to rank the cards so that we could discuss them according to their priorities. Everyone would have received five voting dots that they could have distributed onto the cards. The cards with the most votes would have been discussed first. For the end of the workshop I had envisaged participants receiving a second set of voting dots in a different color and voting on the cards again now knowing more about the functionality and maybe revising their priority.

However, since I had grouped the cards already, we had reduced the number of topics. Furthermore, one of the participants had to leave early and thus we discussed the topics that were of most interest to him first.

We reviewed each group of cards and discussed their functionalities, what the participants expected of them, why they were important, what work flows they envisaged and where it fit into their program. This was not a detailed review of the functionalities, but did go deeper than the line items in the requirements document and gave us good insight into the reasons for wanting the functionality and what the workshop participants tried to solve. The discussion also gave the participants the opportunity to discuss their ideas further with their colleagues under some different guiding questions and looking at their initial ideas in a new light.

As I was facilitating the workshop, one of my colleagues offered to take notes. This is very important so as not to lose information and also to be able to consolidate the information from the cards with the notes later on.

We finished reviewing all requirements satisfactorily in just about three hours and everybody left on a high note knowing that their opinions had been heard, discussed and that we had focused on the important ideas that needed discussing instead of blindly going through the requirements catalog from beginning to end.

A couple of participants remarked explicitly that they enjoyed this workshop and that going through requirements had never been as much fun before. One of them also wanted to trial this idea in the future. Needless to say that I beamed for pride and was very happy that I had achieved what I had hoped to accomplish with this session.

Take note

There are a few things that you should be aware of to avoid last-minute panic. Some things may be more out of your control than others and you’ll have to make the best out of what you have available. Improvisation is after all an important part of the job.

  • Venue: If you have the chance, check with the meeting organizer that you have a room available with a big enough table, whiteboard, projection screen, Internet access and also enough room for the participants to navigate. Our room was fairly small with a table that was too large for the room thus making it difficult for people to move. There was a big TV available as projection screen, but it took a bit to figure out how to log in.
  • Review the cards: Have your cards ready at least one day in advance and go over them with a colleague who’s attending the meeting as well. You might spot a card that has the wrong category color or is missing information.
  • Last-minute changes: If you do need to make changes to your cards, know where you can print them if you can’t do so in your office. Our workshop didn’t take place near one of our offices and thus printing changed cards proved to be more difficult.
  • Bring all your supplies: This is a no-brainer for most people, but should still be taken into consideration especially if you do not facilitate workshops often. Bring all the supplies that you need so you know you have everything and don’t depend on the venue. Whiteboard markers tend not to work if there are any available and usually flip chart paper is also nowhere to be seen when needed. Also take along extra white cards in case a new requirement pops up and needs to be added. Also have the requirements and proposal documents available electronically.

Benefits

The benefits of running the workshop as I did were clear to me during the session and also afterwards:

  • All participants were engaged the entire time.
  • Nobody got lost in requirements documents, but had all necessary information in front of them on the table.
  • Participants saw visually how many of their requirements were already fulfilled and how few only needed to be discussed.
  • We stayed on track during our discussions as we knew exactly what we had already accomplished and what we still had ahead of us.
  • We finished early because we didn’t spend precious time discussing items that didn’t need attention.

If you think this idea might work for a workshop that you are facilitating, please give it a try and let me know how things go and what changes you made. I’d be interested to learn if it works for others as well.

Update: A slightly less “stream of consciousness” version can be found on the Catalyst blog.

12 Jul

“Replace all” in 2 seconds flat

Last Friday at Beer O’Clock, we saw some awesome visualization of data done by Andrew Caudwell, a colleague of mine. I talked to him for a bit later in the evening and learned that he did not only create Gource with which you can visualize activity on git for example, but alos Logstalgia. With Logstalgia you can visualize website access logs.

That got me excited because for some of our busy servers it would be great to show the actual activity. As I don’t have access to any of our servers myself, I asked another colleague to give me all access logs for one of our sites. I thought I can just plug the log files in and let Logstalgia do its magic. Afraid not.

The log file lines looked like the following and apparently, Logstalgia doesn’t like the part in bold.

81.144.138.34 p: 4580 t: 0 – – [08/Jul/2012:06:25:14 +1200] “GET /group/view.php?id=5734 HTTP/1.1” 200 348 “-” “Wotbox/2.01 (+http://www.wotbox.com/bot/)”

The bad thing is that the values after p and t are different for each line. Now I could go through each line in the access log files (some are over 200 MB large text files), or do it a bit smarter. My text editor Geany can parse POSIX regex, but regex is a book with 1,000 seals to me. Chris Cormack, another colleague of mine whom I can ask anything and always get an answer and learn from him, provided me with the syntax for the POSIX regex and also explained the syntax which I understood much better than on a page on the Internet.

However, the programmer in him said: “I could write you a Perl one liner. 2 secs.” The result was:

cat logfile | perl -e ‘while ($inp=<STDIN>){$inp=~ s/p: \d+ t: \d+//; print $inp;}’ > newlogfile

The advantage of using Chris’ script is that it only takes a second to find all instances of the expression that needs replacing and take them out of the file. It would take minutes if I opened the files in an editor and used the Find & Replace functionality.

Update: The script can even be shorter. That’s what happens when 3 Perl developers are in an IRC channel. 🙂 Chris Hall, yet another colleague, shortened it to:

cat logfile | perl -pe ‘ s/p: \d+ t: \d+//’ > newlogfile

Now all I need to find is an interesting bit in the access log or a day and then I’m ready to create a visualization. Stay tuned for the result.

10 Sep

Visualization for “Support in Using ICT”

Yesterday, on the very easy-to-remember date of 09/09/09, we launched the ICT support web site for our Bachelor in Educational Sciences (BScE – Bachelor en Sciences de l’Education). This web site is an on-going project and will house guides and information to the (ed) tech tools we use in our study program. Currently, a quick start guide about our WordPress MU installation is online, and I am working on a quick start guide for our e-portfolio system Mahara.

Instead of making these materials only available within our Moodle installation, I can now publish them openly online. They may not be cutting edge because others have already written guides, tutorials etc. However, I do hope that students and faculty will find them helpful because they address our particular environments and I can add tips and information that they may need. All that in rather short guides as more extensive information can be found in the general resources for these systems or other user-created material online.

While setting up this support web site and revamping our portal site (now completely a blog) which announces our study program news and events throughout the academic year among others, I fell in love with the theme Atahualpa. It is extremely flexible and you can change almost anything to your liking through an administrator interface.

You can also have a (changing) custom header which brings me to the actual purpose of this post (finally 😉 ). I chose to take a photo of Lego building blocks that I arranged for the specific purpose of visualizing what support for using (ed) tech tools means to me.

My idea of how to visualize support

My idea of how to visualize "support for using ICT"

We use a number of electronic tools in our study program: Moodle as the default VLE for course-related work and for our coordinator team to communicate administrative stuff, Mahara for the student e-portfolios (launch for all students after a test run this winter semester), a CMAP server, WordPress MU (launch this semester), a Facebook group mainly for event announcements, and the YouTube channel BScE.tv with student videos about the study program. Teachers can also work with any other tool, e.g. GoogleDocs. Luckily, we are free in our choice and not bound to one single system. Furthermore, our students always document their research projects with video and / or audio and need to use editing / multimedia authoring software.

In the Lego model, these tools are represented by the big colored blocks. I did not bring in the weight of usage, e.g. represent Moodle with a number of blocks. Some tools are close to each other are used in conjunction. I put them next to each other in the model whereas others are not really connected and thus further away.

The narrow green blocks indicate that some of these tools are used within a walled garden, e.g. when they are installed on our server and access to the content is only possible when you have a (university) login.

The small Lego pieces (mainly in apple green and orange) represent individuals and the slightly bigger pieces represent groups of people. You can see that the individuals and groups use these tools (when they “sit on” them). Of course, they do not always just use one tool, but a varying number. Therefore, they can be seen “sitting on” different blocks.

As there is no support infrastructure for using tech tools in place at the university besides the technical administrative support for these sites, the users help each other and find like-minded people to seek advice. That’s why a couple of the smaller pieces (individuals and groups) are on top of each other. However, the majority of the people are on their own and try to find their way around.

Now the big white bottom part comes into play. That is the support that I envision to advance:

  • to provide up-to-date information on the tech tools we use
  • to make available how-to guides for the tools used by many students and faculty, not just written ones, but depending on the needs and purpose also short screencasts for example
  • to offer workshops on the use of selected tech tools on different needs levels – not merely on how to handle them, but how to use them for their learning and teaching
  • to have short sessions like the Open University’s “IET Technology Coffee Mornings” and ETH Zurich’s “NET à la carte” for letting people get their feet wet with tools / services they may have heard about, but have been reluctant to try yet
  • to have a central “somebody” who feels responsible for giving individual / group support and directing questions that s/he cannot answer to more knowledgeable people; too often people do not know whom to ask or the same issues are discussed multiple times without anybody knowing from the other

The red piece sticking out in the back beyond the white support blocks indicates that it will not be possible to provide support for everything.

The support web site that we just launched is only one little piece of the big white bottom, but it is a start.

08 Feb

Visions with Lego

On Wednesday, February 4, 2009, we had a research lab meeting in which we wanted to talk about the vision for our lab and what we want it to be. The first exercise we did was to visualize our personal vision of our lab using Lego building blocks.

In order for me to have a vision for the future, I needed to examine the current situation and make sense of it first. The result of the state of the affairs is the following:

State of the affairs

State of the affairs

The basis for our existence as research lab is the university represented by the bottom white, red and blue blocks (the university colors). On top of that our research lab consists of smaller and bigger units, mainly projects or research initiatives. They can be close to each other, (almost) touching depending on their research objectives, or they can be rather far apart.

These projects or initiatives could not live without the various people who work in / on them. They are represented by the tiny Lego pieces (I had never seen those before) of various colors stating that each researcher is an individual. These researchers are sometimes also close to each other and at other times not because not everybody has the same research agenda or looks at the same topics. Some of the people blocks are taller representing research lab and project leaders.

Our research lab cannot function in a vacuum and thus there is a green block going outside of the lab symbolizing the bridge to our research unit of which we are a part. The white building block is the research facilitator of our research unit.

The only non-Lego parts are the cake crumbles that luckily happened to be there because one colleague had made a banana cake for this session. They represent the nourishment that we need in order to keep up with the daily tasks. Nourishment is not only meant in the sense of actual food and drink, but also intellectual nourishment in the sense of attending conferences, organizing lectures, discussing issues, attending workshops etc.

What I am currently missing is the umbrella that holds everything together and makes me really see that we are a lab thriving for the same thing. My representation of our lab is pretty colorful meaning that a lot of different things are going on and that there is not really a common denominator. This is not necessarily a bad thing. The University of Luxembourg is not constructed according to common university structure. All research units (there are no departments) are multidisciplinary so that we do not look at the same thing through the same glasses. However, that may work for a research unit where there are 30+ people in it. In our research lab, which is smaller, I am still looking for an overarching commonality that makes me see the difference to our research unit. I hope that we will be able to define what that common thing. It should not be some very abstract notion of “We all look at learning” because then you can fit almost everybody in there. It should be more refined and detailed. I am looking forward to our future discussions.

Vision for the future of our research lab

Vision for the future of our research lab

14 Sep

It’s the end of week 1 as I see it

The first week of the MOOC CCK08 (these abbreviations are already ingrained in my brain) is almost over. I still have a lot of work to do, but have to interrupt it after this post to prepare some stuff for work. Unfortunately, I cannot devote my entire waking hours to the course which I think would be extremely helpful at times to really follow up on interesting discussions and trying to contribute to them instead of just opening them in my tabs in Firefox. I don’t feel comfortable to jump into a very theoretical discourse if I still need to straighten out the basics in my head. Hopefully with time it will get better, my inner optimist encourages me. Of course, I don’t and can’t follow all discussions, but at least the ones that I am interested in should be possible. 🙂

The “Mookies” (Stephen Downes coined that name for people who participate in a MOOC) have been producing a lot of writing, video, concept maps and other visualizations in this past week. The visualizations certainly help me to get a better idea of the connections among us all and to sort out the many participants.

Tom Whyte and Trevor Meister try to come up with visual representations of our networks. Tom has started on the Twitter connections and Trevor put forward his ambitious and awesome ideas in his blog entry “Visual Network Interactions in CCK08“. As of now, Tom had already nine Twitter networks connected and there will hopefully be added many more. There are common connections already within these nine networks, and the network map starts to become complex. Pretty soon, we will need to invest in screens as big as walls and have them multi-touch enabled to navigate through this visualization. 🙂

I order to see where I have been active and to reflect on my sparse activity during the week, I collected all Moodle and blog posts as well as tweets connected to the the course and put them in the infamous Wordle. Of course, I already knew where my emphasis was in the discussions, but maybe I had missed something which could have come up in the visualization.

Wordle of my participation in Week 1 in CCK08

Wordle of my participation in Week 1 in CCK08

Common English words as well as numbers have been removed by the program which leaves the most often used words in the visualization. As you can see, “course”, “can” (isn’t that also a common English word?), “use”, and “moodle” dominate the word cloud. I never imagined being drawn into a discussion on Moodle as much as a I was, but that is what happened and where I posted mainly. In hindsight, this forum, albeit I am not an expert on Moodle and there are participants in the course who are much more familiar with the software, was a safe place for me because I knew the topic, had read about advantages and disadvantages of virtual learning environment, had tried a few myself, have worked with them for several years now and was confident that I could contribute something. Although it was a safe spot, that does not mean that it was not challenging, just not challenging in the same way as if I had tried to wrap my mind around a less familiar topic.

My resolution for the coming weeks is to spread out more thematically to the discussions closer to connectivism trying to geet a better understanding of the theory. I am not sure yet, if the coming epistomological week will actually be the perfect week to start with ;-), but I will try my best and stick with the discussions even though I may be a more silent observer.

For this week’s Wordle, I have tried several versions as the words are redrawn every time you select a different font. Finally, I chose the one above as it gives me hope for my New Year’s course resolution. “Connections” sticks out a bit from the rest of the words and I take that as a sign for the next weeks: Look out for new connections and foster the ones that have started growing and that I want to keep. Connect week 1 with the coming ones.

The gathering of the data I used to feed to Wordle showed me that I will need a different strategy if I want to continue doing that for the next weeks. It’s been only one week and I had to remember where I had posted. It was rather easy for Moodle because you can access all forum posts of one person in the profile. However, for the blog entries it would have been more difficult had I posted more. In the first instance I even forgot Twitter. So I went back there, got my tweets out with Tweetake, the service Tom uses for his experiment, and fed it to Wordle as well. Next time, I guess, I should also include Facebook. The only thing I can think of right now is to paste anything immediately after posting into a document to keep track of. That’s the disadvantage of the distributed discussions, but I would not change that for the sake of ease to gather data. That would be like adapting your teaching to the technology that is available and being unhappy about it.

To end this post on an optimistic note, I am looking forward to the continued discussions, (visual) experiments, live online sessions (I hope I can make the Elluminate session on Wednesday) besides starting the new semester and everything that comes with that.