Quote Series Part 1 - Agile

Over the years, I've collected quotes from my agile surroundings. This collection has been growing for almost 5 years now. I've used it to inspire my teams by writing a new quote on the top of the team's wipeboard every few days. It keeps them thinking and on their toes. I've decided to do a series of blog posts to share them with all of you. (it's also good filler while I'm on leave due to the birth of my 2nd child and many in the industry are at Agile 2009.)

Quotes on "Agile"

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

An agile manager must: manage & deal w/ risk, be results oriented, have high energy, be a team player, have multi-tasking ability, be improvement oriented, listen first and speak second - Lee Henson

Agile is:
- A project management process that encourages frequent inspection and adaptation
- A leadership philosophy that encourages team work, self-organization and accountability
- A set of engineering best practices that allow for rapid delivery of high-quality software
- A business approach that aligns development with customer needs and company goals
- Mike Cottmeyer / Jon Strickler

Deliver Frequent Releases, Empower Teamwork, Inspect and Adapt, Build Quality In - Karl Scotland

Agile != following steps, Agile != tools training
Agile = individuals & interactions, Agile = Collaboration & Teamwork
Agile = Environment Matters! Agile = learning from experience
Agile=reflection, Agile is an adjective not a noun!
- Rachel Davies (Agile 2007)

Agility might be said to be about encountering all the problems so early and so often that the effort to fix them is less than the pain of enduring them. - Ron Jeffries

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

The PO is part of the team, get over it!

The other day I posted about charging a fine for being late to the standup. I knew this would get some reactions, but one thing I should have been clearer about was that this wasn't a team problem, it was a PO problem. Sure enough, several of the LinkedIn forums got fired up over it and some heavy hitters had some good points to make (thanks Rachel Davies!).

I agree that this concept can backfire (fine, I'll pay the fine so I don't have to come), and there are solutions to that (double the fine for each offense). I also agree that if the majority of people need a fine to appear at the standup, then there is a much bigger problem occurring.

So, that background aside... one of the conversations appropriately focused on the issues we were having with the Product Owner. Why didn't he want to participate? Why was this an issue?

Lesson learned on that point: when this company went agile, we trained the developers, then the QA and analysts. Following the rules of Scrum & XP, we understood the metaphor of the Chicken and Pig very well. Unfortunately by following this rule, we optimized the team but de-optimized the whole value stream. It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world.

This post is in response to the following comment in regards to fining the PO for being late to the standup:

Why wait for the PO for a stand up? The PO should not be in a position to cause the problem. We try and utilize the Chicken and the Pig approach.

And my response:

There are many people who feel the PO is a member of the team: http://www.danube.com/blog/dan_rawsthorne/who_is_the_project_manager_in_scrum
Thus making them a Pig.

Also, the chicken and pig concept is dead in my mind. It's a coping mechanism for bad managers: http://www.langrsoft.com/blog/2008/08/pigs-chickens-and-asses.html

As our agile team matured, we found that many of our early retrospective discussions led back to the fact that the PO wasn't accessible enough. When your PO is the voice of many customers distributed globally, the PO is very important. If you have direct access to your customers (example: internal employees), then this might not be as important.

The last thing you need is for a team to go to the sprint review and demo lots of software that fails PO acceptance. Instead of making decisions in his absence and hoping they were right, avoid this waste and just treat him as a team member. If you can't do this, then get a proxy in place (lead analyst), or get direct access to the most important users to reduce the risk (beta customer).

Managers are not Super-You's...

Nancy McCall wrote an interesting post about somebody's thought that “Your boss should do your job better than you.”

Her points were:

- Managing people requires different set of skills than developing software, or whatever the job is of the group being managed.
- Proficiency in any area is worthy of respect, regardless of whether is it your area.
- It is not all about you.

She goes into further detail, feel free to read the full post.

I commented further:

Agree. I’ve modeled my management career path after those managers that were best at enabling their team to do something great with their collective powers. This typically meant that the team was collectively much smarter than the manager, but it was the manager that helped them get there.

If I had to be a better coder than the people I help manage, I’d be out of work. Instead, I’m a valued person in my organization because I can do things they can’t… and they come much more naturally for me than for them.

Say what you'll do, do what you say...

I've been noticing something new lately. I schedule a meeting and everyone confirms it, then about 30 minutes before the meeting several people come up to me in person or by phone to confirm that we are still having the meeting.

What?

Am I that distrustful or unpredictable? Is there a history of you showing up for meetings and them not occurring?

I'm confused by this... but then I got to thinking about it more. I realized that I've had friends or family do it also with gatherings. This behavior has risen in the last few years. What I don't know is if it has anything to do with our constant micro-distractions with technology, or a decrease in respect for each other.

Don't get me wrong, it bother me that people waste my time to verify that I won't be wasting theirs... but what I'm really concerned about here is that people do this to protect themselves against something that must happen to them all the time. This something is hugely disrespectful. It's the act of not following through.

I was raised in a community and culture where you stated what you were going to do, then you did it. If for some reason you couldn't, you had better set expectations in advance as soon as you could. If you didn't, you paid the price by harming that relationship. You didn't deserve to receive mutual agreements from that person in the future after that mistake.

Agile is about this. Standups inspire this. Reviews demand this. Planning and Velocity requires it. WIP limits assume it (I've seen managers bypassing WIP on the sly!). Retrospectives if run properly will inspire it also. Without it, everything starts to fall apart.

So people: say what you'll do, and do what you say. Follow through. Get to DONE! And don't limit this to your work, but include it in your relationships with other people.

Think about how much time we can save not second guessing stuff anymore!

Late to the standup, pay a fee! (or not?)

In my last company we realized something very quickly. If the standup meeting is only 15 minutes long, then anyone who is 5 minutes late probably causes the meeting to extend by 30% while we repeat stuff. If we aren't repeating stuff for the late person, then you have to question how engaged that person is in the team.

With that in mind, we started complaining about lateness over 1 or 2 individuals... one of which was the PO. His initial solution was to start without him. We poked at this and it became "meet without me". This turned into our marginalization of his input, which degraded to major problems during sprint review because the customer (PO) wasn't on the same page as the team.

So, we agreed to make this marriage work and the PO said he'd make an effort.

The cycle started over. He always had excuses. This meant that other people started riding his coat-tails and coming late too. Eventually the standup was a mess because it wasn't predictable. People who were on time got punished by those who were late (and didn't respect the team).

How did we solve it? We added a fine. Now, Foo wrote a great blog post about how this will backfire. Once you put a price on something, it's valued a different way. Sure enough, our PO threw $50 in the goldfish bowl and stated "That will cover me for the month and buy pizza for the team" as if he was doing something good.

New rule... $1 / day for being late, fee doubles for consecutive days.
Outcome: PO is present every other day and buys pizza for the team every month or so. This was a compromise everyone could live with.

Before agile came along, life was easier for me...

The problem with Agile is that it helps us realize early that there might be problems. Granted, this gives us time to solve the problems and get the project on track, and it allows us to have a higher success rate.

But I miss the good old days where we happily worked for months until the death march started. It allowed us to stay blissfully happy and then blame management for the last 3 weeks when things went wrong. Some of us would get good at finding long projects where we could work for months on lines of code and then bail on the work and jump to another job or company right before it went into the crapper. Becoming an expert in our skillset was simply about perfecting our selection of projects and timing them well.

Now we actually have to be on top of our game every day! That's a little bit more challenging than I expected. I went and got this computer science degree so that I could sit in a cube and write code and get paid lots of money for it. What's going on here?

Yeah... unless this is the first time you've read my blog, you know how I truly feel!

Read the Cutter Consortium's version of this viewpoint.

Agile Documentation, what is it?

Elroy Serrao asked a question leading to a good discussion about documentation on LinkedIn's Agile Alliance group.

His statement:

The whole "document via index cards" idea felt a bit weird though. Partly because I haven't been able to really view physical "index cards" as something that can be tracked, searched etc over a long period of time. So I was wondering if anyone would be willing to share their experiences, best practices etc. in this area.

The following is a couple of the high notes:

From Siddharta Govindaraj:

Think about how much value a piece of documentation produces. If you think it is worth it, then go ahead. If you feel it is overhead then dump it.
You need to ask yourself three questions: Who is the documentation for? What is it for? How will it be used?

From Levent Gurses:

There is no way in the world that I, or anyone else on my team, will spend time digging a cabinet of index cards to find out about the details of a story that happened 3-4 months ago. It will just not happen.

Instead we use a modern WIKI, like Confluence - which among other things keeps page versions. Requirements and stories captured in Confluence are always current and traceable. Combined with SCM labels and release notes, any person on the team is always 100% sure what's in Production, what's in Testing and what's currently being developed.

From Kevin Schlabach (me):

I'm most aligned with Levent's answer, but here's my simplistic cut at it-

If you do TDD... add a database & architecture model to your tests and you have your tech documentation (as much as is worth keeping up to date).

If you use automated Acceptance Tests... add a domain model and you have your business documentation.

If you use an electronic system for backlog management... you have your project documentation.

If you pair program and rotate pairs daily, you insure knowledge is spread throughout the team.

If you layer on a wiki, you can capture conversations for the few days it's needed until working software is built.

If you don't do some of these things, you might require more documentation to cover you when you want to ramp up new people or explain your API's to other groups.

This is a simplistic overview, but what I'm getting at is that you still need some documentation that goes beyond your index cards, but it can be a living, breathing part of your process.

Read up on some of Alistair Cockburn's work (Crystal). By applying game theory, you always think about working today to insure success (wins) tomorrow. Documentation is meant to be a way to survive in the future when needed.

From Gary Tinnes:

I have a rule: “the amount of a document that is read is inversely proportional to its size”. If you document, keep it short with lots of white space to make it look smaller than it really is. Focus on bullet points (clarification if needed) and graphics.