Tag: workshop

Hands On Introduction to Agile: reflections

So last night after work I went to the Cleveland Agile meetup, where we did a “Hands on Introduction to Agile” workshop. It was really fun. Even though I’m reasonably well acquainted with Agile concepts, I got a lot out of the experience.

We didn’t use computers or programming in the workshop, which made the event accessible to non-technical people who didn’t have specialized skills.

The workshop was split into two exercises.

For the first exercise, we split into four groups of about 6 people. We were sitting at tables, and each table had a pile of Lego pieces. We were instructed to split the pile into halves, and then spend 60 seconds sorting one of the halves, according to whatever sorting method we felt like using. We quickly sorted our pile by color.

Then, the facilitator re-assigned my team to work on the project on the table next to us, and told that team to work on our project.

The other team who’s work we inherited had barely done any sorting. All they had managed to do was take the pieces that had wheels and separate them from the rest.

Our project was to build a structure using each type of Lego piece only once. No duplicate pieces were allowed. We weren’t told what to build, just to connect bricks together. Our team split into two groups, one for each pile of Lego, and each built a structure. We quickly re-sorted our badly-sorted pile, and then did a second-order sorting to weed out all the duplicate pieces, then assembled the rest into a disorganized hodgepodge structure that had no architecture or form. We barely had enough time to do this. The other half of our team took the unorganized pile from the first sort, and did their own structure.

We were asked which half of the Lego piles was easier to work with, and obviously the sorted piles were better to work with. It was much easier to pick out the duplicate parts from the sorted piles, so construction from the sorted piles went faster and smoother.

I was expecting we’d do another iteration, and that it would involve changing the structure in some way, and so I was worried that the haphazard, planless structure we had built would be unsuitable for modification, and that this would teach us another lesson about the value of planning architecture, or refactoring, or maintainability. But we actually stopped with the legos at that point.

I asked the facilitator what we might have done had we been asked to do another iteration, and he said maybe it’d be a project to combine the two structures that the two halves of the team had built, with a requirement that we keep to having no duplicate pieces. I thought that would have been pretty interesting.

It’s too bad that I didn’t think to take pictures of the stages we went through, as it would have made this article a bit more fun to read, and easier to understand, I think.

For the second half of the workshop, we split the participants into two groups, counting off by twos. Ones were asked to find a Two to partner with on a project. It happened that we had an odd number of people, and I was the odd man out, so I was joined to a group, creating a group of three. This turned out to make the experience more interesting for me.

Once we had our pairs established (and my triad), we separated, the ones stayed put, and the twos went to another room, where we talked for about 10 minutes about why we were interested in Agile, who among us were actually “developers” in real life, etc. It was just conversation to pass the time. After ten minutes, we went back to meet with our partners. They were the project’s business requirements stakeholders, and had written up instructions for us, the project developers. They handed off the instructions, and before we were allowed to read them or ask any questions, they all left the room. We developers were given ten minutes to figure out the instructions and follow them.

The instructions were to draw a figure. The instructions were difficult to understand. We didn’t know *what* we were drawing, only a description of the various aspects of the drawing. The instructions specified the color of the lines, and described shapes that the drawing included, but it was hard to visualize from the written description. We muddled through it and did our best to figure it out, but we were not very confident in what we produced.

It turned out that our drawing was reasonably close to what was asked for, but the lesson we took from this was that the process was more difficult and less certain than it would have been had the “business requirements” person stayed with us and been available to answer questions and provide feedback to us as we were working.

After reviewing our drawings and discussing how we felt about the experience, we switched roles. The Twos took on the role of the business requirements analysts, and the Ones departed to allow us to work on instructions for how to draw a new drawing. This time, though, the business analysts were allowed to stay with the developers while they worked, and the developers were allowed to ask us questions. We business analysts weren’t allowed to interfere by volunteering feedback, but if the developer had a question we were allowed to answer it.

Since this was the second time we were doing this, and we both had a little bit of experience with it, and had seen the previous finished product, it was a bit easier. But being available to answer questions made an even bigger difference. We could eliminate the uncertainty in the developer’s mind about what they were trying to draw, and give them confidence that enabled them to move forward with each step successfully completed. The finished drawing was extremely close to the model this time; only if we’d been able to provide detailed measurements of line segment lengths and angles would it have been able to be improved.

For me, working as a pair team, this experience was more interesting. I not only had to deal with the written instructions, but I also had to figure out how to work effectively with the other developer on the team. I don’t often get to do real pairing, and working with other programmers has always been somewhat mystifying to me. So this was a good opportunity to try to figure out ways to work effectively.

For our first project, I tried to decipher the instructions step by step. It seemed that some of the steps were very complicated and difficult to understand, while others were relatively simple and straightforward. It occurred to me that we might run out of time trying to figure out the very complicated steps, and not get to the simpler steps. So I volunteered the idea that we should try to draw out the parts from each step separately, then figure out how to combine them. Tackling the project in a modular way seemed like a smart idea, but since we didn’t have the means to cut and paste the drawing elements, it meant a bit of re-work as had to we re-draw the bits from each step that we’d created during what essentially had turned into tiny sub-iterations for the “release version” of the drawing. While this did take some extra time, I think the final drawing ended up being better for it.

The instructions were not very well organized, either. When I got down to Step 7, I found that it referred back to Step 2, providing some additional clarification, but in a way that would have made us have to throw out the work we’d already done on Step 2, if we’d done Step 2 without first reading the entire set of instructions. We ended up drawing the different parts from each step separately, then puzzling out how to fit them together — the instructions were probably the least clear on this. They specified that lines should not overlap and that the different parts of the drawing should all connect, with no un-attached line segments, but it was unclear how exactly this was to be accomplished. What we ended up with was pretty close to correct, but we really had no idea how close we were until we saw the “prototype” drawing that the instructions described. But I did find it helpful to have a partner who I could discuss with while puzzling through the instructions together.

When it came to writing up the work instructions for the second iteration, partnering wasn’t easy either. We ended up just writing up our own instructions separately, then comparing what we’d come up with, and picking the superior of the two, which happened to be mine. Mine was clearer, simpler, and more complete. But again, having a second pair of eyes helped, and my partner made some suggestions to improve a few minor points that needed additional clarification. When our developer came back and worked on the instructions, he only had two or three questions as he followed the instructions, one of which was a matter of not being able to read my handwriting, the others being about specific angles, which I’d been somewhat vague about. But his drawing was very, very close to the shapes and lines we were describing, correct in all the major details, and only off in terms of specific lengths and exact angles, which we didn’t have time to measure or describe in the time we had to create the instructions.

Figuring out how to work effectively with someone on a project is always a challenge for me, especially with people who I have not worked with previously. But it seemed to go very smoothly with these exercises. In part I think this was because they were especially simple, and it didn’t seem like there was a need to do a lot of discussing about who should do what, or how to do it. We just sort of dove right in, and did it, and we didn’t seem to get in each other’s way all that much, if at all. With more complex, more serious work, this doesn’t seem to work as well, and I have yet to work on a real project with a pair programming approach. I would really like to have this sort of experience sometime.