Register now...

I've gone for the last two years and I have to say it has been an amazing learning and networking experience.










I encourage you to consider going to Agile 2009 in Chicago this year even though I won't be able to go myself.
(I'm expecting my 2nd child to arrive that week!)

Simon Baker's Dozen...

Agile Coaching statements:

#2 - Focus on Purpose, not Process
#3 - Think Big, Start Small
#6 - Working Code Beats Everything
#13 - Be Effective Before Efficient

Read the full list with descriptions.

Permission is not needed!

Over the last few years momentum has increased around the agile movement. It goes by many names (Scrum, XP, Lean...) but they are basically pointing at the same core inspiration: allow the team to be part of the decision making, quality, and accountability chain.

Typically people on the bottom have felt abused by the old system and latch onto this new system. Some test it successfully, and others yearn for more time to learn. Either way, the secret eventually escapes about their activities.

And then the dirty question rises: How do we convince the business to let us keep doing this great thing that increases our morale, quality, and predictability but is not easily quantified in the old world of thinking.

This is where I get confused. Since when did developers lower themselves to a blue collar status. Your job isn't to punch widgets, or flip burgers and assume that every break is clocked and pre-approved. We are a college educated group of people that bring a disciplined skill to our environment. Nobody asks the artist to make the artwork in half the time... only the artist can dictate how long it will take to do their work. Why are developers different?

Alan Cooper's keynote at Agile 2008 spent a lot of time talking about how the software process is more like a trade or craft than an engineering process that can be tuned like a factory. This was his foundation to explaining why usability needs to be incorporated. Here's an expert telling us..."Own your work!"

Then one day later, Uncle Bob presented a keynote that clearly stated the same point again... "Own your work!" His initial summary was craftsmanship over crap and led to a standing ovation of 2000 people which are all leaders in the agile movement.

Today, Tim Ottinger talks about fear of refactoring, TDD, and doing it right and tries to answer the question yet again. He also reposted from the XP mailing list a quote from Jame Grenning :

There are two values to software
1) Business value delivered
2) Ease at which the next important feature can be delivered

There is a theme here folks... quit asking for permission and own your work.

I've always struggled with the existence of the permission question for two reasons:

1. I started my career as a developer with a computer science degree and feel I can relate to the issues developers are going through today (though it has been 8 years since I wrote any real code)
2. I spent more than 5 years as a usability engineer. This role forced me to constantly justify the time and science behind this craft to insure I was allowed to do my job correctly. I was fighting against the mentality of developers that user interfaces had to be built with intention and to the business that this process was cheaper than not doing it.

So, I've always had to defend my craft. I've always had to sell my worth. And because of it, I've been successful at reaching my career goals.

Once again, I find myself pointing to the keyboard and saying get back to work and do your job the way you know you need to. Stop letting them make you compromise so much. Prove to them why you are so valuable and stop marching according to their defined instruction. Be the expert at how to do your job and manage your craft!

Now, go forth and quit asking this silly question.

Note: before you take my advice, become a maverick , and get yourself fired you should probably read J.B. Rainsberger's paper from Agile 2007 about "My Greatest Misses: XP"

Local Build... how big and how long?

Peter Morlion raised an interesting topic on the Agile Alliance LinkedIn group about how long a developer build should be allowed to run. It seems his team is split down the lines of "its important, so suck it up" and "this delays me too much, make it better".

His full question was:

Local build takes a while - run a stripped-down version?
Like in a lot of teams, we update from the source repository, change code, run the build locally, and commit if it builds. So far, so good. But the build takes a while of course. Personally, I think that's just something to live with, but my teammembers want to use a stripped down version of the build (mainly not building the sandbox, because it doesn't change much).
What is your opinion on using a non-complete build before committing, while the build server still runs the full build?

As one of the first to answer I said:

I would agree with your team members... unless I already need to take a smoke break every hour or so, that does not enable higher productivity. ; )

In my last team, the local build included the tests... If your developers have to wait more than 2 minutes for the process to complete, they start seeing this time investment as an impediment and may try to work around it by coding larger chunks before committing and integrating. This is the reverse direction agile maturity typically should take a team (especially a team leveraging TDD).

The sooner someone can verify something in the integrated build server, the better off the team will be. The purpose of the local build is to smoke test the local and obviously connected things they are focused on.

A balance has to be created between the two. If you swing too far in the other direction, then the team is hurt because the integrated build is broken more often.

Good luck finding the happy medium.

Joke of the day (not)...

Disclaimer: if you follow the Agile Software Development Blog, then there is nothing new to read in this post. Move along, nothing to see here. If you don't, then read on. (Sometimes my blog posts are to help me find something later.)

I encourage anyone to read the following article and try to convince me that it is a joke. It claims that the #1 best way to get a project back on schedule is to work overtime. Amongst the list of 10 includes "crashing the schedule" and "prevent all scope change". I've read it 3 times across 3 months now and I still think this guy was intending to provide serious advice.

Peter Stevens is also clearly convinced that it is not a joke and made his own list of 10 things to do to get an project back on track using agile patterns. (I'm right there with you Peter!)

But the interesting data point to take away is Jeff Sutherland's mention of the Maxwell curve. It is showing that working less equals more. It implies that once you go agile, you work more intensely, and overtime as an option is out the window.

How's that for work/life balance?

Don't abuse the metrics...

Tim Ross blogged about his concerns on burndowns. He offers some interesting points on how they can hurt including:

1. too much pressure early on
2. it doesn't handle the unplanned
3. it is unforgiving
4. PM's and customers misread it
5. it discourages refactoring
6. it focuses on a predetermined time

Hmm.... my responses:

1. really? most people feel it at the end
2. it is a reminder of the reality of the clock
3. neither is the market, it is changing whether you deliver or not
4. well... yes, that's true with any data point
   
5. not if you refactor constantly
6. or you could say it focuses on meeting a completion of commitment
   

Okay... some of that is me playing devil's advocate. I can relate to some of the points that Tim makes. Unfortunately, he proposes a solution where teams focus on the task board and maybe even hide the burndown for only the manager's eyes.

Umm... no. If you are really interested in going agile, then you have to understand that there is a power shift from the managers to the team. Instead of having people above (who aren't doing the work) ask for ridiculous things and make useless statements, the team is now more in charge of the process. But, the idea of a self-empowered, self-managed team is that the team has to be willing to be accountable for the work. This is not just the validation and quality of that work, but also the predictability of its timely delivery.

My view on this matter is two-fold:

• The burndown is an indicator. Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (be it the developers, customers, or managers), then everyone should know about it (that is why we do sprint planning and sprint review together, right?).
• ANY METRIC can be abused. If your culture stinks, or there isn't a trusting relationship between the team and the customer or managers... then any metric can be abused to support finger pointing. This is not specific to the burndown.
  

This is why many waterfall projects fail. It takes so long to uncover problems that when they are realized by lower management, they can delay the discovery further by gaming the metrics and reports to protect their jobs as long as possible.

"My definition [of agile] is that you accept input from reality, and you respond to it" - Kent Beck

A burndown is one of many measurements of reality! Unfortunately I think the answer in this situation is that the group needs to improve the cultural issues instead of throwing out the burndown.

Don't stand there, do something...

Part of a true story from inside the walls of Apple-

“This is really bad,” Cook told the group. “Someone should be in China driving this.” Thirty minutes into that meeting Cook looked at Sabih Khan, a key operations executive, and abruptly asked, without a trace of emotion, “Why are you still here?”

- Courtesy of Mike Cohn's blog this morning

The Last Mile... and Coaching....

Matt Grommes has been blogging for a while on the Agile Software Development blog about his experiences in a project transitioning to agile over the last year.

His most recent post covers the topics of how agile is harder as a long project enters its final days and that the agile rules were easily broken and ignored in an effort to finish. He asks for good sources of aid regarding this more turbulent time.

I left my two cents:

I agree that the end of a project can be more difficult. The team is best aided by shorter iterations and smaller stories. As you work on those outstanding things such as performance or questionable bugs, it is beneficial to shorten the feedback loop and keep re-measuring your progress to goal (and providing more opportunities for the customer to change their mind).

Also, he entertains a tangent about the appropriate level of coaching. It's always easy in hindsight to know you didn't have enough, but I also left my thoughts regarding this topic:

As for coaching, the best experience I had was when the coach(s) worked with the team for about 2 months straight, and then they came for one week halftime every other week or so after that. It was just enough to keep nudging us back on track and to infuse new things to mature towards.

Compensation matters...

Dear Employer-

Compensate all of your employees so that every individual feels fairly treated. They will not worry, think, or be distracted by this topic, but instead will focus on work.

If you don't compensate an employee fairly, then you should assume that they might talk to each other, uncover disparities, and start becoming distracted. It is safest to fairly compensate an employee fair market value even when this is higher than they originally request. (Yes, I once had an employer give me more than I asked because I didn't understand the standard of living in that area... and I loved that job!)

WARNING: If you don't compensate MULTIPLE employees in a way they feel is fair, then I can almost guarantee you that they will not only be distracted by this, but they will start talking to each other. When people think they have a good deal, they are afraid to tell others in fear that they might lose that upper hand. But if they aren't sure, then it is in their best interest to find out. Nothing pulls a team of people together quicker than an important common cause, so this is a quick team building activity. Unfortunately, it is not one an employer should promote.

When people talk to each other about compensation (with a precondition of being unhappy), it is very likely they will come to conclusions that are not to your benefit (and possibly not even valid).

My advice... nip these issues in the bud as early as possible. The longer you let human minds ponder these issues, the more emotional (or even irrational) they are likely to become.

Incorporate challenges, don't protect against them...

Precondition:
Everyone working for a company should be assumed to have a vested interest in its success because, selfishly put, they want the company to SUSTAINABLY make money so they can SUSTAINABLY make money. (Hopefully they also have pride in the work, their team, and the company's impact on the world.)

Theorem:
By working within a company, employees are likely to have as much or more insight into the domain than the average user of their product or service. Therefore, if one employee has an idea and another employee challenges that idea, it is very likely that eventually some portion of your paying customers/users will have a similar reaction or be affected by the raised issue.

Proposal:
When someome challenges an idea, they are not challenging you personally but instead they are helping insure that the idea will improve the company future and will not detract from other ideas. If the idea is one you support, then it is your duty to accept these challenges as a way to collaborate and make the idea that much stronger.

1. You must first try and UNDERSTAND what they see
2. You can communicate your idea differently in the hope that CLARITY will enable them to support your idea
3. You can enlighten them with FACTS you might have that will change their point of view
4. If they still can't see your idea as one they can support, then you should attempt to debate, collaborate, and COMPROMISE until the idea is one that everyone in the conversation can support and go out and sell to others. [Note: this can be bypassed if the person challenging you can agree that your idea doesn't detract from the larger set of ideas and you have the authority to make said decisions. (This is to combat the everyone-can't-be-involved-in-every-decision momentum blocker.)]
   

The fundamental thought here is that people need to stop baking ideas alone in their head (or a mini-sub-group) until they believe it is perfect and then expect the world to accept it as is. Humans are tribal social people and we have different perceptions of what we want. Once you state any idea that you want others to desire and use, you must accept that you don't control it any longer. It must be molded to the needs of the group you expect to utilize it. Anyone that can help you do this will get you a step closer to success.

This is fundamental in usability, marketing, business... even the selection of what to put on your grocery list (if people other than you share in consuming those items).

Summary:
If your employees aren't drinking your Kool-Aid, then why do you expect your customers to do so? If your team doesn't have the passion you do about trying something new, then they aren't likely to support you as a team when you pioneer new paths!

Credit:
This was inspired by some thoughts triggered by Dale Emery's discussion about resistance as a resource and Denise Caron quotes found in this slideset about agile:

Open yourself to critics and take your capabilities to new heights
Don't fall in love with your product, someone will be there to change it, it's a promise

Employee reviews...

It's that time of the year when we all start waking up from our holiday comas and drag ourselves back into work. (Alright, I'm a little late, but I've been under the weather for a few weeks.) For some of us, we are kicking off the new year with new plans, and for the rest of us we are just figuring out that it is a new year and we need to make some plans.

With that cycle, many of us also recently endured the review and appraisal cycle. Once again we are reminded of the standard lesson that the raise we receive is tied to economic conditions and the review we receive is tied to how well we can game the system. The majority of us get the painful sting of our performance having almost nothing to do with our raise.

In our little agile community, there has been a lot of talk about how the team dynamic within agile complicates this further and that it all needs to improved. At Agile 2008, I sat through an interesting presentation by Mary Poppendieck on the topics of appraisals, bonuses, and compensation. The problem is that we can point at all the things that are wrong, but I'm not sure we completely know how to fix it. Once you grow beyond the garage, it becomes difficult to say everyone has an equal part in the success of the company and that everyone deserves an equal slice.

So, I found something old that still feels new in its approach. The real point is to insure people are measured by their worth their team, their customer, and the company at large... not the manager that reviews them. Jeff Sutherland actually posted something on his blog over 2 years ago that is not only an idea, but was tried and tested. I not only like the rating system, but also the approach to the document itself. It's lighter, quicker, and probably more accurate than many things I've seen so far.

One other thing I saw in a company I worked for and liked (besides full 360 reviews) was the concept of round table reviews. In an effort to compensate for good managers being more critical of their reports (and scoring them lower) vs. bad managers fluffing their reports scores (to help them get raises)... managers were brought together and had to lobby, review, and normalize their scores across teams. Thus, a stellar (or stinker) employee was discussed across managers and validated (or disproved) as such. For every level up your name was recognized, the more likely you were to get an abnormally large adjustment. This meant that the rare cash that was handed out to the very few had been peer reviewed and management acknowledged across the board. This process also created a identification process to move star employees into a fast-track program for management mentoring or uber-skill training to foster future leaders.

Either way... yearly reviews suck. We really need feedback more often (monthly, weekly) so that we can grow and improve ourselves.