I am a big advocate of Planning Poker and we used the technique to go through a hastily assembled backlog of work. The team really enjoyed the simple act of collaboratively discussing the work and found the process really helped steward the discussion along. A few days into the Sprint, we were having a an ad-hoc estimation meeting when a particular backlog item came up for consideration. The conversation went similar to this, although the names have been changed.

“I know how I want to do that work, but we won’t be allowed to do it that way,” John said.

“What do you mean?” I asked.

“Well, I know there is a better way to do this. It requires me to take an extra day to learn a particular scripting language, though. That means the Product Owner will tell me I can’t spend my time that way. She’ll just want the fastest solution possible, which means hacking it in the way we have done in the past.”

I replied, “Remember that whole discussion we had about empowered teams? It comes down to right now.”

“What do you mean?” asked John.

“I mean that you are in control of the quality bar. That’s what this is all about! If you know this is the right way to do the work, why are you even offering another option? Just estimate the work assuming you will do it the way you know is best. That’s why you are the expert here.”

He gave me a funny look. “Really?”

John’s manager was in the room, and actively participating as a Scrum team member. I turned to him, “Do you agree the right way to do this work is the way John is describing?”

“Yes.”

I asked, “Is there any reason he can’t do the work that way?”

“No.”

“Are you willing to hold off the P.O. and let the team study up on this vendor’s scripting language?”

“Yes.”

It is that simple, folks. This is what managers so, they help their people do the right thing. An this is what John owes his customer, the best solution he is capable of creating.

I understand there are times when fires must be fought, and when perfect is the enemy of good enough. I get that gold plating is a time honored dysfunction. I also know the best quality software I have ever seen was actively managed by the teams who created it. The teams themselves were in control of the quality of the product.

It was a good day at the office for me because John told me something toward the end of our estimation meeting that made my day.

“This is the first time in my 17 years in I.T. I have been trusted to do my job the way I know it needs to be done. I feel great.”

That is gold. That is Agile actually working.

After genuinely pursuing and advocating this whole Agile thing for the last 5 years, I must admit defeat and withdraw my support from the entire Agile movement.

Uncle. I get it. It will never actually work.

Sure, TDD works, so does continuous integration, and a host of other great development practices. The truth is, though, that the real Agile value proposition was never about code. Better software with higher quality and excellent craftsmanship is a great side effect, but Agile is really about changing how products are created and delivered. Agile intends to fundamentally change the model of your relationships with clients and coworkers.

Fat chance.

The Ensconced Lag of American Business

Agile supports the idea of frequent delivery of value to customers. In order for this to actually work, a couple of things need to be true beyond showing software at the Sprint review.

1. If an organization has a product it can ship, it must actually ship it (gasp).
2. If a vendor has made a product available to you, your organization must actually be able to receive the update without tipping over.

Ship It

Let’s say that a high functioning Agile product team has a product that can theoretically ship every 2 weeks. Heck, let’s make it a month. Can the sales department keep up with that kind of change? How about the customer support department? Not typically.

Support teams require time to ingest these changes so they will be “trained” and able to support the new product release. Makes sense, right? Forget the fact that the product is sitting there gathering dust. Pretend the support teams have been playing with drops of the software all along and are ready to support the product the day it is code complete. Can we let the client have it yet?

“Not so fast,” says the I.T. department. We need to certify the new package with a week long burn in and load scenario. Never mind that testing has continuous and past memory leaks have been fixed and checked with automated regressions. Just follow the policy.

Okay, that didn’t really happen. I.T. has worked in close cooperation with the development teams and has an automated deployment system in place that allows push-button product deployment. Awesome. Can we ship yet?

Not until Technical Writing has completed the documentation and help files. What? Wasn’t that supposed to be included in the automated builds so that our documentation builds with our product? Yeah, but the tech writers were busy on another project this week and they need to get back to this project next week. They were proofing marketing materials for the next trade show that the software won’t be available for.

You get it.

Take It

You favorite vendor just dropped a new release of software, but you can’t have it. There are several reasons why, all quite reasonable.

I.T. is backed up with a 6 month project backlog and won’t be ready to roll that new version until the fall. Besides, all the users need to be trained because the new version is so dramatically different they will be crippled unless they are trained on it. Since we didn’t deploy all the incremental updates, it will be a huge User Experience shock.

Oh, and that new ESB version has spawned a porting project for all of our message adapters because BizTalk doesn’t support that little feature we were taking advantage of anymore. That rewrite will take a year. Good luck on that one.

And that new Oracle version? Maybe we’ll get it in 2013 because if we deploy now, it’ll break all of our Oracle forms applications that should never have gone into production, but did.

A Note on SaaS

Sure, Google can roll out a new version of GMail in 24 hours, but just ask SalesForce.com how any many past versions of their product APIs they are standing up because customers have deeply embedded into their system in non-portable ways.

The key here is that Google actually releases small increments of functionality that don’t freak users out. Small, incremental changes in a SaaS model can work. I still believe it.

Conclusion

These two requirements eliminate 99% of the organizations in the world from truly reaching that Agile utopia that is merely Lean.

How many of you are still using Office 2003 because I.T. hasn’t rolled out 2007 yet? How many times has your enterprise had to upgrade through 3 versions of a major enterprise system because no one had been installing the updates from the vendor? This is the norm.

Get it? Having perfect product in hand doesn’t really accomplish anything if we can’t give it to the customer and if the customer can’t take it anyway. Lean and Agile software development isn’t even close to enough. We need Agile business practices to really make this work.

Build your business practices to embrace change just like your Agile development practices do. Embrace continuous integration of the enterprise, not just your source code.

Have you ever looked at the website HotOrNot.com? It turns out that pretty much everyone from Quazzi Modo to Angelina Jolie ranks from a 4 to a 7. This is a prime example of our poor ability to estimate on a closely related value scale. It is pretty tough to tell if something is a 2 or a 3, but it is pretty easy to see the difference in size between a 5 and a 13. 13 is more than twice as big as 5, right?

Think about it this way: Does it really matter if something is going to take 3 hours or six hours? In software development, it typically doesn’t matter.

So the relative estimation model looks like this, in pursuing an estimate for piece of work A:

1. Is this piece of work bigger or smaller than that piece of work B that we already did?
2. Bigger? OK, how much bigger? 2X bigger? 3X?
3. OK, 4X bigger.
4. Here is piece of work C that we already did. It was estimated at 4X bigger than B. Is it roughly the same size as A?
5. Yes.
6. Cool, we are done.

Once we understand that we can trust these relative comparisons because we are better at them than empirical estimation, it becomes much easier to size our work. Look at things you’ve already done and estimate the new one in relation to the previous work. We get our relative size and convert it into time, dollars, or whatever the project managers need and we are done. This is a much faster (and accurate) thing to do than to break it down into tasks and estimate each task. Why? Because we will never get the tasking right.

There is a ton more that could be said (and has) on relative estimation, but remember this: The next time you have to estimate a project for your manager, make it easier on yourself by doing a relative size first. You’ll get back to coding much faster and you’ll find the numbers are amazingly accurate.

Now before everyone gets excited, the following blog post is not meant to compare developers to babies by any means. I am pointing out some similarities in how leaders should tend to and care for their development team, just as parents or caregivers we would care for a child. Basically, we invest time to nurture and care for them because we want them to be successful.

The article, What Every Baby Needs to Thrive, highlights eight steps every baby needs to thrive. For example, the first one is, "Show your love." What I have done is take this step and draw similarities to how this would apply to the success of a development team. This exercise can transcend outside of development teams to other teams, but this is a blog focused on engineering.

I have not altered the steps provided in the article. Each step and how they can be applied to a development team can be seen below.

Step 1. Show your love

How to Apply: Acknowledge them, give them praise, constructive criticism, tone of voice, genuinely care for their progress, listen to them, coach them, help them help themselves.

Step 2. Care for your child’s basic needs

How to Apply: Give them the knowledge and tools necessary to be successful, provide training opportunities for them to take advantage. Rest them, don’t just sprint them month after month without a break. A well rested employee is more productive. Reward them when they have done well, instruct them when they have not. Show them what it means to be a good developer. Provide a welcoming team atmosphere, lead the culture promoting it, and provide frequent feedback.

Step 3. Talk to your child

How to Apply: Communicate openly and frequently, listed and hear them, ask them how they are, what they are doing, learn how to help them.

Step 4. Read to your child

How to Apply: Present to them, demonstrate and show them what you know, teach them skills that they will learn to admire and achieve so they may help themselves.

Step 5. Stimulate all his senses

How to Apply: Give them a broad range of experiences, don’t just stick them in one technology or one facet of a project. Teach them all the parts of the project. See where there interests and skills develop. Groom them for future development in several areas.

Step 6. Encourage new challenges

How to Apply: Encourage them to raise their bar higher, step out of their comfort zone, teach a class, present a session, develop leadership skills. Teach them to teach others. Train the trainer.

Step 7. Take care of yourself

How to Apply: Lead by example, if you are not well rested (on top of your game), it becomes difficult to instill this sense amongst the team. Continue your education to grow and lead. Find time for yourself away from the team.

Step 8. Find good childcare

How to Apply: Develop a good team atmosphere. Who do you want your developers to emulate? Find mentors, get them training, pay for good speakers, find the right conventions. Encourage them to care for each other, to present to each other, to respect one another.

Obviously employees are different than family, but there are similarities. You cannot fire family, and you do not interview them before they arrive (in some cases I guess). Like leading a horse to water, you can only do so much for you developers to be successful. It is ultimately up to them to take advantage of the situation. If your horses refuse to drink and it hurts the team, then turn them into glue.

Thanks to my wife for sending me this article. My guess is that she never would have thought I would apply it to a development team. This agrees nicely with the sprint board we keep in the house for chores and duties. That reminds, we are overdue for a sprint planning session for the month of April.

Esther makes 7 points that I list below under the link to her article. If your leadership is asking for a nice explanation of what this Agile stuff is all about, giving them this article may be a good move to start the discussion.

Getting Clueful: 7 Things CIOs Should Know About Agile Development by Esther Schindler

1. Agile Creates Better Software
2. The Agile Mind-Set Is More than Processes
3. Agile Changes More then Development Workflow
4. Agile Doesn’t Mean "Chaos is Good"
5. Agile’s Benefits are Worth the Wait
6. Agile Isn’t a Silver Bullet
7. Success Depends on People

The first question type is also the largest problem:  The Closed Ended Question.  Consider the question “Have you used ASP.net?”  The interviewee can easily respond with a short, yes or no answer.  You have very little information gained from such a question.  I see this question type used a lot with the same result, a short response that gives little information.

The open ended question is much better.  An open-ended question expects a broader answer, gives the applicant more room to talk.  For example, “Tell me about your experience using ASP.net.”  Use closed ended questions for items like “When can you start?”, “Can you be to work at 6 am?”  Use it for questions where you expect a yes or no answer.

Another question type to use is Past Performance Questions.  Past performance questions are great questions.  These questions are used to inquire about a persons past history. 

Remember to keep the questions open-ended.  For example, “Tell me about a time when you had to work to meet a project deadline”  How well a person has done in the past can give us a view to how well you will do in the future.  Ask these questions early in the interview.  People like to talk about their past.  It makes them feel comfortable.

Another type of question is the Negative balance question.  These questions focus on the negative.  Everyone has had experiences when things did not go right.  Ask these questions to allow you to gauge how the person reacted.  For example, “Tell me about a time when you missed a defect during testing.”  Or, “Tell me about a time when you missed a deadline.”

Be sure to dig further if you find something troubling or you would like more information.  To get confirmation, ask another question.  “Tell me about another time when this happened.”  It may be nothing to be concerned about.

When the interviewee seems reluctant to give information or doesn’t seem to want to talk, you can use a technique called the “half-reflexive” question.  Ask a question that is half-right and listen to the response.  “I think that when pressed for time it is ok to add new functionality without adding new unit tests.”  “What do you think?”  The interviewee has to respond.  It also helps to expose the folks who agree to everything you say.  Don’t overdo this one though or you may come off as disingenuous.

Another tip to get more detail is to say something back that the interviewee said.  This is called a Mirror question.   The purpose is to get them to reveal more details.  For instance: In talking about their experience with Ruby programming, the interviewee mentions that they used “Duck typing”.  You want to know more about their level of experience.  You might say “So, you’ve used duck typing?”  And, then wait for the response.  Listen carefully and build your questions upon their responses.

Be careful with leading questions.  Saying something like, “We work in a fast paced environment”, and then follow it with, “How do you handle stress on the job” may give little information.  You have lead with some information about what you expect and they have complied.  A better question would be something open-ended, without the lead in.  For example: “Tell me about a time where you felt stress on the job?”  Then follow up with “How did you handle it?” 

Reporters like to ask a variety of questions in order to prepare a story.  They ask Who, What, Why, Where, When, How.  This is called layering a question.  This allows you to explore all areas of the topic.  For example:

        Have you had defects get through to the client?  (Opps!  Closed question)

        Tell me about a defect that made it to the client? (Good.  Recovering with the open question)

        How did the situation arise? (how)

        Who was responsible? (who)

        What did you learn? (what)

        Why was this allowed to occur? (why)

        Where did the problem originate? (where)

Don’t accept the first answer to questions but probe further by asking who, what, why, where, when and how.

One simple way to layer is to stretch a question.  When an answer if given, ask: “Can you tell me more about…”  “Can you give me another example?” or “What did you learn from that experience?”

I hope I have given you something you can try in the next interview.  How well the interview goes depends on the information you get from the interviewee.  In your next interview, pay attention to the questions asked.  Consider the information you get back.  Adjust your technique for the next interview.  Then you are well on your way finding your next great hire.

Anyway, I have heard much discussion on the point of the manager’s role in Agile over the years. I share this to further muddy the discussion. 

David Starr (me)

I understand all situations are unique, and I am looking for what general prescriptive guidance you would give someone about using team managers as Scrum Masters. Specifically, I am wondering about personnel managers who will have direct supervisory relationships to many of the team members.

This is what Esther Derby has to say on the subject:
http://www.scrumalliance.org/articles/8-should-a-scrummaster-give-performance-appraisals

Mary Poppendieck

I think that the ScrumMaster role (as canonically defined) usurps the job of a good first line supervisor / team lead.  When supervisors / team leaders understand that their job is to solve problems (remove barriers), preserve knowledge (act as teachers), and grow people (help everyone reach their full potential), the organization probably doesn’t need processes leaders. 

David Starr (me)

I want to follow up on this with all due respect and as a admirer of your work. Have you genuinely seen this come to complete fruition in an organization with over 50 people?

Is it not fair to see the role of personnel supervisor and that of SM as having separate accountability?  To be frank, it is sometimes necessary in the course of human events to tell a team of people what to do.

While one team may embody self organization and emergent behavior, an identically empowered team in the next room may tend toward entropy. The difference hinges on the individuals who compose the teams.

Mary Poppendieck

Hi David,

Here’s what I’ve seen work very successfully in an organization tens of thousands of people engaged in product development:

People are hired by and report to supervisors or managers  who are responsible for their training and career development and supplying them with leadership in an area of a technical specialty. Supervisors are competent to act as technical leaders in the area they supervise, since they have technical expertise in the area themselves.  They understand that their job is to create and preserve knowledge in their field and “grow people” who are competent in the field.  (Think of a major professor at a university, but in a company.)

People are assigned by their supervisor or manager to work on a product teams, which are led by a competent technical leaders who also has a deep understanding of the market and are responsible for the business success of the product.  (We called these people product champions.)  The champion provides team leadership, while supervisors assign people to the team and makes sure they have the guidance, technical support and backup when they need it.  The champion is not a ScrumMaster in the sense of being a process leader, because champions also lead the team in accomplishing most of the work Scrum assigns to the Product Owner:  getting a good sense of what customers really want, deciding how to prioritize the work, etc.  In addition, they provide the technical guidance of a technical architect, or make sure that such leadership is in place.

In some companies the champion is more than one person, but if so, the people in this role are “joined at the hip” in the sense of working together to accomplish the job of a champion. 

In this kind of an environment, a process leader might be needed when a new process is introduced, but over time leadership devolves to supervisors – who grow people –  and champions – who grow businesses. 

David Starr (me)

Mary,

That makes perfect sense and sounds like Nirvana for many of us reading, I imagine J.  Your previous comments left me thinking you advocated a completely flat organization structure with no reporting structures in place. This is a wonderfully succinct description of a well functioning organization and I will be forwarding this conversation to the executive staff in my organization.

Thank you.

See, Kevin! I told you she wasn’t a communist .

Mary Poppendieck

Nah, I’m a firm believer in leadership – generally things go better that way.

Early on, I saw hiring like playing the lotto.  Sometimes you win, sometimes you lose.  But, later, through mentoring and the school of hard knocks, I learned that there are techniques I could use to improve my interviewing skills and thus improve my odds of hiring great people.

I have sat through interviews that are painful to watch.  Folks come with few questions. Some people don’t ask any.  The questions that are asked return some useful information, but not as much as there could be.

To begin, keep the purpose of the interview in mind .  That purpose is to gather information to help you make a decision to hire this person or not.  Much of your ability to get that information is based on the type of questions you ask.

When interviewing, you want three questions answered.

First, is this person able to do the job? 

Does this person have the knowledge of the techniques you use?  Do they have experience with the tools used in your shop?  Do they have an understanding of the processes that you use?  This is the easiest question to answer and most interviewers questions are toward this end.

Second, is this person willing to do the job?  

This is important.  Being able to do the job and being willing to do the job are very different things.  A programmer may be a talented and knowledgeable.  They may know C#, Java and SQL like the back of their hand.  However, you don’t want to find out late that they only want to work on new programs.  They don’t want to work on maintaining existing code.

Third, is this person manageable once on the job? 

This is also important, but many times overlooked.  You are looking for maturity.  You want to root out problems with this person working with you and your team.  You want people that act their age, not their shoe size.

Stay tuned for some follow-up postings.  I’ll discuss types of interviewing questions.

Even thought this model of collaborative workspace is known to be effective, it isn’t everyone’s cup of tea. Some people fundamentally prefer a work environment wherein they cannot hear their neighbor. There are even instances of people leaving an organization because of a perceived “demotion” in losing their office or cubicle. In general, some degree of staff turnover is common when converting to Agile practices. Some figures indicate a predictable turnover of up to 20% when adopting Agile practices. Most turnover is in management positions where the job functions fundamentally change.

Even though Agile practices uncover a lot of dysfunction, the practices shouldn’t introduce new ones. Moving to a collaborative workspace is not a good reason to lose staff or to have perpetually unhappy employees. After all, the intent is to create a more positive, dynamic, and ultimately productive work environment.

How might this transition occur while accommodating folks who don’t thrive in a common room environment? What about times when nuero-typicals (everyone who isn’t me) need some quiet time?

The Concentration Cave

Reserve for the team’s use a separate room, to be available at all times and not scheduled for meetings or other uses. A nice option is to use an existing and fully equipped conference room. Team members should all have laptops anyway and be able to move fluidly in and out of this space. Now when people crave some peace and quiet or some degree of isolation, they can go to the cave.

Cave Rules

The team would do well to consider and then post a set of cave rules. Should music be prohibited? How will people who are bothering others be asked respectfully to leave? Here is a reasonable sample of Cave Rules.

1. No loud talking
2. Respect why people are here, to concentrate
3. Extended conversations should move outside when there are others present in the room
4. No holing up in here for days
5. No phone calls in the cave
6. Turn device sound down or off

Cave Smells

The cave can be easily abused. Here are some things to watch for and deal with proactively.

1. The cave is a phone booth. I have seen success with teams (and parents for that matter) actually providing closeable phone booths in or near the common room. Remove land line phones from the room.
2. Permanent residents. The cave isn’t your home. Your home is with your team.
3. Team members can’t use the cave because someone is in there. Managers need to be good sheepdogs and keep the cave clear for team members.

Other Cave Uses

Yes, the cave is there for the team members 99% of the time. Occasionally other ways to use the cave may be reasonable.

1. Visiting workers, maybe people from another office or 1-day contractors.
2. Design sessions focusing on a few members of the team. Cover the walls in whiteboards like any good surface.

Do you have a cave? How about some cave pics?

Introducing Amplifying Your Effectiveness. I won’t be there, but I have heard most of these people in person and I highly recommend spending your week soaking in this wisdom.