French Fries! (important and fun team habits)

I work in a company that values work/life balance. This means that when people need to work from home for a good reason, they do. But this in turn means that they have to dial in for our standup and other meetings that day. Sometimes, it is hard to hear on the phone from home, especially when 3 people in the meeting room are looking at each other and talking over one another.

"FRENCH FRIES!"

Yeah, that would probably get your attention if someone yelled it out in the middle of a meeting, wouldn't it? Well, that's the phrase that the team created for our standup to state... "hey guys, you are making it impossible for me to be an equal member of this discussion; or even follow along". This is typically caused by people talking at the projector screen instead of the phone (too quiet), but it has other good uses also.

It's a silly phrase. It might seem unprofessional to some... but it's part of our culture. (Don't ask how we came up with the phrase, I honestly don't remember.)

My point?

Have fun in your team. Find ways to help the chemistry of the group work. Make sure people respect each other, and provide ways for them to communicate feedback in a constructive way.

The other day, a higher level manager yelled French Fries in a meeting where most people in the room hadn't heard it before (not people in our standup). It made me laugh because it shows that the idea is effective and is spreading.

The Thumbtack and Hole Metrics...

Sometimes metrics can just appear in front of you very simplistically without any effort. I've discovered two new ones which I call the Thumbtack Metric and the Hole Metric.

The back story is that we use a corkboard to track our work. This is a high level view of the biggest priorities in VersionOne, our legacy ticket system, and any other queues of work we have. Because our one team supports all company operations AND does new product development, we have a hybrid balance of many different approaches. The board is our central view.

I attempted to force WIP limits onto the board so that it was a true Kanban board, but this simply didn't work in our environment for multiple reasons (nature of our work along with company culture). BUT, it has been very interesting for the team to start realizing when they are attempting to do too much. As the coach, this was something I used to pro-actively point out, but I'm learning that it is better for me to be reactive so that the team themselves can learn from experience. (Unfortunately, a child understands "hot" much better after being burned.)

This maturity and growth has led to many great conversations on the team. They start as individual discussions of philosophy between me and someone on the team, and then they become team discussions where we improve something in our process.

Through all of this, I've noticed a few things that the team now sees after it has been pointed out:

1. A problem item typically has many thumbtack holes in it (The Hole Metric). The "holier" the item, the more of a problem it is. What is the causation behind this correlation? Well, every week we scrub the board. Every few days rows get re-aligned. If an item is picked up on one day and finished the next... it has one or two holes in it. But if the item gets pushed around for days and lost under other stickies... then it get punched A LOT! So... we now have a metric that can be used to identify areas of improvement. When a "holy" item reaches DONE, it is a good topic for a quick review/mini-retrospective.
2. Every item on the board needs a thumbtack. We thumbtack stickies so that they don't get blown off while moving the board around (our board sits in a central visible area of the company and is carried into our dedicated standup meeting room every morning). Sometimes we group things with one thumbtack, but in general, there is a correlation between the amount of work on the board and the number of thumbtacks used. I haven't been successful at imposing WIP, but I have been successful in showing that when we run out of thumbtacks, we are in for trouble. This is the Thumbtack Metric. If you need more thumbtacks to stick things onto the board, you have a problem coming (or are already knee deep in it). Conversely, the CEO notices that too many unused thumbtacks might be a sign of available capacity (so I take thumbtacks off the board at times if needed ).
   

See... all those documents, white papers, conference sessions, etc you've read about metrics... they were overkill. There are simple metrics right in front of your team every day. AND, they are much easier to sell, explain, and use as an indicator moving forward.

So... what's your thumbtack metric?

Bored in the standup? Raise your hand...

I just read this interesting post about a scrum team that borrowed the concepts of yellow and red cards from soccer to aid their standups. 3 yellow cards or 1 red card means "move on".

Unfortunately, I live in a country where soccer is not the biggest sport... and I'm sure we would just misplace the cards.

So, let me share what has been working for my team for over a year now...

If anyone in the group feels that the current topic is not relevant to the group, they slowly raise their hand. They do it slowly to not be obtrusive and rude. If other people agree with this person, they can decide to also raise their hand. If there seems to be visible consensus, the people speaking must quickly assess their conversation and decide how to close it. They can either put it on the parking lot, or realize they aren't getting anywhere with it and just stop.

The parking lot is a list on the wipeboard in the team room. The person closest to the board writes the topic and the names of the people who are involved. At the end of the meeting, those people stay behind to pick the conversation back up.

If the person raising their hand is alone when their hand is fully raised, they suddenly realize that they are alone in their stance and drop their hand. At this point they wait for the good of the team since clearly, everyone else finds the conversation valuable.

And yes... our standup is short. We have about 15-20 people every day... and we average about 17 minutes (15-20 minutes) even with these included conversations.

Recently, we had an amusing moment when someone raised their hand on themselves...

Quote Series Part 6 - People

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

Quotes on "People"

If you don't make mistakes, you are not working on hard enough problems - Frank Wilczek

Open yourself to critics and take your capabilities to new heights. - Denise Caron

If you goof, apologize. If you apologize, mean it. - Seth Godin

If you want something to happen your way, try asking instead of demanding. - Seth Godin

If you’re getting feedback, realize that the person must care a lot to have sent it. - Seth Godin

Anyone who uses the term “resource” when referencing people has to put $1 in the “inappropriate comment” jar! - unknown

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

A tool is nothing without a skilled artisan to handle it. - unknown

Don't inflict change on people. - J.B. Rainsberger

A dead scrum master is no good to anyone. - unknown

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).

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!

Collaboration OVER Documentation...

Triggered by this good post by Fabien at the Server-Side Pad...

Folks... the Agile Manifesto does NOT say that we should throw documentation out the window.
Similarly, it does NOT say that collaboration REPLACES documentation.

Fabien's points are important since both of these misconceptions are common in newly transitioned agile environments. Teams seem to forget that anyone on their team can be pulled off at any moment and replaced with someone else. If enough of this happens, then their tests, code, and DOCUMENTATION are the only thing left after they are gone.

Part of my comment left on Fabien's post:

The manifesto clearly states that documentation is valued, but conversation is valued more. (Hence your important qualifier is already built in, people just overlook it!) What they were really trying to combat was the old-school philosophy of writing a set of requirements, believing it was done and pitching it. This lack of review and collaborative thought always led to a breakdown and finger pointing somewhere later in the process.

I wish I worked there...

Actually, I'm [probably] on a cruise ship in the middle of the Caribbean right now... so I'm in no position to complain. But, there are days where I ponder if it would be more fun to work a specific role for a company that is successfully agile, or to work in a company-wide Process/Project Coordinator role like my current one where I can constantly infuse agile concepts into the business in a stealth manner.

I'm undecided...

But, if I were to look for an agile company... it might be a little bit like this.

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

Specialized resources can't be outsiders...

Disclaimer: To protect the innocent, I'm quoting people from a forum conversation, but I'm not going to mention where or who. If you don't agree with this approach, feel free to drop me a line and complain. It just wouldn't be fair for me to put their names in the limelight without explicit permission.

Problem:

In our company some resources like DB developers (and architects) are shared. This makes sense as one team seldomly utilizes one DB developer 100% through the whole sprint. I know we have to use specializing generalists, but you inevitably end up depending on specialists outside of your team and there is nothing I can do to change that. I have problem with planning their demand and availability in v1 [our project management tool].

I need some way to predict when a task will be started in the sprint, so I can notify my shared resources in advance and make sure they are able to focus on that task.

My proposal:

This is difficult and is one of the anti-patterns in agile. Dependencies (especially on resources) are a major problem and require lots of management. You should read Mike C's recent post on this.

One of the changes of going agile is creating a dedicated team where people swarm as needed on the right things. Unfortunately, as you already know, not every skill area can be dedicated in larger organizations. I used to be a usability guy, and my first experiences with agile were excruciating because I couldn't keep up. Things happened when I wasn't allocated and I was always playing catch-up. Also, the team was always upset I wasn't there when they needed me (which meant they started to ignore my role).

Eventually we moved towards "simulated" dedicated resources. I would be "dedicated" to the team every morning every day. In the afternoon's, I would "consult" to other teams and float. This meant I had one main priority project and the others were in maintenance or ramp down. This allocation was tweaked every sprint (most project sprints were aligned). We did the same thing with our QA folks. They had to sit in the team room for at least 3 hours every morning. The whole team was present in the same room for a window of time each morning. This helped a lot. As a specialized resource, I had to prioritize my backlog across projects and work accordingly (and let people know what I couldn't do).

This created a balance. The team might have a dependency on a missing resource for a few hours, but they always knew the resource would be back tomorrow and they would work around that dependency until then.

If you can't dedicate your resources, then you need to lighten the spread of things they work on. Another good post by Tim Ottinger on that topic.

None of this is a tool issue. By going agile, you could trick yourself and plan it out in MS Project or MS Excel, but the reality is that it wouldn't play out as you planned. Instead, you are dealing with a process and culture issue. You have to get your team together and talk through it. See what they can negotiate would work for them. The shared resource is going to have a different set of needs than the scrum team since they are a member of multiple groups. It's a great retrospective topic and it will take time to work out. I'm guessing you won't end up with the textbook agile solution, but part of being agile is adapting.

Response summarized:

I really am not in control of this problem and can't change it. Thus, I need a way for the tool to help me trigger notification that a specialized resource is needed at a point in the middle of the sprint.

Last words back:

Having super-specialized resources like that will make it very difficult. To manage, schedule, and predict dependencies to that level of detail lends itself more to GANTT charts than backlogs. There's little flow or adaptation when you have to manage to these details and therefore this will be a hindrance to maturing agile and letting your team become self-empowered and self-managed.

I'm not being a purist and saying it's not possible, just that it is a difficulty to be overcome within agile. At a prior company, we overcame the architect role by allowing the team to build whatever they wanted and handling the standardization and schema naming convention issues as a refactor by the end of the sprint. Unfortunately this led to a different set of problems.

Good luck.

A 3rd person weighing in:

... In reading your post, I'm not sure what your role is in relation to the team and scrum master, but it appears that you may be trying to manage resources, instead of shifting the responsibility of self-organization to an empowered team.

Raise your hand...

There is an interesting discussion in a LinkedIn group about how much side discussion should be allowed in a stand-up. Many of the answers revolve around the famous three questions and why they are important... unfortunately, this may be missing the point of the original question. The question didn't preclude the "3 questions", but instead is focusing on how long tangents should be tolerated as a result of the answers to the 3 questions and the pursuing discussion.

I'm a believer that the stand-up is about saving time and creating a feedback loop. If someone has something to share that most people should hear, then the stand-up is potentially the most efficient time to have this discussion. Telling people to stop talking after answering the 3 questions is going to turn the meeting into a status meeting. In my group, people use this time to also talk about lessons learned in their prior day (I screwed up and here's how you can keep from repeating my mistake...).

I have two possible solutions for this question:

• parking lot: In my last group we went around the group once and answered the 3 questions. Any tangents or questions that lasted more than a few seconds were halted by the scrum master and written down into a "parking lot" list. After everyone had taken their turn in the stand-up, the parking lot was quickly prioritized based on urgency and overlapping resources and quickly knocked out post-stand-up (or scheduled later).
• hand raising: My current group is still learning what it means to be agile and is shifting from a command and control culture towards a self-managed one. Our rule is simple... people say what needs to be said at the stand-up. If anyone in the stand-up feels that they are gaining nothing from the current thread of conversation, they slowly start to raise their hand. When the majority of people have their hand up, the minority of people still interested simply state that they will take the conversation offline and we go back to the 3 questions and working through the stand-up. If I'm the only one with my hand up, then I quickly drop it with the realization that the team finds importance in the topic and that the most efficient time to have this conversation is right now. Maybe we aren't doing a stand-up for that brief moment, but we are being adaptable (agile) in our needs.
  

That being said, our average stand-up runs between 10 and 15 minutes every day. The hand raising approach creates a sort of peer pressure system where people are conscious of the potential that hands will go up.

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!

F2F communication is always better...

Why is it desirable to have all team members in a co-located room?

1- Face to face communication is more efficient

• facial expressions, voice inflections, and body language are all part of communication
• it is faster to talk than type and read
• you can pull in other forms by using a wipe board or pointing at a diagram
  
• there is less mis-communication
  

2- Spoken words in the background can be absorbed or ignored at your discretion
You can jump in when you know something that helps. You can listen when you know it helps you. You can ignore it when it doesn't matter. Information becomes transferred by default and this is referred to as osmotic communication.

3- Communication decreases by the length of a school bus
I was sitting in a session with Alistair Cockburn at Agile 2007 when he started to describe this study he did for some big company. Simply put, a person's likelihood of getting up from their desk and walking to talk to someone about something they need decreases exponentially by the distance of a school bus (weird unit of measure, but it translates for most cultures). This means that even if they NEED an answer to something, they will probably make a guess and keep working (on possibly the wrong assumption) until the next time they see that person. With this data, you start to realize that next door offices aren't the same as two people in the same room (and that there is a difference when those offices have doors next to each other vs. 6 feet apart).

So this post focuses on communication instead of co-location, but the two are tightly tied together since communication is one of the main reasons for a team room. I know that co-location isn't always an option, so we need to adapt to the next best solution when possible. The point is not that non-co-located teams fail; it is that co-located teams are faster and more productive.

Final thought: Putting the right people together in a distributed fashion will always beat the wrong people together in a co-located room.

Follow-up note: Recent post on the "secret sauce of offshoring" posted on ASD.