I talk quite a bit about the concept of intrinsic motivation in my presentations and workshops. Intrinsic motivation describes our satisfaction in doing something simply for the sake of doing it.  Think of playing an instrument, solving a puzzle or painting a picture.  The activity is a reward in itself.  Daniel Pink’s “Drive” is great book that discusses this concept.  If you haven’t read it yet, checkout the video below.

(Hat tip Aaron Bjork)

Over the last few years I have found myself drawing the same Scrum diagram on the whiteboard over and over again.  A simple, no-frills, diagram that shows the basic ideas of Scrum.  This is that diagram.

In some research I’m doing for a new course, I ran into Nancy Leveson’s list of myths regarding software safety.  She presented this list in her 1995 book Safeware: System Safety and Computers.  The list of myths are as follows:

1. The cost of computers is lower than that of analog or electromechanical devices.
2. Software is easy to change.
3. Computers provide greater reliability than the devices they replace.
4. Increasing software reliability will increase safety.
5. Testing software and formal verification of software can remove all the errors.
6. Reusing software increases safety.
7. Computer reduce risk over mechanical systems.

We will do well to remember this list as we design complex software based systems.

I just finished reading Sam Guckenheimer and Neno Loje’s new book “Agile Software Engineering with Visual Studio.”  Great job guys!

Some observations:

• They appear to provide a fairly clear picture of Scrum.
• I love the fact they cover mura, muri and muda.
• I don’t like their explanation of technical debt.
• Great discussions on “Analysis Paralysis.”
• They pull in Lean and Kanban very nicely.
• Tacit knowledge is mentioned.
• Inclusion of Product Backlog grooming which many Scrum books overlook.
• Good discussion on Kano Analysis. (nice picture of Stephanie Cuthbertson and team!)
• Good discussion on Empirical vs. Defined Process Control.
• They present some great information on metrics and agile.
• Finally! A good description and discussion on Emergent Architecture!
• They talk about using branching sparingly then dive into a head-on discussion of a mature branching schema. I would have liked to have seen a discussion of lighter-weight methods.
• Sam and Neno advocate for integration as often as possible.  Awesome!
• The handling of testing is a bit dicey and appears to target the use of TFS/Visual Studio over good Agile practices.
• Good discussion on exploratory testing!
• Don’t care for their “Handling Bugs” section.

Quotes I really like:

• “you do not measure planned tasks completed as the primary indicator of progress; you count units of value delivered. “ (pg. 8)
• “Lean turns governance on its head, by trusting teams to work toward a shared goal, and using measurement transparency to allow teams to improve the flow of value and reduce waste themselves.“ (pg. 14)
• “Note that this does not mean that all tasks are known on the first day of the sprint. On the contrary, tasks may be added to the sprint backlog whenever necessary.“ (pg. 29)
• “mastery of Scrum is really for the whole team, not just a designated individual.” (pg. 76)
• “Unfortunately, using metrics to evaluate individual performance is often horribly counterproductive” (pg. 81)
• “use branches sparingly and intentionally. If you need to do something temporary, use a shelveset instead. ” (pg. 162)
• “A potential dysfunction is that integration fails. Integration issues, such as merging, are a common source of unhappiness and waste in teams.” (pg. 197)
• (Regarding test automation) “Automation is useful when it achieves high coverage and when the tests will be used many times for many configurations across many changes in the software under test (SUT).” (pg. 219)
• “work should be sequenced to facilitate getting PBIs through acceptance testing to done as quickly as possible.” (pg. 235)

This is a very good primer for using TFS and Visual Studio Ultimate within a Scrum environment!  This book coupled with Scrum.org’s Professional Scrum Developer course and you should be up and running in no time!

See Brian Harry’s blog: http://blogs.msdn.com/b/bharry/archive/2011/08/08/aug-11-tfs-power-tools-coming-soon.aspx

and Ed Blankenship’s blog: http://www.edsquared.com/2011/08/19/August+2011+New+TFS+2010+Power+Tools+Released.aspx

I just received by new Wrox book “Professional Team Foundation Server 2010” by Ed Blankenship, Martin Woodward, Grant Holliday and Brian Keller.  After paging through the book I think it is a great primer for people getting started with TFS 2010.  They cover everything from deployment planning to lab management.  Great job guys!

Over the last few years I have worked with teams that feel a need to using Branching as part of their “best practices” tool set. The ALM Rangers were even nice enough to show teams how to build a mature branching scenario in their Visual Studio Team Foundation Server Branching Guide 2010.  PROCEED WITH CAUTION!  There is a large overhead in using branching and merging.  The branching part is easy, it’s the merging part that will kill you.  Done infrequently, the merge process can be a huge undertaking in many cases taking days to complete.  Here is a quote from the original VS 2005 Branching and Merging Primer:

A branching and merging strategy involves a tradeoff between risk and productivity. You trade the safety of working in isolation for the increased productivity of working with other people. The productivity increases come with a cost—the additional effort required for merging software assets sometime in the future.

Often, there is no need to adopt branching as the teams are small enough or using shelves will suffice.  If you feel you need to branch, do so for the right reasons.  What are the “right reasons?”  In a nutshell, you absolutely NEED to isolate some code from other teams/repositories.  Examples might include:

• Development on a new feature is continuing while the current version is releasing.  (branch by feature)
• Teams are practicing design by contract and only want the final contract to be used by other teams. (branch by team)

What are some branching and merging anti-patterns to watch for? Here are few (thanks Chris Birmele):

• Merge Paranoia—avoiding merging at all cost, usually because of a fear of the consequences.
• Merge Mania—spending too much time merging software assets instead of developing them.
• Big Bang Merge—deferring branch merging to the end of the development effort and attempting to merge all branches simultaneously.
• Never-Ending Merge—continuous merging activity because there is always more to merge.
• Wrong-Way Merge—merging a software asset version with an earlier version.
• Branch Mania—creating many branches for no apparent reason.
• Cascading Branches—branching but never merging back to the main line.
• Mysterious Branches—branching for no apparent reason.
• Temporary Branches—branching for changing reasons, so the branch becomes a permanent temporary workspace.
• Volatile Branches—branching with unstable software assets shared by other branches or merged into another branch.

  Note   Branches are volatile most of the time while they exist as independent branches. That is the point of having them. The difference is that you should not share or merge branches while they are in an unstable state.

• Development Freeze—stopping all development activities while branching, merging, and building new base lines.
• Berlin Wall—using branches to divide the development team members, instead of dividing the work they are performing.

Remember, think long and hard about jumping into branching and merging.

Some additional reading:

Fowler on Feature Branching

Fowler on Continuous Integration

Microsoft Research has a great tool for automatic unit test generation (Pex) and delegate method replacement (Moles).  These tools can be a great way to get unit testing up and running on your brownfield project.

http://research.microsoft.com/en-us/projects/pex/

In a recent discussion with a team, the topic of “unshippable bugs” was brought up.  The team explained to me that there are cases when there are bugs found during a Sprint that cause the software to become unshippable.  Their fix was to extend the Sprint and fix the bugs. For many of us this probably does not seem all that crazy of an idea.  In general, there is a big problem with this idea if you are using Scrum to build software.  Let me explain.  In Scrum we are always shooting to complete PBIs in the order of importance.  We don’t want to “divide and conquer” all of the PBIs in a Sprint but rather work on one at a time, in order of importance.  (as much as possible)  There are numerous reasons for this including the fact that we want to always deliver some “done” value at the end of the Sprint.  If we split up the work we run the risk of not delivering any of them and thus creating no value.  Additionally, if we want to deliver positive, quality value, we need to always including many forms of testing in our definition of done. (unit, integration, functional, performance, regression, etc.)

If we comply with our “definition of done” during the Sprint in a way that makes the PBI shippable, how are teams getting to the end of the Sprint with “unshippable bugs?”  One reason might be that the bug was discovered during testing after the PBI was considered done.  Should the team be writing code in such a way that testing can’t keep up?  Should the testing specialist be the only one testing?  No. Quality and testing should be owned by the entire team such that the software is thoroughly tested as it is written.  This way bugs found after the PBI is considered done are usually minor and easy to fix.

The next issue here revolves around the concept of delivery.  Should the team just extend the Sprint?  No. If the team is shipping every Sprint, this is usually indicative of a fast pace and the Sprints should already be short. (1-2 weeks)  If a bug is found and the Product Owner wants it fixed prior to shipping, the team should simply make it #1 in the order and deliver it as part of the next Sprint.  If the Sprints are longer (2-4 weeks) the team is using working in a Release Cycle and has a number of choices, ship what was delivered a Sprint prior or wait for another Sprint.  Finally, when you extend a Sprint (timebox), the Product Owner and the organization looses the ability to contain risk, measure velocity and establish cadence.

I think we are all well aware that bugs cost more money to fix the longer they live.  What are the reasons for this?  As some of you have heard me discuss in various presentations, a lot of it has to do with context.  As developers move on to new areas of code, they loose context for previous areas that may contain bugs.  Specifically, they loose the fine details on how that area of the code works, thus preventing a quick fix of the bug.  I’ve done some analysis of some of the teams I’ve worked with and have found the time to fix a bug varies with time as shown in Figure 1.

Figure 1

This curve shows us that bugs caught early can be fixed fairly quickly.  However, after a certain point, there is a spike in the amount of time it takes to understand to the code and fix the bug.  I have seen this spike occur somewhere between one and three months, depending on the developer.  Obviously this in and of itself is reason to fix bugs early.  But there is another monster waiting for us in the closet…bugs love to procreate.  (just like in nature)  The longer a bug lives in code, the more chances developers have to write code to accommodate the bug, thus creating another bug or two or three.  Left unchecked, this growth becomes exponential.  (Figure 2) I’m guessing this is no surprise to many of you.

Figure 2

We can look at both Figure 1 and Figure 2 as “cost curves.”  By this I mean that at points low on the curve we incur low cost and at points high on the curve we incur high costs.

In Agile, we seek to change the way teams test software.    We want to eliminate the “let me finish it all, then you can test” mentality with “let’s write a little and test a little.”  This behavior encourages teams to find bugs quickly, before they get into the wild.  Lisa Crispin and Janet Gregory thing of this as “Coding and Testing Progressing Together” in their book Agile Testing.  What is the point of cranking out a bunch of code if it’s riddled with bugs?

There are a ton of advantages to using Agile iterations.  One of which is improved quality.  By driving towards zero bugs every iteration, we can keep all of our costs on the bottom of the “costs curves.”  This is one way that Agile helps limit the risk of ballooning costs late in a project.