Sometimes, It's the Little Things...

Sometimes, it's the little things that make all the difference in the world for people...like the person that buys a $30k car just because they like where the cup holders are placed. Yes, I laughed at that too, but I've actually seen that happen.

Clients are people too, and I like to look for opportunities to provide a "better than expected value" for them. By that I mean, not just confining ourselves to what the SOW says we're to deliver, but other opportunities to deliver added value...whether it be handling little ancillary issues for them from a project management standpoint, or some helpful little documentation, or just a quick interpersonal check-in.

One way I go about this is I routinely (maybe daily) ask the stakeholder(s) "How can I help you? Is there anything I can do for you?" But you have to really mean it...come at it from a personal approach. The way I look at it, if it's something that lies outside of my realm of job duties, but isn't anything much to do, and helps them...it's worth a lot more in client relations in the long run than the few minutes it may take me to do. Maybe it's scheduling a meeting for them that they were going to schedule, but we're both attending, so I’ll do it. Sometimes, a client may be just overwhelmed with their workload and really flustered, and while there may not be anything I can do for them at the moment to lessen it, they appreciate just being asked. They like to know that someone just cares as a person. (NOTE: If you’re just not that kind of person, don’t attempt this. Being disingenuous with this is worse than not doing it at all)

Another way I've been doing this, as I alluded to, is supporting documentation. I’m talking about little “extras” that help the client, and might be something we would find useful ourselves anyway. By that I mean, we're not burning cycles producing some frivolous document just to provide that "added value" (i.e. make work), but something that they can actually use, but aren’t expecting...think Lean, and the categories of Value-Added, not Value-Added but Necessary, and Waste. Avoid the Waste.

Recently, I worked on a solo project for a client. There was a basic process logic flow that was an early deliverable, but there was one extra request from the client to annotate it. The annotation wasn't in the strict SOW, but I did it and in addition, color-coded the map by processing module to make it even easier to follow. As a result, It proved to be a valuable tool to for the client to easily communicate the logic of the application to both business stakeholders and technical staff. And while a lightweight technical manual was in the deliverable, I added details that weren't defined...such as including that diagram, writing detailed install instructions, etc. Again, these weren't strictly required, but were just something I wanted to include to make things a little easier, a little nicer for my client. And they appreciated it, which is what really made it all worthwhile.

Like I said, sometimes it can be those little details that really make the difference.

Microsoft’s new SDL Perpetuates Some Misconceptions of Agile

Recently, Microsoft published its updated Security Development Lifecycle (SDL), version 4.1a. It includes provisions for incorporating security tasks into Agile development, so naturally I was interested to read it. While on balance I understand what Microsoft is trying to do with this effort, I found a few misconceptions and knocks on Agile that I felt were unfair and disconcerting.
The chief misconception of Agile that I see perpetuated in this document is that Agile releases after every sprint (iteration). While this is possible, it is not necessarily the case and certainly not required by the framework.

On p. 47, in the section on “Melding the Agile and SDL Worlds,” the authors make the statement:

“With Agile release cycles taking as little as one week, there simply isn’t enough time for teams to complete all of the SDL requirements for every release.”

There are two issues with this statement, and similar statements throughout the document. First, the statement assumes a release after each sprint. Agile focuses on producing potentially releasable product in every sprint – and this is an important distinction. As you use Agile in your organization, if you don’t need to release after a one-week sprint, then don’t release. There’s no rule that says you must. Second, the statement seemingly knocks Agile for having sprints (they say “release cycles”) that are ‘too short’ to accomplish all the necessary tasks for SDL requirements. Again, there is no hard and fast rule here for Agile, other than the strong suggestion (call it a rule if you want) that sprints should be time-boxed to 30 calendar days maximum and that sprints stay the same length for consistency. But a team and Product Owner can choose a sprint length that is appropriate for their development model and business needs…if a team is choosing one-week sprints but can’t fit in security tasks deemed necessary, then the sprint timeframe needs to be lengthened.

There were also a few statements with respect to Agile and security in general with which I took exception. In the Introduction on p. 47, the authors make these statements:

“Historically, security has not been given the attention it needs when developing software with Agile methods.”

“There is a perception today that Agile methods do not create secure code, and, on further analysis, the perception is reality. There is very little “secure Agile” expertise available in the market today.”

The problem here is that the authors blame Agile methods for this shortcoming (real or perceived), and not the implementation of those methods, or rather the prioritization of the requirements or user stories undertaken in those Agile methods. If security requirements aren’t being given the attention they need, that’s flat out a failure of prioritization of the requirements by the Product Owner, not a failure of the methodology. You could conduct a sprint consisting entirely of security-related requirements, if those are the top priority, and that would be perfectly valid. Also, the very notion that there is little “secure Agile” expertise in the market is a logical fallacy called a “Complex Question”: unrelated points conjoined as a single proposition. In other words, there’s no such animal as “secure Agile.” There’s Agile. Security is but one consideration among others that can, and should, drive the prioritization of a product backlog.

I then came across this little gem of a paragraph on p. 50 of the document:

“Although SDL-Agile was designed for teams with short release cycles, teams with longer release cycles are still eligible to use the SDL-Agile process. However, they may find that they are actually performing more security work (emphasis added) than if they had used the classic, waterfall-based SDL. Requirements that a team only needs to complete once in classic SDL may need to be met five or six (or more) times in SDL-Agile over the course of a long project. However, this is not necessarily a bad thing and may help the team to create a more secure product.”

This smells to me like the framers of Microsoft SDL-Agile decided that there were certain security requirements that needed to be performed every sprint without consideration of the release schedule of the product. And, in fact, they seem to admit to as much in the preceding paragraph. This is all well and good, I suppose, if you’re OK with doing five or six times the required work for a release as you could otherwise do. But if that’s so, why would one ever choose to do that?

I’d like to offer a couple of options for the SDL-Agile folks to consider. First, remember that Agile doesn’t require you to release after each sprint, only that you produce potentially releasable product.  Second, consider using a “Release Sprint”: a sprint of those activities required before a release that may not be required in each development sprint. This could contain security-based stories as well as other typical release-related activities like, perhaps, user acceptance testing or compliance reviews. But my overarching advice to them, and to you, is to not let misconceptions of Agile hamper your implementation of it. Instead, just understand and respect the basic framework, and look for opportunities to apply the framework, principles, and culture of Agile within your organization. Do those things and I suspect that you’ll be pleased with the results.

As always, I welcome your comments.

Running Agile With Manual Testing Part 2: Feeding the Queue

A few weeks ago, I told you about how to practice Agile with an all-manual test harness. Now I'd like to give you some additional principles to keep in mind that will help you in this challenging scenario (and come in handy as good practices even with test automation).

A key notion to focus on in this situation is keeping a flow going at a steady pace, and getting stories through to QA testing early on in the process.

(Note: I'm adapting some of these principles from research work done on the construction of the Empire State Building by Mary and Tom Poppendieck for their new book, Leading Lean Software Development: Results Are Not the Point):

1.   Get ONE to Done:
Focus the team on one user story at a time and moving it to QA testing as soon as possible. So if you have four developers on your team, instead of having them work on four separate stories and moving all four towards QA testing at a relatively equal pace (which could get you four stories ready for QA testing at the same time and create a logjam), have them team pair up, split up tasks and get two stories, or even better just one, moving to QA. Think of automotive assembly lines, but instead of each developer building their own car, the team works on one car at a time, together, to get it complete before moving on to the next car.

2.   Feed the Queue Logically:
Be sure to consult the QA testers regarding the logic of testing order for the stories in the sprint. In Sprint Planning and in the daily Standup, be sure to ask the question “which of these stories make sense to test together, or in a certain order?” It sounds like an obvious point, but if you don’t ask the question, it could be missed. Then take this into consideration in prioritizing the stories in-sprint.

3.   Prioritize by Size:
We always want to work first on the stories with the highest priority per the Product Backlog. But within a sprint, IF the relative priorities of two stories are close and there's little danger of being stopped mid-sprint, and all else being equal, focus on the largest story first. There's generally (though not always) a direct relationship between the amount of development work for a story and the amount of testing required. There's usually also more unknowns, more issues, that can crop up on a larger story than a smaller one. By putting these stories into your testers' hands sooner, you give them more time to test and uncover these issues, and therefore give your developers more time to address the issues, during the sprint.

Just to illustrate the point, let's say you have five user stories in a sprint, A - E (by priority), as illustrated in the first graph below. I've applied a rule of thumb of 25% of development time required for QA. IF all else is equal, and you have the leeway to do so, prioritizing the stories by size (as illustrated in the second graph) results in a cycle of steadily decreasing testing time required for each story flowed to testers by developers:

(click to enlarge)

Also, by leaving the smaller stories to the end (the ones requiring less testing as well, per the rule of thumb), you accomplish several things. First, you lessen the lag time between when your developers complete their work and the end of the sprint. This keeps the developers from potentially “sitting around” at the end of a sprint. Also, you make it easier for QA testers to turn around testing successfully in the limited time at the end of a sprint because the testing required on those final stories should be less.

Keeping these simple guidelines in mind should help keep your sprint queue humming along like an assembly line, and make it that much easier to practice Agile with manual testing.

As always, I welcome your comments.

Common Sense Guidelines to Creating Speedy Mobile Web Applications

In the current story line on the HBO series "Curb Your Enthusiasm", "Seinfeld" creator Larry David is producing a "Seinfeld" reunion show. In the story line, George Costanza has a brilliant idea for the "iToilet," an iPhone app that directs you to the closest acceptable public toilet anywhere in the world. In preparing to write this blog, I could think of no better example for a mobile application in which speed would be critical.

OK, so it's a fictional humorous example, but the fact of the matter is that mobile web content has grown far beyond simple text messaging. Looking around the train on my daily commute, it's odd to look at the people using laptops for web surfing, instead of mobile devices, and think of them as "old school." But mobile devices have made the leap to the primary information channel for millions of people worldwide. With the level of reliance that there is on all that rich content, it's critically important that your mobile applications focus on speed. And to do that, it helps to think lean.

Here are some basic, common sense guidelines to consider in designing mobile applications for speed:

1. Limit white space: It sounds simple enough, and it can be. Content files that are smaller in size will transmit faster, and removing extra white space in content is a quick way to slim down the content.
   
2. Watch out for the Cookie Monster: Cookies are a standard method for storing identifying data on the client to personalize the user experience on a site. Cookies present a dual problem in mobile web applications, however. For one, every server request contains the cookie information and thus results in extra overhead in the traffic, reducing performance. Also, many mobile devices don't accept cookies, so you can't rely on support for them across mobile devices. One answer for this is the new HTML5 and its support for DOM storage. (NOTE: the acronym here does not stand for "Document Object Model"). DOM storage offers some key advantages over cookies for mobile web applications; chief among them in terms of speed is that DOM data is not transmitted to the web server with every request. This reduces the additional traffic and increases speed. In addition, you can store much more data in DOM storage (5MB-10MB depending on the browser) than in a cookie. And unlike cookies, servers cannot access DOM storage at will; traffic flow and access in both directions is controlled by the client.
3. Minimize the detours: Redirects (sending a user to another server to pull in additional information) can be flat-out brutal in mobile web applications. When rendering a page, having a redirect between the client and the HTML file will cause delays in downloading the page and rendering elements until the HTML document has arrived. Some redirects may be necessary, for example, in account authentication, but other redirects can happen unintentionally and you should be vigilantly watching for these cases. Some examples to avoid:
   
   1. Missing Trailing Slash – Failing to have a trailing slash in a URL will cause an unintentional redirect to the directory, assuming the URL ends with a directory name. For instance, http://mywebsite.com/somedir will cause a redirect to http://mywebsite.com/somedir/.
      
   2. Conditional Redirects – This is redirecting a user based on certain conditions (browser used, etc.) to a different section of a website, or a different site altogether. It's easier to develop in this manner, but again, it adds overhead and time for the user to wait. 
4. Pack before you move: This is a general guideline to minimize network traffic by reducing round trips, and includes practices such as:
   
   1. Batching data requests to send in a single batch
      
   2. Combining static images into a single image by utilizing sprites. This is useful for images that don't often change.
      
   3. Cache Ajax data – caching this data wherever possible will reduce the response time a user might have to otherwise endure waiting for that asynchronous data request to roundtrip over the mobile network.
      

The above are just a couple of examples of common sense approaches to optimizing your mobile web applications for speed. Just keep focusing on the notion that leaner is faster.


As always, I welcome your comments.

How to Run Agile with Manual Testing

Contrary to popular belief, you can run Agile with an all-manual testing harness. I’m doing it now, and I’ll tell you how it works.

In Scrum (my particular flavor of Agile), we promise to deliver releasable product at the end of every Sprint (iteration). The software is considered potentially releasable based on the Team and Product Owner’s definition of “Done.” Definitions of “Done” vary greatly from team to team and project to project. At a high level, however, “Done” typically includes similar basic elements. 


Here is a typical basic definition of “Done”:

1.       Code completed

2.       Peer code review completed

3.       Unit tests completed

4.       System tests completed

5.       Requirements documentation updated

6.       Integration tested

7.       Regression tested

Agile devotees like me will tell you that automated testing at all stages is a true key to high throughput, or velocity, on a team. When a team is developing in a four week Sprint utilizing unit tests written into the code, scriptable QA testing tools that automate regression testing, and a Continuous Integration Server that runs a build (and thus runs the unit tests) on each check-in, the amount of releasable product that can be built in a Sprint can be really impressive. Some people advise that some or most of these elements are required in an Agile adoption. However, when your team has few or even none of these automated test harness components, and procurement details put the acquiring of the necessary software and hardware beyond the foreseeable horizon, why let that stop you from adopting Agile?

The key time crunch in the cycle, as is always the case with testing, comes at the end. You want developers to be fully engaged and working, but if they were to develop through the entire four week Sprint, there would be no time left for QA to do manual Integration and Regression testing, which has to wait until all the code is completed. If you want to give the testers a full week, let’s say, to complete these tests, you might have your developers stop developing three weeks into the Sprint to give QA that fourth week. But having idle developers will rightfully cause issues with management in short order.

In Scrum, you have additional set meetings every Sprint. The Sprint review (final demo of product developed during the Sprint) can run several hours. The same is true for the Sprint Retrospective (a process retrospective around what went well, what didn’t, and what processes we want to change for the next Sprint). Sprint Planning for the next Sprint (choosing items from the Product Backlog for the next Sprint, and breaking them into development tasks) can take up an entire day. Throw in a Product Backlog Grooming meeting (fleshing out requirements further down the Product Backlog, slated for a future Sprint, and put preliminary estimates to them), and you have most of a week taken up in necessary meetings for the development team. Try to run a Sprint every four weeks, with the last day of one Sprint butted right up against the first day of the next Sprint, and you’ll find yourself cutting significantly into development time to have these meetings, or shorting the meetings themselves. Either way, you’re headed for disaster.

One way that I use to overcome these constraints is running a five week QA Sprint overlapping a four week development Sprint plus a planning week. That planning week between development Sprints is the time for QA to complete Integration and Regression testing while the development team participates in the planning meetings and conducts analysis to flesh out the Product Backlog. The developers are available to address issues encountered in QA’s testing if need be, without taking away from their development for the next Sprint. A typical schedule with duties might look like this:

(click the image to enlarge)

Week 1 (Sprint 1): Developers begin coding/unit testing, QA begins developing system test scripts
Week 2 (Sprint 1): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 3 (Sprint 1): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 4 (Sprint 1): Developers release code to system testing/code/unit test, QA system testing/complete Integration/Regression scripts
Week 5: PLANNING WEEK. Sprint Review/Retrospective meetings, Product Backlog Grooming meeting, Sprint 2 Planning; QA Regression/Integration testing
Week 6 (Sprint 2): Developers begin coding/unit testing, QA begins developing system test scripts
Week 7 (Sprint 2): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 8 (Sprint 2): Developers release code to system testing/code/unit test, QA system testing/refining scripts
Week 9 (Sprint 2): Developers release code to system testing/code/unit test, QA system testing/complete Integration/Regression scripts
Week 10: PLANNING WEEK. Sprint Review/Retrospective meetings, Product Backlog Grooming meeting, Sprint 3 Planning; QA Regression/Integration testing

Combine this strategy with a “Release Sprint”, where you’ll conduct those activities more appropriate to a production release, such as User Acceptance Testing, a full end-to-end regression test, and any other reviews or activities more appropriate to a release cycle than a development Sprint. Overlay the release iteration on top of another development Sprint, if appropriate, to keep your team developing new features. Plan a lighter workload for that Sprint so that you have bandwidth available to address issues found in, say, UAT, as a top priority. If release testing goes well and the team finds itself with available bandwidth towards the end of that Sprint, pull in additional items off the Product Backlog to fill the Sprint.

As I say, this is one way to implement Agile in an all-manual testing universe. I’d be interested to hear your experiences with similar challenges. As always, I welcome your comments.

The Agile Voyageur – What a wilderness canoe trip taught me about software development

(This blog was inspired by the forward that Tim Lister wrote for Mike Cohn’s newly published work, Succeeding With Agile – Software Development Using Scrum. Look for my review of the book in a future post)



Those who know me well know two things about me:

1. I LOVE to tell a good story (and I might tell you the same one 5 or 6 times, so watch out);
2. I believe in the analogy, the allegory, and the axiom: basically, that we can find parallels, symbolism, and truths about one area of our lives in an entirely different area.

So with that said, let me tell you a good story that I promise to conclude with an analogy, an allegory, and an axiom!

As a high school sophomore, I went on a school-sponsored canoe expedition (just like the old French voyageurs) in Quetico Provincial Park in Ontario, Canada. This was no ordinary camping trip. It was 6 days, 12 people (3 per canoe), with no powered vehicles (air, land, or water) allowed, no buildings, no power lines, no roads…no sign of civilization. Each person had a 75 lb. backpack with personal items, tent, cooking equipment, and food…everything we needed (but NOT, for sure, everything we wanted, or thought we needed). We had to lay out our personal items before we left and the guide went through and eliminated what he felt we wouldn’t need. And everything we packed in, we had to pack out. No garbage cans.

A great mentor of mine from my high school was supposed to go up and chaperone. He had been a guide up there on several expeditions. He ended up being unable to go, but he gave me this great waterproof guide’s map of Quetico…with all the campsites he’d used in the past marked on it. I was also the most experienced outdoorsmen among the students, so I was set!

On the first day of the trip, our guide Steve decided to keep things light for us, let us get our feet wet (literally!). That first day was a series of small lakes and short (100-200 yards) portages – which, if you’re not familiar, involves beaching the canoe, unloading everything, and carrying all the gear: three packs, paddles, and canoe – over land to the next lake. Our group had never done anything together before…we were just kids from the same school. But we quickly had to learn how to make it work. We had no big guidebook, no real prior experience, and only Steve to answer our questions. That first day seemed rough, but we made it through and looking back, it was REALLY the easiest.

I started off in Steve’s canoe, and by the 2nd or 3rd day, it was clear to him I was more advanced than the others. He took me aside and asked me to command one of the canoes. That sounded great! I’m in! Then the bad news: I would get the canoe with the substitute chaperone. UGH! See, the substitute was the least outdoors-y teacher in the school. He was a canoe leader, and was doing poorly. He didn’t know what he was doing and, to make matters worse, he’d developed a bad attitude about the trip. He was miserable and was making others miserable. I’d be replacing him as canoe leader and he’d be in my canoe! Uncomfortable! I decided to say yes anyways, and off we went. My “favorite” comment he had one day, while canoeing across this beautiful lake, was “I HATE this G** D*** G**-FORSAKEN PLACE!” My answer was a wry “really? I think it’s pretty amazing.” I had to keep things light. Of course, with my trusty guide’s map, I knew exactly where we’d camp every night. But I was wrong…my map was a little old, and Steve had to keep correcting me: this site had a rockslide and was no good, or that site was too bear-infested.

The days went on, the lakes Steve took us across got larger, the portages longer…a half-mile, then the granddaddy one mile portage. I’m proud to say I carried TWO packs over that portage – one strapped in back and one in front – and I only stopped to rest once (a feat that I promise I can’t recreate today). But the teams got tighter, and as we became more experienced, we were able to go farther, produce more.

There were dangers along the way to be sure. One team member got a leach on his leg. One narrow passage between lakes, with faster water, that most people were portaging around, we paddled through. On Elizabeth Lake, there were reports of bears in the area. We had to paddle our food packs out to a tiny island in the middle of the lake and leave them there overnight so the bears wouldn’t be drawn into our site.

We pulled into base camp on day six, 10 grungy-but-seasoned kids, one great guide, and one still-cranky chaperone. That night, we had a little bonfire to relax and review with Steve. “Do you realize what you boys accomplished?” Steve said. “You just traveled 110 miles in six days, with nothing but yourselves and each other to rely on. You overcame challenges, you adapted to adversity, and you’re changed forever for the better because of it.” And he was right, on all counts.

So, do you see the analogy, the allegory, and the axiom? Let me spell it out:
Analogy: Agile software development is a wilderness canoe trip. We start out small to learn, and increment up to bigger and bigger challenges. We adapt to changing circumstances and use the varied talents of our cross-functional team to reach the goal.
Allegory: The expedition is the project, the canoe is a Scrum Team, the whole group is a Scrum of Scrums, the bears and leaches are impediments. Steve was a Product Owner. The chaperone was a discordant team member. The old map is a stale project plan. Sorting through our things before beginning is removing waste and technical debt from our process. The bonfire was a retrospective.
Axiom: Agile, folks, is what we already do in everyday life, certainly on a wilderness canoe trip. So if Agile principles made a potentially life and death trip something fantastic to enjoy and remember forever, what do you think chances are that they can improve our work developing software?

Note: Every word of the story is true. And I bet that chaperone is still cranky about the outdoors today.

As always, I welcome your comments.

The Psychology of the Sign Off

“Make sure you get the Sign Off.”

That’s a common mantra among managers in any business. The sign off is sometimes pursued and valued like it’s some kind of ancient idol. (The opening scene from Raiders of the Lost Ark comes to mind.) It’s taken for granted that it’s a necessary part of the processes we use to produce product. But what does the sign off really mean? When you get that signature on the document (or give yours), what is the sign off saying and what are the expectations of both parties going forward?

Webster’s online dictionary defines “sign off” as follows:
“to approve or acknowledge something by or as if by a signature <sign off on a memo>”

Hey, that sounds pretty innocuous. I showed you something, or did something for you, and you’re just signing a piece of paper that says you saw it, or I did it. But of course, the benign nature of that thought belies the social complexities and implications of what that signature really means.

On one level, it’s an issue of trust. Why do you need my signature? Isn’t it enough that I told you verbally that its fine? If we worked in a world of implicit trust, that might be OK. But if you’re the one looking for that signature from a manager or client, and heard that question, what are the chances you would respond “yes, sure, it’s fine?” I say the chances are slim and none. If you could take it on verbal approval, then chances are:

1. The decision or deliverable in question is very minor,
2. Your organization is extremely small (and likely with a very flat organizational hierarchy), and/or
3. You really DO work in an organization with a model of implicit trust (this is rare if (2) is not true).

So if we don’t trust each other enough to take everything on verbal approval, the question is why? What are we afraid is going to happen if something goes wrong?

In THAT question lies the core issue. It’s not what happens when everything goes well…when the product is delivered on time, on budget, free of defects. At that point, everyone is happy, and someone throws a party. Maybe the only person unhappy with the lack of formal sign offs in that situation is the person whose job it is to make sure all the boxes were checked for process’ sake.

But when things DO go wrong – major defects make it into production (“QA is the problem”), business owners or customers report that product features aren’t what they wanted (“Requirements are the problem”) or delivery is very late or well over budget (“OK, who did it?”) – THAT is when the true nature of the formal sign off shows. That’s when fingers get pointed and people dive for cover…behind the sign off.

I submit that at its core, the formal sign off serves mainly as an abdication of responsibility for a deliverable, or transference of that responsibility to the signatory.

This is why people are so apprehensive to sign off. Because at worst, by signing, the signatory puts him/her self on the hook for the deliverable on which they’ve just signed off. They’ve accepted responsibility for something they’ve likely had no hand in producing, but for which they have to answer. And when things go wrong, they'll be left holding the bag. This is an issue of the culture of the process.

Imagine a large river being fed by several small streams. At the point where each stream feeds into the main river, there’s a lock. Water flows from each stream into the main river, but once it’s contributed a certain amount, the lock closes. When a storm hits at the mouth of the river, and water is pushed back upstream, the locks are closed and the streams are protected, but the main river (and its surrounding banks) is devastated. This is a metaphor for the classic sign off when things go wrong, and the real tragedy is that in this model, nobody is responsible for the successful delivery of the product (except maybe the last signatory). Everyone else has plausible deniability. If I’m contributing to the product, and something goes wrong because of my work, but you signed off on it, I can make a great case that I’m not responsible because you accepted both my product and the responsibility when you signed off.

Now, contrast this with the model we use in Agile, specifically Scrum. We take a cross functional team, combine that with a business Product Owner and a Scrum Master, and emphasize that together they are the team, together they are collectively responsible for the successful delivery (or failure) of the product. We move away from the silo mentality that fosters people protecting their camp (or stream) at the expense of the product. We move to putting the product first, by ensuring that the product owner is prioritizing the product backlog to ensure we’re working on the items with the highest business value first, in every iteration. And we emphasize continuous, open communication on the team.

Don’t misunderstand me. I’m not saying that Agile or Scrum is some magic bullet to avoid the contentious atmosphere that the traditional sign off can foster. Is it possible to poison an Agile development effort by sticking to the old psychology of the sign off? Absolutely. What I am saying is that it provides a framework more conducive to making the culture change that is necessary to change that atmosphere. It’s not in our nature and it’s not easy…it takes a willingness by the parties involved to give up the protection of the sign off, and sign up for shared success or failure. Implement this culture shift in your team or organization, however, and trust and a shared sense of ownership of the product will cement the team together, stronger than the sum of its parts.

As always, I welcome your comments.