thekua.com@work

In considering a leaner approach to software development, many people in the agile community are starting to turn towards an iteration-less approach. Wayne Allen talks of trialling No More Iterations, while Amit Rathore talks about an iteration-less agile process. Heck, I’ve even given it a go with a couple of my projects. On the other hand, there’s a whole movement in Italy devoted to the Pomodoro (Tomato) Technique that focuses on time-boxed activities.

So who’s correct?
The short answer: They both are.

Photo of a “time box” from Great Beyond’s Flickr stream under the Creative Commons Licence

The long answer: When you compare people not working in an iterative fashion (i.e. one phase of analysis, one phase of development, etc), to those agilists now turning away from iterations, there’s a noticeable difference, and is what I will call, discipline.

Those arbitrary time boxed units that we call an “iteration” creates cadence for teams. Cadence in turn creates rhythm, where teams can focus better on developing the healthy habits associated with agile software development. Much like the way that beginning martial artists repeat katas, it helps the Novice, Advanced Beginner and the Competent (Dreyfus Model) understand each practice individually and develop the discipline to make them effective. They don’t need to worry about which practice combines best with other practices, and yet, still see some benefit. It helps the team synchronise, predict and potentially even enforce when activities happen, giving people the stability they need when they are learning. It forces people to make important decisions that, without the associated discipline, end up deferred.

In absence of iterations, you need a guide to achieve a similar effect to encourage people to use the practices in an appropriate order. I argue that those people who are Proficient or Expert (Dreyfus Model) don’t need the iterations because they understand when to use what practice and the value it brings. They move towards what looks like an “iteration-less” approach because they are instinctively doing things iteratively without the arbitrary time box. They have enough discipline to ensure all the activities happen at the right time without causing disruption. Unfortunately, in my experience, many never make this jump to being Proficient or Expert.

What to do about it?
Iterations are useful, with that usefulness limited to a certain context. The learning level of the people involved heavily influences this. Respect the needs of the people you work with, and understand that jumping into “no iterations” requires a level of discipline you won’t achieve without people reaching these later levels of mastery.

Comments(7)

One of my most memorable conversations during training went something like this…

Student: Aren’t these just best practices? I don’t see how this is agile estimation. How is this agile?
Me: Hmmm. I guess they are best practices. I see many agile teams frequently apply all these techniques when they do some estimation. Let me ask you about your current project. Do you get people who will do the work to give you estimates?
Student: No. Either we have a group of architects to estimate the work, or I estimate the effort for the team.
Me: Do you try to make make sure more than two people estimate?
Student: No. One person should be good enough to estimate.
Me: Do you try to understand or uncover the assumptions that person is making during estimation?
Student: Sure. We ask them to write their assumptions down.
Me: Do you use relative estimation?
Student: No.
Me: So you’re telling me that even though these are best practices, you’re not necessarily doing any of them?
Student: Yes. But I don’t see how this is agile.

When people get fixated with disagreeing about something, they stop listening and stop learning. Drawing them out of this corner can be a really difficult task. In this particular case, the student wanted clear evidence that agile was something else and wasn’t prepared to hear about estimation best practices being normal best practices when working in a most agile methodologies.

Comments(0)

I’m a big believer in letting people try things out. Unfortunately, most training programs don’t let people do this enough. In fact, most of the time, training is seen as some way of “fixing problems” or a “all-in-one solution”. I can tell you a simple reason why training fails… people don’t have support to actually use the things they are trained on. They don’t get the essential feedback loop in their real environment and they quickly forget what they learned.

It’s all fantastic when you have an opportunity in class to try what you learned out. What really matters if whether or not you have long term lasting support in your environment to apply it to what you do. Unfortunately most training programs fail to address that, or the trainers don’t feel like it’s something they can influence.

Training lasts a day. True learning lasts a lifetime. If you send people on training, make sure they have a safe environment to apply it as well. Don’t view training as a silver bullet. Use it as a tactical solution as part of a larger strategic initiative.

Comments(3)

How you facilitate a retrospective impacts the success for a retrospective. Inexperienced facilitators often don’t know how best to achieve the Decide What to Do part of a retrospective, often resulting in action items too broad, or too difficult to actually achieve. Revisiting them next time results in frustration as the team hasn’t made any progress on them.

Photo taken from Opheliates Flickr stream under the Creative Commons Licence

What you can do about it?
Sumeet writes about using SMART (Specific, Measureable, Achievable, Relevant and Timeboxed) to help focus forming better action items. He also writes about giving them an owner and a time frame. I will often use this to guide the discussion – “Is this achievable in two weeks time? How can we break this down to ensure we make some progress? Does everyone understand what you need to do to call this item complete?”

I also like Bas’ Plan of Action approach, linking short term actions with long term goals – allowing people to break down large changes into more achievable ones, or to help align short term tasks with longer, more strategic goals.

As a facilitator, be aware that how you deal with the last part of the retrospective will influence the result, for better or worse. Learn how to facilitate the group towards something more likely to result in an observable change.

Comments(0)

Ever been in a meeting where the organiser doesn’t really know why they brought everyone together, or even have an agenda to start with? It devalues your time and you feel pretty frustrated. I’ve seen the same happen when facilitators don’t prepare for their retrospective. Preparing well demonstrates to participants respect for their time. Conversely a clear lack of preparation shows disrespect. Even though it doesn’t guarantee it, proper preparation ensures a better chance participants will be more willing to engage.

Image taken from Meredith Farmer’s Flickr photo stream under the Creative Commons licence.

What to do about it?
In preparing for the retrospective, I like to go through this list of questions:

• Who is the sponsor for the retrospective? - Sponsors may have extremely different agenda. Some of it may be about spreading lessons learned, others just want to understand the root cause of some major problem. You want to be clear about who the sponsor is and why you’re even running a retrospective. Is there just one person, or are there more of them?
• What are their goals, and what are you going to end up by the end of it? - Looking for ways to improve client relationships will have a completely different focus than understanding what new technical innovations came out of the project. The goals will heavily influence what exercises you plan for.
• Do you know how long the retrospective will be looking back? - Planning to look back over 1 week will be different from 3 months and different again from 1 year.
• Do you have an idea about what topics might come up? - A retrospective for a project where significant negative events dragged the team at certain stages will be different from a retrospective for a project that had less troublesome issues.
• Have you planned for enough time to cover everything? - You want to have enough time for people to tell their stories, unload any emotional baggage and get to understand what lessons are worth sharing.
• Do you have a good representation from team members? - Just having development members in a retrospective will skew what you talk about, perhaps missing important elements all the way from the sale, client relations, etc.

Just before starting the retrospective, also ensure that you have all the materials prepared - this may includes markers, pens, paper, sticky notes, handouts. Also ensure you have the room prepared with any posters or whiteboards you plan on using.

Comments(0)

One thing I’ve noticed agile projects tend to do is to push relevant information out to people, and be extremely honest about how things are going. Here are my attempts at doing so:

• Posters Around the Workplace - Finding time to showcase progress to my stakeholders is like trying to hold a wriggling eel in water, so I thought of hanging some eye catching posters on the noticeboards. I decided they’d be good for two purposes - the first to help give stakeholders an idea of what I’ve been doing with training since we met about a month ago without the need of scheduling another meeting, and the second, to market towards potential people who’d have an interest in attending. In about an hour, I ended up with a poster (see the photo) that included what topics I have material for (and what I have planned), photos of outputs from the training including snippets of real feedback, and contact information for more information. I purposely left two spaces to update the colour poster with two pieces of information, just the right size for sticky notes. I’m currently filling one indicating the number of people who’ve participated so far, and the other, the number of classes I’ve run.
• Mini Card Wall - Keeping track of all the tasks associated with material development, scheduling training, meeting with people is becoming difficult so I’ve put up a mini card wall using the desktop PC I have next to my monitor. People around me can take a look at the things that I need to do, and as new requests pop up, I can quickly add it to the list of items still open using the pen and pad of sticky notes I have nearby. As you can see from the picture, all I really care about is whether or not something is open (needs my attention eventually), in progress (reminds me of what I’m working on) and done (I remove these at the end of the day).

Comments(0)

In my experience, achieving high quality is a key part to being adaptive and nimble. Continuous improvement and responding to the feedback allows you to achieve high quality. Here’s what I’ve applied to training so far:

• Set design and collaborating ideas - One approach I could have taken to developing the material included simply writing the content, trainer’s guide, handouts, etc and run it with a single class before trying to change anything. Instead, I came up with a few options, bouncing ideas off someone else who’d run training before and asked them, “I’m thinking of trying something like like …, I imagine it would work like … and we’d achieve … What do you think? What discussion would this generate? Would people find it engaging?” It stopped me detailing things too early and putting in too much effort that would need rework.
• User Centred Design - For some of the worksheets, I applied some principles from Don’t Make Me Think, testing them out with some users to make sure they needed as little instructions as possible. It’s important for students to have a good experience with everything to do with the course. You can see the evolution by looking at the picture above - it’s a worksheet for introducing the concept of velocity for the XP Lego Game.
• Finding the right metrics to use - I’ve already changed my feedback forms since running the pilot programs, looking at what information I actually consume and how people use it. I used to have a two-page feedback form, the first including instructions and a focus on multiple choice answers, with the second page using a more free form format. Since I hand them out in class, I give verbal instructions and removed the detail blurb I had at the top. I also condensed the form into a single page, and focused on three key questions I am more interested in - “What did you like best about the session? What constructive changes would you suggest to make the session more effective? What else do you want to know about?”

Comments(0)

I’ve been leveraging my experience with agile in teams and development and applying it to what I’ve been doing in training. Here’s what it looks like:

• Review material before class - Executing the material with an audience is the slowest part of my feedback loop. Instead, I’ve had a few people review different parts of the material during and after I’d developed the material, constantly seeking people who might give a different perspective about the content, delivery techniques, etc. Some of them involved a detailed walk through, others a brief, what do you think response?
• Gathering feedback from classes - I’ve had a chance to run some pilot classes, gathering effective feedback to consider changes. I also try to set some time aside after class, capturing notes around how effective I thought some of the classes ran, looking at ways of improving them.
• Eating my own dog food - The trainer’s guide is meant for someone else, and as difficult as I find it is, following a guide you wrote, I try using it to plan out the classes I run to see how well documented it is.

Comments(0)

In the spirit of Goldratt’s understanding of metrics, “Tell me how you are going to measure me and I will tell you how I will behave,” here are some questions I ask myself when I play the role of a Technical Lead.

Picture of Einstein figurine taken from Dunechaser’s Flickr stream under the Creative Commons Licence.

• Have I fostered a learning environment? Do people feel safe to make mistakes, and more importantly, learn from them and share them with the rest of the team?
• Have I fostered an attitude of continuous improvement? Can people talk openly about what they see on the project, determine what impact it has or how people feel about it, and encourage more of it (if it’s a good thing) or try something different (if it’s less than ideal). Do people feel empowered to do things without feeling like they need authorisation every step of the way.
• Does the development team collaborate well with the other parts? Do they talk to other people with respect, and do they try to involve them as much as possible where it makes sense?
• Does the development team balance the needs of the business with the demands of the technology and toolset? Are they doing what’s right for the business in the long term? Do they share the same vision?
• Do I act as I say? Even though this sounds obvious, I’ve seen many people fail at this and, as a result, the non-verbal cues that conflict with verbal cues and confuse the team.

And of course, this resource is a useful one too.

Comments(0)

I’ve pondered on a question from the last Retro Gathering where someone asked how do you prompt people to tell their story by starting them with a common seed. I’ve thought about a couple of them since then, and got to run a new exercise with some people at the Calgary Mini Away Day we just had (thanks all for participating!) This exercise was inspired by the childhood TV show in Australia, of the same name (Mr Squiggle). Kids would literally send in a set of squiggles to the show to be put in front of a blackboard, where the main character, a puppet with a pencil on his nose, would turn them into complete drawings. See this link if you want to know more.

What is it: A variant of the Art Gallery exercise except using a common drawing to start the creative juices.

Time needed: 10 minutes

What you need:

• An index card per participant prepared in the same way (see below)
• A marker pen

How to run it:

• Before the retrospective, prepare each index card by drawing a set of symbols on it (I started with two lines and a circle)
• Hand out the cards
• Explain that you all have the same set of symbols and you would like everyone to spend the next five minutes turning it into a picture that represents the state of the project
• After five minutes, ask participants to share their story with the group

Tips for facilitating Mr Squiggle

• Ask participants to avoid writing words as this exercise is meant to be a visual, creative process.
• Provide other colours and markers to help with the creative process.

Summarising:
Mr Squiggle brings a different take on the Art Gallery picture at demonstrating how a simple set of symbols can be converted into completely different stories when explained by participants.

Comments(1)