Agile2011 - Final Summary

Agile2011 is over. The last couple days went so fast, I didn't even have a chance to update my blog until now.  Over the last two days I spent a little time on the topic of design. I'll admit it's a topic I don't spend much time on, but I should.

On Wednesday I listed to a discussion on the topic by Mary Poppendieck. Her discussion was based on the  book The Design of Design by Fred Brooks. The design is basically broken into 3 steps;

1. Understand the problem
2. Design the solution
3. Implement the design

A small team is better than an individual for design and the process is iterative across the three steps. Good design is like Wayne Gretzky playing hockey, he skates to where the puck will be. 

The second design topic I heard was Lean UX by Jeff Gothelf. There's a great article that covers his discussion here, so head over to read it. 

One of the themes I picked up on during the conference was the idea of building value. Design plays into this, designing a good solution. A couple speakers talked about how if we get to focused on delivering the user stories, we can loose track of what the real value we are trying to bring. 

Personally, I've seen this with some of my clients. Even though we're using agile, there is still to much focus on competing the stories in the backlog without much thought about what value those stories bring to the business. It's not a question of getting all the stories completed, it's delivering a product that has real business value. 

Agile2011 - Day 2

Today started with the keynote address by Dr Barbara Fredrickson. Her topic was Positive Emotions. She cited research that showed how positive emotions expand our cognition, things like thinking more global, being more positive, improving peripheral vision, being more creative. This positive emotion can be triggered by giving a gift, pictures of cute puppies or upbeat music. 

My next session was lead by Chet Hendrickson and Ron Jeffries. It was a retrospective of what we've done right and wrong over the past 10 years since the Manifesto was signed. On the positive side, agile has found its sweet spot, co-located, cross-functional team with solid technical practices doing frequent iterations. On the other side, there's dogmatism. This is common in people new to agile; insisting that the rules get followed. This behavior is a result of ignorance, fear, or inexperience. There's also the competition factor; do we use xP, Scrum, Crystal? There conclusion was there is plenty of bad software practices out there and it doesn't matter what you use as long as you follow the principles. 

I also sat in on a session by Jim Highsmith. He was talking about the subject of leadership and doing agile versus being agile. One interesting idea he threw out was on technical debt. As it builds, the cost of change increases exponentially. 

My last session today was with Andy Hunt, which would make it the 3rd author of the Agile Manifesto that I heard today. He had an interesting discussion on Refactoring our Wetware, based on his book Pragmatic Thinking and Learning: Refactor Your Wetware . He talked about how we learn, how our brain works, and how we can improve. He talked about the evils of multi-tasking. He also talked about how to be more effective. One of his ideas was a journaling technique. The idea is that you do this the first thing in the morning, before checking your email or updating twitter. You write (no computers or iPads) three pages and don't censor what you're writing, and finally, don't skip any days. 

So now I have to pick out tomorrow's sessions. The quality of the talks has been great. The hardest part is selecting among the numerous choices in each time slot. 

Agile2011 - Day 1 Summary

My morning session was on Multi-Sensory Kanban, presented by Ravindar Gujral and Andre Dhondt. Kanban is supposed to be visual. The session discussed ways to expand beyond just your kanban board. One example that they gave was connecting the computer to some speakers and when the the build fails, it creates a disturbing noise. There was also a discussion on using timers in a pomodoro technique; get the team focused on a problem and when the bell goes off, you re-evaluate where you are and what the next steps are. 

I only made part of the afternoon session due to a work-related conflict, but I did listen to a discussion on deliberate practice. Some of the key points here;

It must be designed to generate improvement 

It should focus on a weakness 

It should put you under stress. 

It requires thought/is mentally demanding 

It must be repeated a lot to achieve results

It's not fun

This session was by Tom Perry and I wish I could have listened to the rest, because it looked like it was going into how we can practice techniques to become better leaders. 

The real highlight though was the evening session, which featured a Q&A session by 15 of the 17 signers of the Agile Manifesto. They provided an insightful and humorous discussion on how the manifesto came into existence. 

The conference has around 1600 attendees. My real purpose in attending is to help promote the PMI Agile Certification (PMI-ACP sm). I was in the booth Monday evening discussing this with attendees. There was a lot of interest, both with current PMI members and folks who weren't active with PMI. The exam will be available on September 15th. 

$300,000 bonus

There was a big road construction project over the weekend in California, with predictions of major travel disruptions around the area. However, things didn't turn out as expected, and the construction company earned a $300,000 bonus for finishing the job in 33 hours instead of the expected 56 hours.

So what would you do to get a project done sooner. Is this an effective way to run your technology project?

According to Daniel Pink in his book Drive, cash incentives won't motivate the team effectively. According to Pink, "if-then" rewards such as a bonus for getting done early, aren't effective in the long run. Mihaly Csikszentmihalyi introduced the  idea of flow, where intrinsic motivation takes over and the person is absorbed by the task at hand.

I recently took over a project that was "challenged." One of my steps has been to remove distractions from the project team so they can focus on the development tasks. I'm using Kanban to help with that, minimizing the work in progress and helping the team focus on what needs to be worked on next.  What should happen next is their efficiency goes up because they aren't multi-tasking and they can get to that point of becoming absorbed by a single user story and get into the flow. I think it will take a couple more weeks to really know how effective my approach is, but throughput seems to be going up so far. This is good, since I don't have $300k to give the team.

Personal Kanban Update

So I've been using my home Kanban board for about a month now. As I suspected, it is a bit of a challenge to use a physical board with as much travel as I do. My approach so far has been to review the board before I head out on a trip, figure out what will be in my working queue, and capture that electronically. When I get back home, I update the board. I think I have to go to an electronic version of a kanban board, but I haven't looked into that yet.

I've also started reading Personal Kanban by Jim Benson and Tonianne DeMaria Barry. I'm almost done and it has given me some other ideas.

One idea is setting up a special flow for different tasks; in my case when I do writing. My writing takes on a different flow than just from doing to done. I found with writing articles or papers, I go through a step of laying out the outline, then I go through a first draft where I try to get my thoughts on paper, a second draft where I try to make my thoughts more coherent, and a final review to check grammar, punctuation etc.

I also like the idea of having a "Today" column. That gives me the ability to look at everything I have going on that day - tasks, meetings, work in progress - and decide what else I think I can get done.

One area I still need to improve on is capturing all my tasks. Right now I am only putting the bigger tasks on the board, not all the little tasks I have going on. I think I need to do this to really get the full effect. In general though, setting up my personal Kanban has helped me get more organized.

Shuhari

I've written in the past about the rules of jazz. I've come across another similar concept that has surfaced in relation to learning agile techniques; Shuhari. The ideas first gained popularity in the martial arts, but is being used these days when discussing agile. Alistair Cockburn has been an advocate of this idea (link).

Shu is the first stage, when a pupil is learning the technique. The emphasis here is practicing what was learned. This reminds me of the new Scrum Master, running their first projects following the techniques they developed in training. Having a coach would be beneficial at this stage.

Ha is where we start to think about what we've learned. We may start to bring innovation to our technique. In jazz, this is where you start taking solos and improvising. In the project setting, it is where you start bringing in new ideas.

Finally, Ri is where we discard the structure learned in the first step and take our own direction. We are no longer the student but the practitioner.

A key part of this approach is that it is a journey. As a project manager, you will face challenges if you try to move right to Ri without practicing in Shu and reflecting upon it in Ha. I have always been an advocate of selecting the right approach to manage a project based on the details of that project (a Ri action). However, to be able to do this, a PM must understand the tools in their toolkit, which they build in the Shu step. The Ha step is where the begin to understand how a particular approach works in a given situation.

This isn't a one-time journey either. I know as I adopt new techniques, I have to go through all three stages. Learning Scrum is a good example. I was already a project manager when I learned Scrum. I went through Scrum training and applied what I learned (Shu), then I started holding retrospectives with my team to reflect on how things were going (Ha), and then we modified our approach on new projects (Ri).

Adjusting Goals & Re-planning

I ran the Chicago 13.1 last weekend and while my time was not very fast, I did make it across the finish line; which was an accomplishment under the conditions we faced. Because of heat & humidity, the race organizers actually stopped the race. Only about 130 people (out of 4000 starters) "officially" completed the race before is was stopped. I crossed the finish line after the clocks had been turned off.

Preparing for and running this race was a lesson in adjusting goals and re-planning. The original plan was to run the race with my son. By March, we abandoned that plan because he got an injury and wasn't able to train. So I set a new goal of running under 1:45 and targeted my training toward that goal. On race morning however, with the temperature already climbing to a humid, sunny 80 degrees before the start, I knew if I went out on my target pace, I would pay for it later in the race, so I went slower right from the beginning. I ended up about 7 minutes off my target, and I was pretty tired at the end, but I made it.

So how often does this happen in projects? We start out with a goal, and as events unfold, that goal is no longer attainable. Can you recognize the need to re-plan, or do you keep marching toward your original target, not admitting that the situation has changed and your plan won't work?

I was consulting on a project last year where it became obvious that we would miss the target date. This information was presented to the executive steering committee, but they wouldn't allow the date to change. I think their logic was that if they let the date change, everyone would start slacking off. We missed the date, but still no one tried to come up with a realistic goal. It turned into a death-march where everyone was trying to deliver to an impossible goal. Fortunately for me, I had moved on to another project by then.

Did the executives achieve anything by keeping the pressure on? I doubt it. The morale was sinking with my team members as the project moved forward. In the race, the people that didn't adjust their goals were disappointed. People I talked to missed their target by 20 or more minutes and were really suffering at the end. When faced with reality, it's better to adjust a goal to be achievable. That doesn't necessarily mean easy, but if everyone knows the goal is impossible, the race is already lost.