My Overview of Agile Presentation (to a local PMI Chapter)

I was invited to give a talk about Agile to the Delaware Valley PMI Chapter on January 7th. The audience was going to be filled with local PMP's, some of which would be skeptics, and some of which would have been burned by bad agile implementations. I was worried about how to normalize their knowledge, and I had to do it in less than 45 minutes so there was room for Q&A.

Once I realized that I couldn't cram Scrum, XP, Lean training in along with a proven case study... I decided to go for the overview and provide them what they needed to find out more. I wanted the group to understand the Scrum is Agile, but Agile is more than Scrum.

As far as I can tell, the session was a success. I got positive feedback at the end, and I felt I made the most of our time.

If you want to get a copy of the slide deck, you can download it here. Since I'm not that popular of a guy yet, hopefully this won't overwhelm the daily bandwidth limits of my personal website traffic restrictions. If you get nothing, email me or put a comment on this post and try again tomorrow (and I'll have to move it to another host).

Having been through this experience, if there is anyone in the Philadelphia region that is interested in having me come talk about Agile or some specific piece of it... feel free to contact me. You can find many ways to reach me on my personal site.

Individual Recognition on a Scrum team

Hmmm... another conversation in the Agile Alliance LinkedIn group. Here was the question:

Should we have an individual recognition award in a SCRUM team? Lots of people says that individual award is against an Agile methodology. Award should be given to a team not to a individual team member.

I tried to play a passive role and stated the following:

I have seen these conversations occur many times in many forums and the end of the conversation always results in a "NO" with a very good list of reasons. The risks outweigh the rewards no matter how you set it up.

There is a gray area of disagreement on whether the team can spontaneously award a peer or not. But the minute you make it a regular event, it wanders back into the problem area.

The best reward is taking a respected peer out for coffee/beer and telling them you appreciate their contributions, or saying in front of the team what good they've done. This doesn't need to be organized.

And the first few responses before mine were in line with this:

If you want to have a well jelled team - absolutely not.
The only exception I can think of is if the team requests it.
But that sets up a conflict of interest. - Jay Conne

The only time an individual award is appropriate is if the team wants to acknowledge an individual who has made a significant contribution that made a big difference TO and FOR THE TEAM. - Shane Hastie

But then we got the extremist viewpoint thrown in:

The Communists tried the concept of Co-Operative farming. Under that framework, no individual was supposed to be better than the rest. Needless to say, the concept didn't work out.

So I found myself having to take a stance and state the following:

Here's the best way to summarize what I'm insinuating/feel:

If an award is financially valuable... and it is regular (creating a sense of expectation), then it has a higher probability of creating individual behaviors over team behaviors unless your team remains constantly aligned to itself (resources typically fluctuate too much for this to be assumed).

If a reward is simply a show of appreciation and a call to what behaviors or achievements the team should continue to grow and repeat, then this has a higher probability of creating a collective and positive team behavior, especially if it is unexpected (not scheduled), and driven by the team.

Feel free to include your own thoughts in the comments, but I have to say that I'm not very open to debate on this one.

Quote Series Part 7 - Philosophy (contd.)

This is part eight of the series, to see what this series is about, click here. This is the last in this series.

Quotes on "Philosophy"

Make time to make it right, or be prepared to do it again - Denise Caron

Embrace new directions... not everything you do will be used, sometimes, the target changes. Re-aim and move on! - Denise Caron

Change is constant... don't fight it, leverage it. - Denise Caron

Don't fall in love with your product, someone will be there to change it, it's a promise. - Denise Caron

Blindly following rules is a fools errand. We have enough grey matter to discern when the rules are helpful and when they are not. We have the responsibility to continuously measure whether the rules are helpful, or whether they are not. - Uncle Bob Martin

It is solely and utterly the team’s responsibility to figure out what to do, and to do it. - Ken Schwaber

"Better" is typically a word leveraged by those in control (eyes of the speaker). "Appropriate" is typically a word referencing those affected (surrounding group). We should seek that which is appropriate, not that which is better. Avoid elitism, blanket statements, or viewpoints of limited individual experience. - Kevin E. Schlabach

Without prioritization, nothing is a priority. - unknown

The practices are not the knowing: they are a path to the knowing. - Ron Jeffries

To tolerate a problem is to insist on it. - Ron Jeffries

If it hurts, do it more often - Martin Fowler

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.

Quote Series Part 7 - Philosophy

This is part seven of the series, to see what this series is about, click here.

Quotes on "Philosophy"

...initiating requires a willingness to look foolish, stupid, or uninformed. To initiate great things, you must truly not give a damn about what people think about you. - Seth Godin (Tribes book)

what you call things and their meaning matters cuz it sticks in people's mind - Twitterstream from Lean Kanban 2009 conference

No good idea can be judged by the number of people that get it - Ron Jeffries

Learning faster than our competitor is our only sustainable competitive advantage. - Denise Caron

Change happens fast, our competitors will not wait for us to get ready. - Denise Caron

Self-organize... don't wait to be told, be accountable and stride forward. Self correct! - Denise Caron

Satisfaction comes from closure- open-ended tasks can't be closed - ObjectMentor coach

Managing the project is MANAGEMENT'S responsibility... do the best you can with what you know now and program as though you have time to do a good job. - ObjectMentor coach

If you deliver every day, then no deadlines are special (or scary). - ObjectMentor coach

If it doesn’t hurt, then you’re probably not changing enough. - J. B. Rainsberger

If you just do the same things, only faster, then you’re missing the point. - J. B. Rainsberger

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.

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!

Participate in change, don't expect it to happen

One of my peers asked me why our manager kept assigning work to specific resources instead of simply prioritizing it and letting the team pick it up as people were available. The upside of this question is that they are starting to understand some of the core agile concepts, but the downside is that this is a hard question to answer. What they want to hear is that I will go convince management to stop meddling with the team and allow them to be self-empowered and self-managed. They want to find the better way on their own, but it's not that simple.

The manager does this for a reason. To him, it is important to sort his desires taking efficiency into account. In his mind, this is most affected by WHO is going to work on it. Instead of pushing for anybody to be able to work on anything (something that seems insurmountable), he re-arranges his desires and works with the system in place. Unfortunately this is a very short-sighted approach, but we haven't provided much of an alternative. Right now, the manager only trusts himself to make these decisions.

I pushed back on my peer. I told them that it was up to the team to change this situation. We have to do more than simple code reviews. We have to actually insure that multiple people on the team know how everything works so anyone can modify it. We have to build trust with management that we can handle work efficiently in whatever order it arrives. It is a slow path to managers having the freedom to prioritize and granting the team control to manage themselves. We have to build the solution, show it exists, and earn management's trust.

I find it is easy to convince a team of the underlying agile values and principles. The harder part is convincing them that they are an active part of the solution. They see all the ways agile solves their needs, but they forget the needs of the business and management. Teams must take ownership of showing managers how agile solves their needs also. Everyone has to understand that we are trying to optimize the whole system and not just the part that the team plays!

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.

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

Get constant personal feedback...

Agile is about constant feedback loops. Release, iteration, daily scrum, pair programming, unit tests... they all provide feedback.

How are you getting feedback on yourself? Are you doing a good job? Do you communicate well? Do your team mates like working with you? Is there anything you can improve?

Something I took away from Agile 2008 is that regular personal feedback (weekly) is much more impacting than a yearly or quarterly review. This is why I've started using Rypple. After every presentation, I send it out to the attendees. I've sent it out to solicit peer feedback to support my self-review with my manager at the end of the year.

I tried something like this before using index cards and received good results, but this platform makes it so much less time consuming.

Try it... it might help you also. Check the site out and watch the quick video for more info.

Don't work for jerks 2...

One of the reasons people pursue agile approaches is due to the culture that is found within it. Instead of treating people like resources (cattle), we treat them as trusted team mates. Instead of focusing on a waterfall GANTT chart and controlling impossible things, we focus on communicating with the customer and setting realistic expectations.

This is reflected in the agile manifesto.

It is reflected in Norm Kerth's directive about retrospectives:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

It is reflected in Seth Godin's comments about not working for jerks, and Lynne Ralston's things to look for (prior blog post).

But I have come up with my own list. I like it and I wanted to share. So here is Kevin E. Schlabach's work environment directive-

A good work environment is a place where:

• everyone knows that we are all fairly compensated (removing distraction and providing stability)
• my peers and I share a pride in our work and take accountability for what we deliver
  
• our teams are respected and empowered (education and training is accessible, impediments are removed, feedback is responded to, there is a low level of politics/process/red tape)

allowing me and my team members to focus on:

• helping the company make money (profit, not revenue)
• keeping the customer exceptionally satisified (insuring long term viability)
• creating business value for the users (sometimes different than happy customers)
• staying prepared for the future (long-term sustainability, not short term money)
  

A good work environment is NOT a place where:

• people work through checklists of tasks
  
• meet the minimum requirements of their job
  
• are compensated unfairly
  
• therefore forcing them to constantly be on the lookout for better opportunities or ways to get ahead of their peers

What are your thoughts? Do you have your own version of this?

The emporer has no clothes!

I worked with Mike Bria at a prior employer and he's a really smart guy that quickly switched from agile skeptic to agile champion (he says shepherd) when we went through the transition from waterfall. He recently wrote a great article on infoq about how agility means truthfulness.

Everyone read that book as a kid. The emperor is convinced and the townsfolk have a good laugh. How many projects have you been on where the project manager spends his time fudging the numbers so that you can all keep your miserable project afloat for another few weeks? You know the axe will come, but you've bought more time. Is that how we like to work?

Back to Mike's point, agility is about transparency and truthfulness. I love information radiators. Take key points of data (a burn-down chart or cards-on-the-wall for example) and put it in a really visible place. Allow people to see what is important at the moment. Let people see the progress being made, or the things that aren't moving. Allow debates and discussions to happen.

Before you know it, you aren't spending time fudging numbers... you are spending time seeing the trends and correcting. You aren't hiding the failures, you are managing towards success.

If you work in a company where this is the culture everywhere, then you can kill a failing project even quicker (because it is obvious) so that you can get moved onto a project that is successful and much more fun to work on.

Agile can be about being honest with ourselves about where we are heading and what we need to do to be successful. Don't get caught without any clothes on!

Don't create a terrorist...

Peter Stevens over at Scrum Breakfast had an interesting article about questions to ask your CEO about agile. The idea is in line with items I've pointed to previously around explaining agile, specifically Mike Cottmeyer's elevator speech used to grab a CEO's attention.

The item in his post that caught my attention though was around the topic of being "ambushed" which he described as:

... a peer (i.e. rival in the company) learned bad news about your project before you did and surprised you with it in meeting in front of all your peers. Very embarrassing. Operational staff often learns about an ambush through a very heated discussion with said top manager after the fact.

This reminded me greatly of something a prior (non-agile) mentor shared with me about being a good PM and dealing with a "terrorist".

A terrorist is someone who doesn't believe in the same side of a debate or cause as you. Typically it is cultural or political. They hide in the shadows. They wait to strike. (If we exclude the recent surge in suicide attacks, ) terrorism was originally an attack from someone that was in hiding to make a point (and hope to make it again and again until they win). Typically, a terrorist fought this way because they were in the minority in that situation and knew they might lose their cause if they fight out in the open.

You could easily imagine this general description of a terrorist as the group behind any number of bombs left outside any embassy... but you could also easily envision this terrorist as a co-worker that agrees with you in meetings with many peers but soon after seeks out a higher manager to undermine everything that has been said and done in that meeting.

Agile is a cultural change. On some level it requires a company to undergo political or organizational change. It's not uncommon to find people that can't fit within an agile culture. These people can quickly hide once they realize they are outnumbered by the peers around them that embrace agile with enthusiasm. You need to be aware of these people when you are driving agile coaching and transitions. One of my favorite quotes is from J.B. Rainsberger who says... "don't inflict change". Tying this to my other mentor, I believe that if you do inflict change, you are at risk for "creating a terrorist" in your organization. To Peter's point, this will lead to you being "ambushed".

My old mentor also said that once you create a terrorist, it takes a long time to overcome that problem. Sounds a lot like that Bin Laden problem, doesn't it.

Being a good diplomat and reaching out to build relationships with people that are least aligned with your intentions is a good way to create respect across areas of disagreement. I believe it is also imperative to dealing with the above issues. Whether you are driving agile changes, or any other changes... this is something I've found valuable to carry in the back of my mind.

Improve yourself...

In a few weeks I transition from coaching our tech group within agile values, principles and practices, to training the "product" groups on many of the same concepts and starting to fold them into the agile culture. I realized pretty quickly that it was a good time to reflect on my past two years and think hard about how I approach this effort. Rather than easing into it, we're taking a more formal approach... and as a coach, I need to get along with people as I spend more time with them than I have in the past.

So, time for a personal retrospective.

At the end of a team retrospective I facilitate each month, I handed 3*5 cards out to each member of the tech team and asked them to honestly and brutally tell me at least one good thing and one bad thing about me. They looked at me funny, but after I explained why I needed this they asked for several more cards (funny, ha, ha).

What I got back was insightful. I'll spare you the 34 individual comments and share the most common:

• good: you don't inflict change
• good: you hear our concerns and adapt, you don't force us to do it by the book
• good: you presented the philosophies behind it instead of telling us just to do it
• bad: you talk to fast and cram in too much
• bad: you sometimes try to hard to help people and step on their toes in the process

There were many other insightful comments including the humorous remarks of my nerdiness, male pattern baldness, etc.

What's my point?

I'm proud of the fact that these people trust and respect me enough to give me honest feedback. I'm proud of myself for asking for it even if I felt like hiding in the corner as they scribbled on cards. I hope I have the guts to absorb this feedback and improve my coaching skills.

Peer reviews can be an amazing way to improve yourself if you are open to changing.

Do you have the guts to try it?

"No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today." - Kent Beck

Puppy vs. Pitbull...

The puppy approach: Every time this person comes to you and asks for something... they stick their head through the door slowly and kindly ask for permission to enter. They give you puppy dog eyes and you know they need something. But they are always so stinking nice that you invite them in to talk. They carefully explain what they need, and they work with you to mold their needs to something you can provide. When you help them out, they tell everyone about it including you. You get credit. It's almost like every time they enter the room, you just want to hand them a treat because they make you feel good when they wag their tail and shower you with appreciation.

The pitbull approach: You walk quietly by their desk hoping they don't notice. They remind you of your walks home from school many years ago when that dog ran towards the fence barking at you. You always wondered if the chain on their neck was long enough for them to hop the fence and take a chunk out of your arm. You feel fear and you always brace for the worst. This co-worker charges into your office, even when you are very busy. You can be fixing the fire that will keep the company out of trouble, but this person's stuff is always more important than everyone else's. You've tried dropping your work to help this person thinking it would make them appreciate you more, but it only led to them coming around more. They never give you credit for your work; they only complain about what you don't do for them. At the end of the day, you can only do your best to avoid them or figure out how to make them go away.

These are extremes, but which are you known more as?

Unfortunately there is a small percentage of people that are proud to be pitbulls. After all, they get quicker results. They get what they need from someone. Who cares how much damage is done if they get the desired result?

What do I have to say to pitbulls? I hope you enjoy getting just enough to fulfill your needs. The puppies around you get a lot more than they expect or ask for. You see, most people like puppies and will do stuff just to see the puppy happy. So, as a pitbull, you get exactly what you want... nothing more. The puppies are getting all the love.

Don't feel so special now, do you? By the way pitbull... over time, people learn how long your chain is and figure out how to stay out of your reach. You will actually lose your ability to get what you want over time. Good luck with that!

Sustainable Pace...

I hate that in the past I've worked in an environment where overtime or week-end work was a badge of courage. Where the pager was rotated and the holder expected a page every night at some point. And this was commonly accepted. People didn't question whether the pager should have been able to go a week without ringing... they were used to knowing it would go off within the next 12 hours.

Of course, the company didn't require overtime... it didn't condone burning out... but we also didn't force someone who stayed up until 3 am to come in late (or not at all) either. Where does the line between volunteering and demanding begin/end?

Well, here's a post that I like... it's a debate I've poked at for over 5 years and homebrutrout says the piece very well.

Trust is the core of it...

Agile Tools put up a great post about the degrading relationships on a team when manager/leaders don't trust the team. Estimates are sandbagged, scope is padded, deadlines are moved around, all sorts of games are played to compensate.

Wouldn't it be much simpler to work on the trust issues and move forward. I agree with the author that mistrust is as much your problem as it is theirs. Someone has to extend trust first to build a good relationship.

If you want to be entertained, then click through to the post and read my short play (in the comments) describing my interaction with a Product Owner who had ridiculous ideas about how to game the system rather than overcome the trust and commitment issues.