Here are the slides from the workshop that I presented last week, at Agile Brazil 2013, Brasília DF.
From sketches to code, the Agile way
The workshop started with participants coming up with stories and sketches to support a particular scenario. Most things were left open so they were required to come up with something, either by making assumptions or asking some questions about how they could approach their task.
Then they presented to the group. I asked each pair / group the following questions:
- How many stories did you come up with?
- What was the most important or tricky part?
- Was there something else that you would like to add?
Some had chosen the lean start-up method from the get go, choosing a couple of stories to implement before testing this to their customers and proceeding with the rest of the application; some did the traditional way of coming up with the entire design, with icons, welcome page, search… all that jazz.
After they have presented, I then threw a curve ball: the product owner has come back with a challenge and had given one of three different ways that the fictitious company makes revenue. The next task was to ask them to change what they have currently, and re-work their stories and sketches to their new fate(s). Then, of course, they have to present again.
The second round of exercise, the curve ball, was meant to test how much up-front thinking the participants have done before validating their assumptions in their learning journeys. It was a great exercise, albeit painful, to have some of them see that the majority of their work go to waste because they have found out that the curve ball actually had gone against what they had initially thought was the money-maker. They had to scrap stuff from areas they had thought were the most complex, because a completely different functional area was the key in generating revenue. On another level, this was to simulate a situation where they are dealing with lots of ambiguity, and the that they should be thinking about what is the least amount that they should do to validate their thinking, before producing more work that would risk going to waste? In my opinion, a critical element in any analyst’s skill set.
At the end of each exercise, we had a quick debrief on the whole experience, and got them talking about how they had felt when doing the exercise, whether it had mirrored in their real-life experience or not. This was a great way to listen to how some folks might have perceived their usual way of working, contrasting with this particular exercise.
The workshop then ends with a quick walk-through on a field example, with annotated notes on how to deal with tweaking the amount of information you should put into each story that is appropriate to their project environment. This was an eye-opener as I had demonstrated the differences between a co-located team versus a distributed team (for the latter, there were lots of gasping as they did not expect a story to typically include that much more detail).
Overall, it was a really good experience — by the end of the workshop a group had gathered to ask more questions (~30 minutes in addition to the 80 minute workshop, talk about dedication!) prompted by the many areas that we have touched upon, and of course, sharing more experience. I hope I have inspired more people to try out new techniques and to ask more good questions that will help improve the way they work.
Thank you Brasília!