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.

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.

What if Congress used Agile?

Eric Camulli posted this interesting question in the Agile Alliance LinkedIn group:

Could Agile help Congress with healthcare reform? I'd like to see someone take a stab at applying scrum principles to the "great development project" of our day...

Our country's healthcare "project" could end up looking like many Waterfall projects...not on time, over budget and not meeting customer's needs in the end.

Unfortunately the conversation quickly started to veer off into moral, ethical, and political opinions/viewpoints/jokes unrelated to agile...

But I thought about this a little bit and I did find some comparisons between our legislative system and large companies that aren't agile. Here is what I ended up writing:

I think the real problem with anything going through Congress is that they don't "go to the gemba". They rely too much on research and lobbyists to translate the needs of the "customer" for them.

Congressman act as if they are Product Owners, but they don't have the domain knowledge or "end user" interaction to truly own that role.

So... I guess my solution is that we need to find a way to decrease the feedback loop distance between those affected by policy and those creating it.

Does anyone else have any ideas or insight into this one?

Bees self-organize, why can't we?

There is another interesting thread on LinkedIn's Agile Alliance group. I caught up to the conversation late, so instead of adding my two cents, I just want to share the highlights here.

The Question:

In another discussion thread I saw many references to "self managing team" as being one target or goal for any Agile team.

Here are few hypothesis related to that:

True or false?
1. Teams can only become self managed if they have worked togather for long.
2. Teams (and through that companies) will never get to take advantage of their ability to be "self-managed" since the members will be transferred to different projects after they have completed their existing project.

I think the first response is the greatest, so I applaud Bob MacNeal's response:

1. False. Complete strangers are capable of self-organization. Bees do it. Humans do it too.
2. False for some teams. True for most companies. People have an amazing capacity for self-organization. Organizations habitually muck this up by layering in a mojo-killing culture of command-and-control.

Mark Ferguson:

A team that can't self-manage their own internal dynamic will fail. A manager can't micromanage each individual's interactions with other team members, although some do try!

Wayne Peacock:

Success comes only after a series of failures. Scrum or Agile is no silver bullet. The best thing about Scrum is the constant inspect and adapt cycles...

and finally, Sharan Karekatte:

Self-management is what Scrum teams do. They actually manage the user stories and tasks from the Sprint Backlog on a daily basis. They are not told 'how' to complete the work, but 'what' the Product Owner would like from the team in order to deliver the ROI and fulfill the Product Vision.

Does generalized roles mean a team of equals?

A very interesting discussion on LinkedIn got me to thinking...

If a Scrum/XP team adopts pair programming...
and everyone should be able to pick up anything...
and anyone should be able to test or fix the build...

does that mean there is no longer a need for team lead? tech lead?

Hmmm...

Interesting discussion.

My thoughts:

...every Agile/Scrum team I've been on has had "leaders" that fill the roles of project or tech lead. In my mind, the advantage of agile is not to normalize the team to a bunch of equals, but to reduce the distance between the outliers. Keeping some diversity in the team is critical to team wisdom (read Wisdom of Crowds).

Feel free to join in the discussion.

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?
   

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.

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.

UX and Agile (part 2)...

One of my highest visited posts is the one I wrote about usability. I've since added updates to direct people to other ideas. Sometimes I feel like I should write more on this topic because there is a large void on it within the agile community, and I spent more than five years focused on it. But the reality is that I have been focused on process, PM, agile for the last 4 years now. Usability is like SEO, you need to be living it today to be an authority. My history in it allows me to carry good conversations, but I'm not going to pretend I'm still an expert.

With that lengthy, wordy introduction... here is a good second part about usability in agile. I just happen to not be the one who wrote it.

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.

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.

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!

Nobody will listen...

Eckford complains that people are head's down. As a contractor, he's in a tight spot as his tenure approaches an end but he still has something to share. Why can't people value collaboration over isolation? Why aren't they interested in the bigger picture and planning for the future game?

I attempt to provide my thoughts on providing advice without inflicting change or burden... what are your thoughts?

My nugget: "timing is everything, sometimes patience is required because they simply aren’t ready yet."

Business Analysts have to stick around now...

Karmark96 is a budding business analyst in a company starting to borrow practices from Agile. He was surprised that his new role follows the product life past definition and through testing and support.

I explained how this was true while at Siemens after going agile also. My nugget:
"Before we went agile, the BA would write documents and then dump it on the dev and test teams to deliver and fix. In this scenario, a lot of flaws were found in the requirements and the BA could be long gone onto the next project. Agile was about removing this waterfall and bringing these timelines together."