Monday, April 27, 2009

Higher Agile Project Performance...

Recent VersionOne user forum discussion:
How to yield higher agile project performance? Should we implement one agile method, such as scrum, and follow process rigorously, or mix with different agile methods?
I'll paraphrase my response:

As mentioned previously, I'm a believer in Shu Ha Ri. This means, follow the book until you know the why behind the prescribed actions. Do not modify the process unless you know what is removed with your proposed changes. Many people lose more than they gain if they change a process before it is fully understood.

Many waterfall projects could be successful if the team studied and followed the PMI process as documented. Agile will be corrupted just as quickly as waterfall if people keep bastardizing it blindly as they have been. If you are interested in expert opinions on bastardized agile process, check out Jeff Sutherland's view's on ScrumButt and the Nokia test.

My proposal: apply Scrum for people, business, team, project management improvements or apply XP for engineering practices and technical quality issues. You could apply both simultaneously, though this might increase risk with too much change at once. Scrum requires a top down implementation, while XP should be a bottom up implementation (I'm speaking of the top/bottom of your organization).

Eventually, you can yield a higher agile project performance with a blended process approach based on your environment, but you can't jump directly there in the beginning. Also, the person driving your Ri level approach should be experienced (not just trained) in the things being blended. If you do not have this person, then the changes need to be a gradual evolution (one per iteration) allowing for correction.

I would debate that the average team should get through twelve iterations before trying to tweak this. For one month iterations, this is a year. For two week iterations, you might be ready after six months. Why base this on number of iterations and not time? Because you should be learning with each cycle and improving from your retrospectives. Agile is about learning and adapting, not practicing (or feeling pain) over time.

The last option I would throw out is that you don't implement anything by the book... you simply add one practice every two weeks or month. The practice added is one that addresses your biggest pain of the moment. Over time, you will back into a blended agile process that works well. Unfortunately this requires two things... lots of time and patience, and someone with experience to make the right selections at the right pace and help the team implement it in isolation of the rest of the practices. I've seen this work only where the person driving has had experience with a successful multi-year mature agile implementation in the past. If you are going to choose this path, I would suggest the following sequence: retrospectives, standups, large visible charts. Why would you choose this path? Because nobody has bought into agile and you just want to solve the current problems with agile patterns.

Friday, April 24, 2009

Scrum does not kill the need for a PM...

Jack Milunsky posted on the Agile Software Development blog a great 2nd part article about change caused by agile. I agreed with many of his ideas and points, but one of his statement rubbed me the wrong way. Here is his statement and my response:
You said, "Scrum essentially does away with the traditional Project Management role."

Why do I keep reading this everywhere? Why is this becoming a standard statement? Is it really true?

I not sure it is always true, I think it is dependent on the environment.

My first experience with Agile was at Siemens Medical. On our "project" (product release effort) we ended up having ~5 scrum teams across India and Philadelphia. Each had a scrum master who spent a lot of time focusing the team on the agile transition and the process. We still NEEDED a PM to help coach and guide the teams, scrum masters, and product owners. In this case, the PM and PO (two separate people) were very helpful in guiding the 5 teams to draw their slices of their sprint backlog from a single unifying product backlog. I do not know how we would have done this without a PM and PO. Note: our PO was a person from the clinical domain, I would not have expected him to also fill that role. The scrum master role was focused on helping the team transition and function daily, the PM role focused on interfacing with the company and handling reporting, staffing, metrics, and buffering us from the company (we had 2500 people on our campus alone). The PM (with the PO) was the single voice of the 5 teams to the company, the scrum masters could not have done this.

So the question is... is this an issue of Agile at scale, or was my experience unique due to the domain? Either way, I argue it is not a foregone conclusion that scrum does away with the PM role.
Sorry Jack, I wasn't picking on you specifically... you were just the third or fourth person who said that this week.

Thursday, April 23, 2009

Walking the Board...

Several weeks ago we changed our standup structure. At first I kept it to myself due to my fear of backlash from the agile police over blogging about it. But, this week's InfoQ post prompted me to bring it up since what we did was mentioned in the article.

Our team was starting to drone in the standups. As more people swarmed on a story, there was a lack of self-management when communicating against the story goal. Translation: Person 2 in the circle would discuss Story B, and then person 3, 5, and 7 in the circle would wait for their turn to share their piece of the story work. It was if we had mulched our sprint backlog and put focus on people instead of delivered business value.

Ditch the 3 questions! What? Yeah, I said it, ditch the 3 questions. Actually, wait... keep the questions. Ditch the person rotation. Yeah... that's the answer.

Our pseudo-Kanban board (I say pseudo since it is not by the book) is already prioritized from top to bottom by the CEO/product owner. Now, instead of going around the room by person, we work from top to bottom. I play the role of scrum master, so I point at each card. The team speaks about what they did yesterday, what they will do today, and what is blocking them.

Suddenly the room is lit up with energy. Instead of having people discuss their slice of the work, the team is speaking about the whole story. They talk towards the goal of delivery and business value. Cross-communication is triggered (and taken offline as needed). I'll admit that this didn't happen at first (at first they talked to the guy pointing at the card on the board), but it has happened over time with my coaching. There's more interest in moving the card since there is immediate clarity on where we stand with it. Nobody later in the circle is going to surprise us on a prior topic.

Now... you could easily argue that this is stupid. A mature team would be smart enough to speak at the right time and not just in turn. I agree. Look at it a different way though... we are talking through our board in order of importance to the business. The most energy and focus is on the right stuff. Our conversation is less about the who, and more about the what.

Turns out, David Anderson calls this "walking the board". I propose that it's a good alternative and we are proving it!

Friday, April 17, 2009

What makes a good Product Owner?

Kanban Jedi put up a good blog post about Product Owners. After a little banter back and forth, I figured I had a few words to add myself:
  • If you have a single customer, the mature agile team doesn't need a product owner. Their customer is the product owner. Direct communication is critical.
  • If you have many customers (for example, 6 beta customers and a market potential of 100's), then you need a product owner to go out and be the liaison between all these opinionated parties. It is the product owner's responsibility to find the core set of requirements for all customers without including requirements unique to a few.
  • Your product owner should understand technology. Prioritization of the backlog is greatly dependent on understanding the cost of features which includes the complexity of building them. A basic understanding of technology will aid in this discussion. If they have implemented a software system, then they at least have an idea of how complex it can be.
  • Your product owner shouldn't represent the techonlogy, but instead represent the domain. They represent the customer. The customer doesn't care what language it is coded in, or how cool the algorithms are. They want something that meets their business needs. Make sure the product owner is responsible for the domain first and foremost. They should not be the architect or tech lead or anything close to that role.
Anything you would like to add to the list?

Thursday, April 9, 2009

Can Agile Teams Recognize an Individual?

So, I found myself in an interesting debate with KanbanJedi. He raised a really good point that I agreed with:
... So recently I heard of a team that is using Scrum and their manager had decided to have a “Person of the Iteration” award for the person that completes the most points in a Iteration.

I think this totally misses the point of Agile being a team of people working together to get as much stuff “done” in an iteration to the highest levels of quality...

... What happens if several people work together on a story – who gets the credit? Well firstly you’re not encouraged to do this to win the award and secondly I have no idea how that works.
Fundamentally, I believe that he and I agree that any award that encourages individual behavior over the team will be destructive to the self-empowered self-managed team structure. I took a minute though to play devil's advocate and see if there was an example of individual recognition that could grow the team in a positive way.

My first thought was that it had to be from the team, not from a manager or due to a metric.

My proposal was MVP, or Most Valuable Pair Partner:
I’m thinking of a mature agile team that does TDD and pairing (that already limits this enough to strike it down from being a public idea since most teams aren’t there).

If every person on the team nominated the peer who provided them the most value that sprint as a pair partner, then the team is selecting the person who most contributed to selflessly supporting others in delivering value/velocity and/or mentoring/knowledge sharing. Such an award would encourage people to not work as individuals, but work to uplift the team as a whole.
As nice as this sounds, I'm inclined to agree with KanbanJedi that this might be a bad idea. Only a very mature team can handle such an approach and not let it degrade into someone gaming the system for recognition sake. I guess the award could be recognition only (pat on the back) so that it's about pride and nothing more, but there is a risk.

So, the question is whether an agile team can provide individual recognition to a team member? Or is it too filled with risk to even open this pandora's box? Does this fit into Mary Poppendieck's points on constant and timely feedback, or is it a bastardized version of the old management's way of passive-aggressive team-destroying motivation.


Wednesday, April 8, 2009

How to sell agile over waterfall...

There's an interesting discussion going on over at LinkedIn's Agile Alliance group...

Q: What would be the right approach or main reasons when convincing a client to switch from the classic Waterfall to Agile? What would be his main benefits (business wise)?

Some of the first folks said:
the client needs to feel the pain of waterfall first, or they won't have a compelling reason to make the shift
or something like it. This bothers me greatly.

My response:
Doing waterfall first can help, but do we really want to say that Agile can only be sold when the pain of waterfall has been felt?

I'd start with these two points...

1- you can cancel the project at the end of any iteration if you are not happy and still have delivered business value. With waterfall this typically only happens at the very end.

2- You can change the scope as you learn and see your product grow and there are options for still delivering business value at dates before the end of the project.
Your thoughts?

Tuesday, April 7, 2009

Agile is about Courage and Discipline...

Agile transitions are not easy. Most people focus on changing the process, but underestimate the other things that need to change also. The key moment in an agile transition is when you realize that people, their interactions, and their attitudes are more of an influence on success vs. failure than the process itself.

I have run across many people that hit this transition but run into a new problem. They know what needs to be done and have great ideas for improvement, but don't have the courage to speak their minds. Even worse, a group agrees on an improvement but doesn't have the discipline to follow through and gain from it. Nothing is more demotivating than having knowledge and not applying it, or continuing to feel pain when there is a proposed solution.

Here are some examples of what I'm talking about. The first statement is the current team state... the paired response is the potential state of the team if everyone employed a little courage and discipline.

Everyone comes to meetings two minutes late because "meetings always start late"

All of our time is valuable, we need to respect everyone by being on time. Not doing this hurts our peers and the company's productivity. We will start meetings when they are scheduled regardless of if everyone is present.

Retrospectives create focus on the negative and if we can't fix the problems raised, then it demoralizes the group. It is too risky to have them.

Retrospectives are an opportunity for improvement. These conversations are steered towards valuable conversation. It is on the manager AND the team to invoke gradual improvement. They are too important to NOT have them.

That person typically blocks me or slows me down, I'll avoid them until I can't.

They must be affected by this, which is why they are invested and speaking up. How do I work with them towards a mutual outcome?

This process is painful, but it is what we always have done.

We have changed and grown, we need to adapt the process to our new situation. Call the team's attention to it. We might be able to streamline the process.

We have too much to get done in a reasonable time. Instead of worrying about it, we will just let our manager tell us what to do next.

We accept and reject commitments based on what we can do. We will push back as needed because we want to focus on the most important work with realistic deadlines so that we are motivated. We will speak up if this isn't happening. We will hold ourselves accountable to our commitments.

We don't have time for that, we have too much to do right now.

We already decided that is important… we have to make time to pursue it, or it will never happen because we always have too much to do. The long term gains are more important than the immediate loss.

More could be listed, but you get the idea. Think about your team. Where aren't you employing the courage and discipline required to help improve your team's future?

Monday, April 6, 2009

Manager type: Curler

As a manager, you’re the guy on the Curling team with the broom – sweeping the snow out from in front of the stone… You don’t want to be in their face with all the details, but here to remove obstacles.
Excerpt from his list of advice to new team leads.

Friday, April 3, 2009

Agile Planning...

Two reposts due to their interesting topic and unique content:
  • One of my more recent and popular posts was about creating a proper estimate scale. Here is a great post by Bob Hartman about how to improve your poker planning activities. Use it to build on top of my advice!
  • If you are curious to read a great overview on agile written by a User Experience expert from IBM, I found this quite good. Nothing new for the experts, but I like having good summary resources to leverage when coaching. I also found it interesting since it's coming from such a large company.