Waterfall is efficient...

If you want to see how Dan Rawsthorne gets to the following statement, you'll have to read the full post-

To put it quite simply, "waterfall is efficient -- agility is effective", and when we try to be efficiently agile we often wind up introducing false predictability into our process that winds up hurting us in the end.

I'm intentionally teasing you because it's a worthwhile read.

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.

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.

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.

You make your software suck!

Uncle Bob has spoken again... this time to the masses, not the managers or agile leaders, but to the folks doing the coding.

My take... quit whining and uphold your craft. Your complaints are valid, but they aren't an excuse to create crap.

Again, his post is here if you want to read more: How to Guarantee That Your Software Will Suck

Snake on the wall!

We found ourselves in a retrospective and there was a general feeling that there were a lot of interruptions in our day caused by "other people" outside the team. Nobody could put their finger on it and everyone had different unique examples. We couldn't easily say if we handle this problem or group of people then it will stop.

So how do you handle this?

Invoke the Snake on the Wall!

Every time a team member feels as though a task they are responsible for is delayed, they write it down on a post-it note. The note includes the time lost (compared to if they didn't have the delay), the thing affected, the cause, and their initials. They take the note and add it to the "end of the snake" which is a growing row of notes on the wall.

Over time the snake is monitored for repetitive patterns. The issues consuming the most productivity time are prioritized to the top of the list for the manager, scrum master, and team to focus on reducing or removing. Scrum masters look at it daily, managers look at it weekly (or when it grows suddenly), and the team reviews it right before retrospectives to trigger new topics. When an item is solved, those related stickies are removed from the snake and it is collapsed back down (you can't let it grow infinitely, otherwise you demoralize the team).

What does this accomplish?

• it validates real issues
  
• it kills false beliefs and misdirected complaints
  
• it quantifies the impact of impediments
• it creates transparency for managers who don't believe what you say
  
• it empowers the team
• it is immediate
• it self-prioritizes
• it uncovers surprises

On my last team we quantified for upper management how much time was lost EVERY DAY due to a bad source control system we were forced to use. It also provided insight into things we would never have thought were a problem. If used properly, it does a good job of quantifying the ongoing costs of certain types of technical debt.

So, I'm trying it a second time with my new group. We'll see how it goes.

Customer Feedback...

This may not seem like an agile post, but it is... I'll tell you why at the end.

• To all commercial businesses... stop playing holiday music before Thanksgiving (as early as Halloween). Surprisingly, I'm already sick of hearing it. I almost walked out of my grocery store last night because of it. If your goal is to remind me of the holidays to I spend more... you have passed my threshold of repetitive torture. (At least find something different than everyone else).
• To all retails stores with Black Friday doorbuster deals... people shouldn't die trying to get into the store to get a deal. Not only is this sickening, but it can be prevented. Use the Best Buy ticket model.
• Lastly, this whole situation with flight charges is starting to get out of hand. Fuel costs rise, so we get charged more for a seat. Then more for extra luggage. Now overweight people are being discriminated against. Please stop. Can't we just charge everyone by total weight? Put me and my luggage on a scale and charge accordingly. We are paying to move freight. Though I am human, I am a fuel cost just like my luggage and therefore I am freight. I could have 200 lbs of make-up and shampoo in my luggage which is no different than weighing 300 lbs in a seat. Kill the complaints and discrimination issues by charging us all the same way... by weight. (Note: this happened to me on a small plane flight in Costa Rica many years ago, so it is not a new idea.)
  

What's this have to do with agile? Agile includes customer involvement and transparent feedback. If someone reads this and changes something in their store or airline... then that is agile in action.

Cue groans... now.

The Agile Salesman...

Many of us find ourselves explaining Agile to others. What's good about it? Why to do it? How it helps?

The problem is that many of us have been burned by waterfall so badly that we take a "waterfall sucks and agile doesn't" approach. Unfortunately this approach doesn't work because it just leaves a bad taste in people's mouths and we then justify it with the concept that you have to experience agile to truly get it.

I've been following Seth Godin lately since he is a master marketing guru and his viewpoint provides insight into how to sell a new idea. Today he wrote a great post about how to pitch a concept. He uses the metaphors of gravity vs. evolution and how quickly these concepts were "sold". Here's a snippet:

Tactic 1: Try to tell a story that complements an existing story rather than calling it out as false.
Tactic 2: Try to make the 'proof' as vivid and immediate as possible. Like an apple falling on your head.

This is why I like Mike Cottmeyer's recent work around bridging the traditional PM's point of view with Agile's (he has a bunch of posts, so keep looking past this recent one if you are interested). Instead of saying waterfall stinks, he explains how agile enhances.

Agile is a Chinese Buffet...

James Shore has put out an article called the Decline and Fall of Agile. Within the past 2 weeks, I've seen it referenced in many places, including here on InfoQ, and it has definitely sent tremors through the community. Some people have misunderstood his intentions. This has led to many people talking about what languages and labels to use when discussing their agile experiences and whether using these labels properly matters.

Here's a quote from James's article:

It's human nature to only do the stuff that's familiar and fun, and that's what has happened with Agile. People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work.

Here's my opinion-

1. If you are not experienced in a successful agile transition that covers more than one denomination (XP, Scrum, Crystal, Lean), then you are at risk for making incorrect assumptions about what you can change or discard from the practices and still be successful. You either need experienced mentoring, or you need to follow the rules until you know why you do things and what adaptations will increase the value of Agile in your environment. You can't understand value without a baseline. You need to try the things unfamiliar to you to understand their value.
   
2. If you are experienced in a successful agile transition, then you MIGHT be able to adapt agile practices and patterns to a specific environment because you have experience and the foresight to see anti-patterns and other issues as or before they occur. You have to constantly take into account that your environment is unique and adapt accordingly.

To the chinese buffet metaphor-

1. If you've never been to a Chinese buffet, then you don't know what you like or don't unless you try it. You don't know which sauces belong on which items unless someone tells you.
   
2. If you have been to this Chinese buffet before, then you have a good idea what makes a good meal for your tastes.
3. If you have been to a good Chinese buffet before, but not this specific one... you might not realize that this one has very good versions of things you didn't like somewhere else unless you try it again.

Shu, Ha, Ri folks... Shu Ha Ri!