Monday, March 30, 2009

NFR's and Technical Debt...

Two reposts due to their interesting topic and unique content:
  1. Non-Functional Requirements, a minimal checklist at Leading Answers. This is a good checklist for any team to work with their product owner and cover all that "technical stuff" that insures the product's success or failure outside of its features. Some people call this the "-ilities" list.
  2. Using the Mikado Method to pay down Technical Debt. This is a good post that uncovers the typical lesson of refactoring the guts of a ball of mud. For every thing you fix, you find 10 more. The Mikado Method is a good way to plan out refactoring to avoid this problem.

Friday, March 27, 2009

Sprint Committments...

This post is my response/summary to a thread on the Agile Alliance LinkedIn group related to the same topic. If you'd like to read all the details, click here.

The question asked by Rene Rosendal was:
I've seen teams who don't seem to take their sprint/iteration commitments very seriously. When a story is in jeopardy, they don't increase their work intensity in the attempt to finish it. Instead, the words "well, we'll just have to carry it over to the next sprint" pass their lips very easily. Obviously the Scrum Master or Product Owner cannot "force" the team to work harder and make things happen. ...
My response was three fold:
  • Assuming they made the commitment, you have a team / culture problem... lack of caring or motivation
  • Or you have an empowerment problem. The team is not actually committing, but someone else is declaring commitment for them. I've seen management assign the sprint goal and work. How can the team commit to something they know is not possible just because someone said it? The team should own the sprint planning session of work.
  • Or you have a communication problem. Maybe the team is committed and they selected the work. But the point of agile is that things change. Maybe they found things during the sprint that made them realize the commitment was not obtainable. Did the team go back to the Product Owner/customer and clearly communicate this? Did they negotiate? Did they make sure that the work they were pursuing was still correct in light of this new knowledge?
Other great points:
If the team puts in extra work to complete a story are they penalized by having the organization expect that they will do the same number of points in the next iteration? - Rob Scott

Most sprints my team fails to complete everything on the Sprint backlog. We do not consider this a Sprint failure. Instead, we remind ourselves to focus on getting the topmost things on the backlog completed first, so the items of greatest priority are done by Sprint review. I think this is extremely common. - Dan Greening

Is the product owner easily accessible to the team and actively involved during the sprint? - David Sallet
Fundamentally, commitment is like trust... you can't make it happen, it is chosen by the holder.

Thursday, March 26, 2009

TAD vs. TDD vs. paired TDD

This is a repost from Jeff Langr where he simply models how TDD is quicker than TAD and paired TDD is quicker than either of the first two.

Simple but effective.


Paired TDD:
Confused? Read the full version here.

Wednesday, March 25, 2009

The 4 stages of competence...

No, they aren't idiot, fool, apprentice, genius. Here are the four stages of competence:
1. Unconscious Incompetence - The individual neither understands or knows how to do something, nor recognizes the deficit or has a desire to address it.
2. Conscious Incompetence - Though the individual does not understand or know how to do something, he or she does recognize the deficit, without yet addressing it.
3. Conscious Competence - The individual understands or knows how to do something. However, demonstrating the skill or knowledge requires a great deal of consciousness or concentration.
4. Unconscious Competence - The individual has had so much practice with a skill that it becomes “second nature” and can be performed easily (often without concentrating too deeply). He or she may or may not be able teach it to others, depending upon how and when it was learned.
- Wikipedia
Thanks to Jerome Gagner for sharing in his recent blog post on the same topic. These ideas fold nicely into the Shu Ha Ri ideas discussed before.

Friday, March 20, 2009

Flashlight vs. Laser...

Peter Stevens has been talking about his journey from a PHB to a scrum master (and agile coach). His recent presentation included some interesting lessons, journey notes, and advice.

One of the things I'd like to call out is his metaphor for an agile (scrum) team before and after the transition (slide 17 of his presentation):
What is the difference between ordinary light and a laser?

A bulb produces white light – the light is at multiple frequencies, going in all directions and produces more heat than light.

Laser – the light is all on the same frequency going in the exactly the same direction. A laser pen can illuminate a point across the room by daylight. A laser can read bits on a DVD. A laser can measure the distance to the moon (which is increasing by 38mm / year).

A group is a light bulb – bright individuals, but individuals going in different directions

A team is a laser. Focused, synchronized, with incredible potential.

If you do Scrum, you can turn your groups into genuine teams.
I love this metaphor! It's a good one. Having said that...

We have to be careful about perception. I know managers that prefer the flashlight. Instead of rapidly focusing the laser on one or two things at a time to quickly and efficiently "kill" them, they'd rather shine a bright light on the whole room and see what scatters.

It's a "let's do a little bit of everything and see what sticks" approach. Granted, this probably shows some flaws in strategy and vision, but it is a culture nonetheless... and it works for some people/businesses.

So... how do we tackle this issue? How do we make the argument?

Well... make sure your laser is effective. Make sure it can be redirected quickly. Make sure it can kill flies, not just gnats. Turn it into a Star Wars program. Make it a better approach than the stadium lights one.

(I didn't really say anything but fluff, did I? Fine, I don't have the answer... I'm just making a point an sharing frustration.)

Your ideas?

Tuesday, March 17, 2009

ScrumAnd, not ScrumButt...

Repost: Ola discusses the difference in climate, attitude, and outcome when we switch a conversation from "Yes, but..." to "Yes, and..." Not only is this an interesting coaching/team culture thought, but it ties in well with the ideas around Scrum, Agile, and the different disciplines (and how they can be combined).

I believe ScrumAnd already exists. Under a different name though. It’s called eXtreme Programming. It’s Scrum and programming practices. Now you might say. ‘Well, Scrum deliberately says nothing about programming practices. You can use Scrum to plan and execute anything’.

Yes, that’s true and that’s the problem. People are now cranking out crappy code at least twice as fast as they used too.

Read the full post "What About ScrumAnd" here.

Friday, March 13, 2009

Our chosen language...

No... not the programming language.
Not even English vs. French/Spanish/etc.

Language... as in tone, rhetoric, choice of words.
Is yours offensive, passive, strong, dull?

Some people are inspired by strong words, some people are offended by it. Attention is grabbed with certain words, but what kind of attention?

What do you use in your daily conversations with others?

Why does this matter?

If you are a leader (an agile coach, scrum master, tech lead)... then this is important. As a leader, you mentor constant change. For this to be successful, positive change... you have to insure the team as a whole is working together. To do this, you have to sell the idea, plant seeds, mold minds.

You are the salesman. You make the pitch.

Pick your words carefully.

This post was inspired by the struggles of my esteemed mentor in the pushback on the word "sucks" as part of his presentation title at Agile 2009. Here is a portion of my thoughts back to him:
I totally understand your predicament. I agree with you that words like "suck" and "crap" have been used at our agile conferences (in keynotes) in a manner the implies they are accepted. Strong words to invoke strong emotions. I tend to get in trouble as an agile coach when I use strong emphatic words... they do catch attention, but not everyone is comfortable with their strength (and implied negative connotation)...

... I think the lesson here is that [strong] language IS acceptable to put the final nail in a point being made, but maybe not acceptable as a way to introduce it. It is acceptable within a controlled and known audience, but not to the world at large. Personally, I don't like this... but I've accepted that being a good coach/presenter is being a good salesman... which is knowing your audience and exposure and adapting to it.

Thursday, March 12, 2009

Commenting your code...

I once heard a very wise man say... if you comment your code, that is an apology for its lack of readability.

Okay... so that might be an extreme viewpoint, but still a good philosophy.

If you want a more balanced view, Tim Ottinger blogged about 3 rules for comments today.

I like.

Wednesday, March 11, 2009

It's okay to be a zealot!

I was starting to think I'd been coming on too strong recently. Too much faith in the agile ways, not enough compromise.

In some ways, I was right.

You can't coach or mentor if you don't listen to others. You can't sell an idea if you don't mold it in a way that adds value for your listener. You can't be the catalyst for change if you ignore where people are coming from.

At the same time... it's okay to have strong beliefs. It's okay to KNOW that your way is better (assuming you've experienced and proven this before). Life experience is about learning and growing. Wisdom is about sharing that with others. Knowledge is only valuable if it is passed along.

Uncle Bob posted a retort that will probably start yet another flame war between the agile community and a non-member who didn't think through his words completely enough. But his points about being a zealot, and it being an okay thing, are very interesting.

We are a problem only if we start to believe our views are the final perfect answer.

Tuesday, March 10, 2009

Dale Emery has spoken...

For whatever reason, Dale Emery blasted out a whole pile of blog posts this morning (update: he just modified his blog structure which caught up the feed!). I started to follow his work after attending his "Resistance as a Resource" session at last year's Agile Conference in Toronto.

Two of his posts stood out because they discussed how to approach a technical system and think of it as a planned response system. He goes on to define system responsibilities, essences, events, and obligations.
The definition a system’s essence makes no mention whatever of technology inside the system, because the system’s essential responsibilities would be the same whether it were implemented using software, magical fairies, a horde of trained monkeys, or my brothers Glenn and Gregg wielding pencils and stacks of index cards.
In a second post in the series, he goes on to discuss the anatomy of responsibility further. Both are good reads, and I encourage you to check them out.

Staying on the Dale Emery kick for the day... I also enjoyed his post about "testing as an information service." He focuses on the quality assurance and testing team roles and how they affect the surrounding team.
Testing is an information service. The point of testing is to inform stakeholders about the system. This is not a new sentiment, nor does it originate with me.
He goes on to tell a story about one student in his class and how he realized the goal of his role is not to rub developer's faces in found bugs, but to inform the team and stakeholders equally of what is broken AND what works as expected. Testing is a litmus test, not a contest.

hmmm... I'm going to repeat that last one again and stake claim to the quote... "Testing is a litmus test, not a contest."

Monday, March 9, 2009

New manifesto...

If you haven't heard the buzz, a new manifesto was created and signed over the weekend. No, not a new agile manifesto, but a complementary one.

Instead of repeating others, I will joint point to them:

Friday, March 6, 2009

Friday highlights...

In case you didn't see them:
  1. Achieving Agility Needed for Business Survival (Info Q) - 8 values & ethics, along with a good comparison between agile and the restaurant business.
  2. Accounting for bugs the agile way - part II (ASD) - simple summary by Jack Milunsky of how to handle bugs in your process... yes, they are on the sprint backlog... no, they don't add to velocity.
  3. The Ideal Workspace (Cohn) - what is needed for a team (of developers) to fulfill their basic workspace needs?

Tuesday, March 3, 2009

TDD is good...

Most of you probably follow InfoQ and have seen the recent article referring to the study showing that TDD improves quality. The data seems to show that it is 15-30% slower to develop using TDD, but the defects seem to decrease on the magnitude of 40-90%. Most managers would agree that the defect savings would more than pay for the increased cost. The study had very comparative control subjects, so the data should be considered valid. A peer of mine mentioned that this type of TDD was not as mature as could be, and therefore would imply the gap might be even bigger with TDD mature teams.

Also, Mike Bria made an attempt at creating an elevator pitch to pronounce the values of TDD. His pitch is a little longer than my typical elevator ride, but it is a good explanation for those techies looking for a better understanding.

Monday, March 2, 2009

Enable, not strangle...

As an agile coach with successful experience in agile applications, it can be frustrating at times when working with a new group. A better way can be obvious but you see peers facing a train head-on while looking down at the tracks directly in front of them. The question is, can you really do anything when someone isn't interested?

I think this is the fundamental struggle in learning to be a coach. Just because you know (or believe) you have the answer, doesn't mean you can actually convince others of that.

Lately I've dug myself a little hole. As much as I use Rypple, retrospectives, and many other feedback methods, I still have to confess that I have missed things and made a few large mistakes. With certain groups, my desire to invoke change has led me to focus more on the change than on the people involved. I've been on the other side of this situation and know how dangerous it can be.

So... how can we measure when we have sunk into this situation? How do we keep an eye on our own actions and words to insure we are continuing to be a valuable mentor and coach?

I'm going to propose that resistance and negativity are two great ways.

If I'm using negative words or am resistant to listening or compromising, then I'm not in a good place. If the peers I'm trying to communicate with are responding with stress, fear, or negativity, then clearly I'm not making a positive impact.

Seth Godin talks about finding reasons to say yes instead of finding reasons to say no.

Krshna posted an interesting concept about Ohm's law and applying the physics of an electric circuit to agile. In both domains, resistance is a form of waste.

As a coach, we can't always know the best way to pitch an idea or message to the person we are directing it at, but we need to be very good at knowing when we've wandered across the interface of safety and discomfort well into the realm of fear and chaos.