Scope

I'm finishing up the development stage of a project this week. It has been an interesting road with respect to scope. I was brought into the project after the start, actually 8 weeks into the project. When I got here, I looked at how much work was planned and became concerned. Without trying to validate the estimates, I felt there was more work than we could get done by the end of the project.

I worked with the team and client and we were able to reduce the scope by about 20%. Some of this was moving stories into the next release. Some was reducing the complexity of what we were trying to deliver.

As the project progressed, we added more scope. Not a surprise; it should be expected. As the users started seeing parts of the application, they thought of other things to ask for. But here's where we ran into a bit of a jam. We added new stories, but didn't take anything out. We assumed we could absorb the additional work; it only was a couple story points a week.

With about 4 weeks to go, as I looked at our velocity and how many points we had left, I saw we had a problem. When I brought this to the business, they said "we have to have all of this, you need to work harder." Two weeks later, the business saw what I was talking about, it just wasn't all going to get done.

The business identified some stories that could be moved out. The remaining work was still more than our average velocity, so I agreed I would work the team through the weekend to get the rest of the work done.  This was the first time I had asked the team to go above their normal work days, so I wasn't to concerned. If we had been 4 weeks out and expecting 4 weekends of work, I would have been concerned.

We got the work done. Our final tally was slightly higher than what I thought we could deliver right after we re-scoped the work. The real lesson to me is to make sure every time we add even a small amount of work, we make the client aware of how that can impact what we can deliver by the end of the project (their final delivery date couldn't be changed).

Interpretation

I came across this picture recently. Do you see the old woman first, or the young woman? Can you see them both? I find it interesting how our perception can be different from someone else's.

Perception - a way of regarding, understanding, or interpreting something

I think the key word here is interpreting. We don't all see things the same way. We have filters based on our backgrounds, experience, education etc. It is these filters that create the interpretation. The thing is, we need to be aware of how other people may interpret things as well, or we can run into problems.

For example, as a mid-west US raised, former military officer, if a meeting starts at 9:00 AM, I'll be there at 9:00. With some of my clients, meetings start right on time as well. With other clients, a meeting scheduled for 9:00 may start at 9:05 or 9:10. There is a cultural difference in the company that is in effect here. My interpretation may be these people are rude for starting late, if I don't understand their culture. Once we start talking about outside the mid-west US, things can really change. When I'm in Egypt for example, I have to be aware of how Egyptians interpret time, not how I do. If a meeting is supposed to start at 9:00, I need to know that may not really mean 9:00 exactly. 

So next time you seem to be at odds with a colleague, think about what their interpretation of the situation may be, not yours. 

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.