Death by Process: How Not to Consolidate Four Processes into One

As my client began her new position as head of her company's enterprise project management office, she started off with the bold step to consolidate the processes and deliverables currently in place. She freely shares her lessons learned here.

The projects spanned across all aspects of IT. Infrastructure, ERP, custom development, mobile applications and business intelligence were the largest and most influential projects. There were hundreds of simultaneous projects in play. She researched all of the phase gates and deliverables currently being used by the different methodologies and thought this was the perfect place to start streamlining everything into one methodology. She collected templates and sample deliverables and then corralled all of the most senior representatives from these projects (the "Senior Leaders") into an all day session.

Her intent was noble and utilized one of my favorite facilitation techniques... a shared visual space (in this case a wall) and sticky notes that represented all of the deliverables. The idea was to show that many deliverables were redundant and could be done away with. Keep in mind, most of these delivery methodologies had between ten and forty deliverables that were commonly used, a subset of which were strongly encouraged for each project.

My client acknowledges she lost control of the meeting at this point. These senior leaders refused to remove any deliverables from the board and actually started to add more deliverables to the mix to "ensure quality delivery."

The net result was nearly 90 deliverables and 9 phase gates that became a part of their methodology.

Personally, I struggled greatly with the Rational Unified Process at my last employer when it was en vouge there back in 2002-2004. I felt the deliverables were too many, too redundant and too complex to readily understand, which ultimately reduces the efficacy of any software management solution. If my team of highly qualified engineers can't quickly understand and benefit from the process, what value is it to me? We live in an environment of high job turnover and can't afford to train engineers for weeks on end before they join a team and can contribute.

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