patkua@work

The intersection of technology and leadership

Category: Learning (Page 10 of 15)

Estimates degrade over time

January 15, 2009 / / 7 Comments

Project management is a funny thing. It seems like once something is converted into a number, the number is often all that matters to traditional schools of project management. Plans get created, promises get made, yet little diligence goes into ensuring the number is based on sound thinking, and that the basis for that number remains correct. Maybe that also explains the state of the current banking industry, though that’s another post entirely.

Most people fail to understand that estimates have a half life, and often a very short one. Even results produced with agile estimation techniques, have an expiry date that is often ignored. Magic numbers (aka, the estimates) have an expiry date because in order for them to be even slightly reasonable, they need assumptions to be made, and it is often these assumptions that expire. Gantt charts are awful at highlighting what those assumptions are, let alone tracking when they fail to be met.

burntnumbers
Image of burnt numbers provided by Dead Scene under the Creative Commons licence

A recommended practice for agile estimation is to get the people who are going to do the work, to estimate. Put these estimates on a shelf to ripen for a year and, presto, you have a new team to which, the original estimates no longer apply. Even given the same team, set to work on something else only to return to the system, will have lost some flow, forgotten some things and need more time than if they just continued to work on the same system. Environments often change, and the underlying needs for the business change even more frequently.

What can we do about it? I refer to Lean Software Development’s principle of the Last Responsible Moment, to not only make decisions, but when collecting (and keeping) estimates. Collect estimates now if it helps you make a better decision, discarding the estimates if you choose not to immediately implement the project. You set yourself up for failure if you choose to estimate now, knowing that the project is to be shelved for “only three” months and keeping those numbers as if they are in any way relevant. If you don’t need to make a decision now, work out when you need to make the decision and defer collecting estimates until just before then.

How do I tell if a team is agile?

November 12, 2008 / / 4 Comments

Vivek asks what are the signs you use to tell if a team is agile? I prefer not to count the practices they might be using because that is almost too easy (to get wrong).

Example: I remember talking to a person about their team who claimed they did lot of automated testing. They apparently had tests but upon further questioning I found many of their tests didn’t work and hadn’t worked for quite some time. I continued to ask questions about their practices and they mostly seemed excessively ritualistic without the team benefiting from them.

Ticking off a checklist about practices is easy to do, yet hard to do well. I prefer to ask questions with a less explicit goal in mind. I care more about how people do what they do rather than what they are doing right now.

I prefer to look for consistent behaviours across what they are doing that tell me:

  • they care about what they’re doing
  • they understand why they are doing what they are doing, and actively question when it’s not clear to them
  • even better is that they can explain to people why they do what they do as a team and what value each part of their process has (I dare you to try that with your current team)
  • they help each other out even if it’s beyond their normal roles because they don’t believe that people fit in boxes perfectly. And most importantly;
  • they’re constantly trying to improve the environment they are in.

What other ones do peope look for? I’m sure there are plenty more.

Why timeboxing is important

July 3, 2008 / / 7 Comments

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.

Time box

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.

Barriers to learning

June 26, 2008 / / 0 Comments

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.

Why Training Fails

June 2, 2008 / / 3 Comments

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.

When Retrospectives Go Wrong: Poorly Formed Action Items

May 21, 2008 / / 0 Comments

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.

Failed Pottery

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.

When Retrospectives Go Wrong: The Faciliator Did Not Prepare

May 20, 2008 / / 0 Comments

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.

Surprise

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.

Agile Principles Applied to Training: Transparency and Information Radiation

May 14, 2008 / / 0 Comments

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:

  • Training PosterPosters 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 WallMini 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).

Agile Principles Applied to Training: Building in Quality and Continuous Improvement

May 13, 2008 / / 0 Comments

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.
  • Worksheet EvolutionUser 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?”

Agile Principles Applied to Training: Building in Feedback Cycles

May 12, 2008 / / 0 Comments

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.
« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑