Death by Process: A Vicious Feedback Cycle

I have been working with a client that employs hundreds of employees and contractors in their IT department. Their workforce is a diverse mix of full time employees, contractors, and some off-shore development work. They are currently caught in a rather vicious cycle of processes and procedures.

Because they have introduced a large amount of off-shore workers and lower-cost contractors, they have spent the past several years introducing new processes to help keep things moving. Then someone came up with the idea of introducing CMMI. It's not a bad idea in concept. "If we are going to have processes, then let's make sure that they are mature and that we improve them."

In the next few posts I will examine how the introduction of controls that started with a simple desire to increase CMMI compliance has led to escalating levels of process and complexity that I will refer to as "Death by Process."

Why I Gave Up PC Games

Years ago I used to swear that PC's were vastly superior to the toy-like console games. A while back I got an Xbox free at a Microsoft event and started getting my fill of geek-time through that outlet. When it came time to upgrade my PC to keep up with the then current genre of games, I was faced with the prospect of dropping $300-$400 for a single graphics card. I passed on that and have never played much on the PC since.

So I'm travelling a bunch now. Rather than buy a PSP or DS to get my fix in, I picked up a PC game that was a couple years old. (It is a work laptop after all, not exactly pushing the envelope in the graphics department, but otherwise sound). I got back to the hotel and started the install. I got up, called my wife for 15 minutes, ironed a shirt for 5, packed my bag for I don't know how long and the game was done installing.

Then I played for about 15 minutes before finally hitting a save spot. At which point I received a helpful message "Save failed! There was an error while saving the game. Could not find the save game directory." REALLY! That's great. I never got the message on my Xbox 360 at home. What did I do wrong? I called technical support... 20 minutes on hold. Their solution? Uninstall, boot into Safe Mode, Re-install and then try to save again which "should" fix the problem. Uh-huh.

Games are suppossed to be fun. So far I've lost an entire evening. Oh well, being annoyed certainly made the time fly by.

Role of Tester, Subject Matter Experts, and Business Owners

From: Julie
Sent: July 16, 2008
To: John Santiago
Subject: UAT ?

Hi John,Hope all is well.We are having a little controversy here on how business acceptance testing should be run. If you could please advise me of which option you have seen most prevalent in your experience with agile methodologies that would be great.

As an end user, SME and tester which business acceptance testing process would you prefer?

1. As you test and find issues you report them and development resolves them quickly for you to re-test and close
2. As you test and find issues you report them and development releases the fixes to test approximately 2 weeks later at which time you would retest and close.

Thanks much for the opinion.
Best Regards,
Julie


Julie,
I think you guys follow Scrum with two week Sprints, so I will focus on that methodology.

SME’s and Business Owners (Product Owners) should be meeting with developers throughout each two week sprint to help clarify requirements and provide guidance. If that’s not happening, then the developers are not asking enough questions to clarify requirements. If they are, this should avoid major misses at Sprint Reviews.

Then, the SME’s and Product Owners should meet at the Sprint Review for 2-4 hours to review the product in detail. At that point, defects and enhancements are added to the Product Backlog and prioritized in or out of the next Sprint during the Sprint Planning Session. SME’s and Business Owners should be participating in the Sprint Planning Session, btw.

So defects and enhancements found in Sprint Review would be two weeks out into the next release according to Scrum, which probably wasn’t what you wanted to hear.

However, you mentioned Testers which is a development team role. Testers should be part of the development team and actively testing code during the actual Sprint and should have a chance to review and approve code before it is deemed complete for the Sprint. This is my opinion, as the specific role of Tester is not well defined in Scrum. I do know that the Scrum teams running at eBags follow this approach and I have done it very successfully as well.

If you have someone who is a SME and a business owner and a tester, you probably have one person with too many roles who will have difficulty interacting well with a Scrum team.

Thanks and good luck!
John

Analysts (not clients) as Your Scrum Product Owner

In a conversation yesterday I was talking with a colleague of mine about the difficulty of doing Scrum in a consulting environment, such as when we are hired to build custom software for our clients. Often times we are on a fixed or firmly entrenched budget (whether our contract is Time and Materials or not) and our clients don't have the time to sit in and fill the role of Product Owner. Nor will that client really want to participate in many of the day-to-day sessions.

In this setting (well, most settings actually) I highly recommend having a talented business analyst on the project. This person's primary job is to gather, refine and prioritize requirements. Their role in RUP and other processes remains largely unchanged. In fact, many of the great tools and techniques learned in RUP and UML translate very well.

On a Scrum project, these analysts should work at least a Sprint ahead of the development team. They meet with clients and get documents approved and signed off on. Then when the development team starts a new Sprint, the analyst fills in the role of Product Owner. They provide hands on reviews of software in progress and help interpret requirements. Sprints start off very effectively because that analyst has documented a use case or user story and may even have some wifreframes sketched out.

It is the analyst's role to get questions answered quickly from the client in order to keep the development team productive.

Their are obvious downsides, of course. The analyst is NOT ultimately the actual Product Owner. There is a difference between what the actual Product Owner will want and what the analyst will specify. I contend that for most software projects the difference is acceptable and their really are no better options without the Product Owner making a larger commitment of their time.

Issue and Risk Management in Scrum

Today I met with an organization who has three simultaneous development teams and is closely following the Scrum rules for managing risks and issues. I tend to think this approach is deficient, however. Perhaps it's the traditional Project Manager in me, but I have really come to rely on a well managed risk and issue log as part of my tool box. In fact, I would frequently spend more time in my issue and risk log than in my backlogs (in Scrum) or project files (in RUP or my company's methodology). I recently received this e-mail from "MN:"

From: MN
Sent: Tuesday, March 04, 2008
To: Santiago, John
Subject: Risk management

I was wondering how risk management gets done in scrum. Is this an explicit activity or is it sort of inherent in the prioritization process?

I have this voice in the back of my head saying: "Mike, you should be doing risk management..."
_ _ _ _
My response:
In theory, “Frequent risk and mitigation plans are developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) is incorporated at every stage and with “genuinity”.

I always took a more proactive approach and kept a classic risk and an issue log complete with mitigation plans and results, so that I could help remind the team of past decisions and make sure items don’t get lost. Sometimes issues or risks would manifest themselves as actual backlog items. The reason I ask in our standups about work is being held up or roadblocks the team has is to identify Issues and sometimes Risks. During Planning meetings I watch for any backlog items that are uncertain, and those quickly become risks. It also helps to ask the team during Planning, “What problems do you think we could encounter?” They can usually answer that question, but can’t always answer a more formal question such as “What issues or risks do you see?”

How to Facilitate a Scrum Retrospective

From: MN
Sent: Monday, March 03, 2008 10:33 AM
To: Santiago, John
Subject: Scrum iteration retrospective

Our first iteration ended up going reasonably well. We moved about 20% of the original work back into the backlog, but the client readily agreed that these were low priority things. We'll have our first retrospective tomorrow morning at 9am, followed by our second iteration planning meeting.

I was wondering if you had any advise on how to conduct the retrospective....

_ _ _ _ _ _ _ _


For the Retrospective, use whatever facilitation technique you are most familiar with, but as ScrumMaster you should keep the following points in mind:

• You want to encourage participation, don’t let anyone sit out quietly.
• Avoid undue influence on your part. As facilitator, your job is to gather other’s opinion. Save your own until you are sure everyone else has gotten theirs out.
• Encourage dialogue, but don’t let more vocal and opinionated folks drown out others, especially folks who are hesitant to talk.

Here’s a facilitation technique that might help:

• Give everyone two index cards.
• Ask them to write down five things that went well on one card and five things that went poorly on another. You can participate in this.
• Collect all of the cards
• On a shared visual space (whiteboard or flip-chart) start writing down responses for what went well.
• First read the item and ask if this is a new item, a duplicate, or if it amends another item. Let the group guide you, but you might make some suggestions to move it along.
• Repeat this process for What Didn’t Work Well, creating a new list.
• At the end, give everyone three Dots. Use stickers or sticky-notes as dots. They get to use these as votes for what to talk about further, perhaps items to adapt what we are doing as a team. People can put all their dots on one item, or spread them around as they see fit, but they have to vote with all three.
• From there, take your top items and discuss how to adapt your process in the next Sprint.

John

National Car Rental Praise and Complaints

Over the weekend I travelled to meet with family in Georgia. I have an Emerald Aisle membership with National Car Rental and had an interesting experience. When on business, I never pay attention to anything, I just expense the cost and am too busy to sweat the details. When it's my money, though, I get very annoyed about cost and truth in what these companies quote.

Praise:

• I love their company and the Emerald Aisle experience, where I get to pick from their crop of rental cars whatever I need for that trip without any difference in price. Since it was three hours to my destination I picked the Pontiac Vibe, hoping it would be good on gas (it was).

Gripes:

• When I made this reservation, I was quoted $84. Taxes, fees and indecipherable nonsense on Travelocity left me surprised at the end of the trip when my bill was $100. How long before someone files a class-action lawsuit? When booking the trip, National's website quoted me a higher price than Travelocity. Was the difference because National was telling the truth and Travelocity was obscuring the actual cost, or is there really a price difference here? Frustrating and confusing for a consumer.
• The car was 3/4 full on gas. No credit was applied for me bring it back slightly below Full. The guy who checked me out gave me a really skeptical look as I explained that I hand't noticed it was low when I left the lot.

How I get treated when I travel for personal reasons greatly affects who I book with when on business. National Car Rental and other agencies need to clean up their pricing policies.

Non-Developers on a Scrum Team

I received another e-mail this week on a different topic in Scrum. How do you incorporate some of the traditional non-developer roles into a Scrum team? For example, your Business Analysts?

From: MN
Sent: Tuesday, February 26, 2008 7:26 AM
To: Santiago, John
Subject: Question about SCRUM

How do you handle non-development activities assigned to business analysts in SCRUM?

During our product backlog planning, we identified two non-development activities that we assigned to business analysts. The business analysts have told me that they would prefer to have these tasks managed outside the iteration backlog because they're not development activities.

What do you think?

MN

My response:

The team correctly identified one of the challenges you can run into with Scrum when you introduce non-development staff. Your BA’s are not directly contributing to the current Sprint (they are thinking ahead for future Sprints) and so they don’t really belong on this Sprint’s backlog. Intuitively we know that they are a part of the team, so what to do? Here are a couple of ideas / workarounds:

1) Remove your BA’s from this Product Backlog and all future Sprints altogether. Create a separate backlog just for them and have them organize into Sprints. They are Developers, but they are Developing requirements documents instead of software. This might be a good team for 1 week Sprints since they don’t have builds and such, plus BA’s sometimes need a little extra drive so they don’t get caught in the weeds. The downside here is that they become somewhat disconnected from the rest of the team.

2) Another option is to keep the BA’s work items on your Product Backlog and your current Sprint, but don’t count their hours in any of the Burndowns since they aren’t directly contributing development time to “potentially shippable product.” This keeps them in your status meetings, and you can still check their progress with the rest of the team.

Since Scrum is all about “self-directing teams,” you might take 15 minutes for a team discussion where you lay out the challenges, posit these two solutions, solicit other ideas and have a team vote as to the best idea to try. Your team might have some really good thoughts.

Question About Scrum Velocity

A peer of mine is working on a major software development effort. He is a Software Architect in the role of "ScrumMaster" and is just learning the ropes of Scrum. He works for a very major consulting organization. He sent me this e-mail (excerpt):

From: MN
Sent: Monday, February 25, 2008 8:21 AM
To: Santiago, John
Subject: Question about SCRUM velocity

We've been measuring velocity for three days and, as you suggested, the numbers are relatively low. They are heading in the right direction. Now that we're moving, do you think velocity will improve naturally or do you think I should be doing things to encourage increased performance? If so, what sorts of things might help? The team isn't reporting much in the way of barriers; its more like we underestimated things.

MN

After reviewing his backlog, I had some suggestions about individual challenges some folks might be having, and I also suggested that he check out this great post about Sprint Retrospectives so that he can examine in more detail the Sprint with his team:

http://pragmaticintegration.blogspot.com/2007/01/first-scrum-sprint-retrospective.html

He responded back with the following:

I'm not stuck but vastly underestimated the amount of work. I thought my estimate was pessimistic when I originally made it. Sometimes when you turn over a rock, you find something you wish you hadn't found. As far as I can tell, it absolutely needed to be dealt with and I can't think of a good way to cut the work short.

I think that acknowledgment is critical to understanding how Scrum operates so I sent him the following e-mail:

From: Santiago, John [mailto:John.Santiago@emc.com]
Sent: Wednesday, February 27, 2008 10:52 AM
To: MN
Subject: RE: Question about SCRUM velocity

“There are known knowns. These are things we know that we know.

There are known unknowns. That is to say, there are things we know we don't know. But, there are also unknown unknowns. These are things we don't know we don't know.”

-- Donald Rumsfeld, befuddling the press at a Pentagon briefing

A huge part of software development is learning to recognize what you don’t know. What you will find is that your velocity will tend to account for this over the course of the project… allowing you to fairly accurately predict the impact of the unknown. Assuming that there aren’t monumental roadblocks in your way of course, which is why project managers still need to actively do aggressive risk identification and management even in a Scrum environment to steer around potential roadblocks.

What you must be doing right now to maximize your team’s velocity is to be very aggressive about removing any gold-plating from the project and to make sure the team is focused only on the minimum functionality needed to go-live.