Notes from a Tool User

Visual Studio vs. CCNET as Service

Ok I’m going completely mad with CCNET and Visual Studio 2005. We’ve got CCNET running from the command line – but wanted to migrate to running it as a service so that it would always be run after a machine restart. The service has the login credentials of the user that runs the command line version today. So in theory they’re the same people.

The ccnet config file:

<cruisecontrol>
 <project name="EndManager" webURL="http://localhost/EndManager">
  <intervalTrigger name="continuous" seconds="30"/>
  <sourcecontrol type="vss">
   <project>$/EndorsementManager_Net</project>
   <workingDirectory>C:\GLOBEXDOTNETVSS\ENDORSEMENTMANAGER_NET</workingDirectory>
   <timeout units="seconds">600</timeout>
   <ssdir>\\vss2\share2\GlobexDotNet</ssdir>
  </sourcecontrol>
  <tasks>
   <devenv solutionfile="C:\GLOBEXDOTNETVSS\ENDORSEMENTMANAGER_NET\Source\EndorsementMgr.sln" configuration="debug" />
   <nunit path="C:\Program Files\NUnit 2.4.8\bin\nunit-console.exe">
    <assemblies>
     <assembly>C:\GLOBEXDOTNETVSS\ENDORSEMENTMANAGER_NET\Source\EndmBaLayer\EndmBaComponentUnitTest\bin\Debug\EndmBaComponentUnitTest.dll</assembly>
    </assemblies>
   </nunit>  
  </tasks>
 </project>
</cruisecontrol>

This contains the much maligned devenv task which we use because its easier than writing an msbuild script for all of the assemblies. The devenv task trys to do the following on the command line:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com "C:\GLOBEXDOTNETVSS\ENDORSEMENTMANAGER_NET\Source\EndorsementMgr.sln" /rebuild "debug"

Net result – I get the following wonderfully descriptive error: “the application data folder for visual studio could not be created” What’s up? Is this an environment variable problem? Shouldn’t having the login credentials of the user mean that we get their environment variables?

Any ideas?

If you enjoyed this post, subscribe now to get free updates.

Planning a Change in Career? Laid Off?

Recently a few good friends have been laid off and I’ve been left thinking what to do after that happens. First up I don’t have any jobs in my back pocket. I don’t know anyone hiring right this second. My thoughts are more general than that.

Snippets

Moving Stuck Projects Forward: The Clinic Method ...The Clinic Method.  What’s this?  It’s a nurses’ station for projects that are sick.  If a project manager or product owner or scrum master or anyone feels that a project is in trouble, it’s a place to go for help.  Get five or six of your best people and have them meet for half a day, once a week. ... What does this team do when someone brings a problem?  They don’t solve the problem.  They help that person come up with a positive step to move forward...

The Magic Chemistry of Teams - examines some of the characteristics required to build and renew great teams.

Multi Tasking Myth - we're often trained to believe that multi-tasking is good either in the small: doing email and answering the phone. Or in the the large working on two or more projects. This item from Jeff Atwood demonstrates the falsehood of both. This picture illustrates the problem:

Handling Large Stories in Agile - a short item on approaches to splitting large stories/features so that they can be completed in a single iteration.

Track Velocity, Not Time Spent on Tasks - reminds us that we ship features/stories to customers not task. While tasks are useful in helping the team plan, estimate and organizing itself - it really doesn't matter how much time is spent on any one task. Instead what matters is whether the stories are getting completed.

Time to Go

Friday will be my last day at IBM and on Monday I will become an Agile Coach/Trainer for hire, via my open little company: Pure Agile Consulting (sorry no website yet).

I've had a nearly eight year run with a great bunch of people. First at Databeacon and our .NET Rich Client (tip of the hat to Robi, Dave, Marc, Tony, Patrick, Suzzane, Ralph and briefly Hans) - little did you know how far I would take those crazy ideas around unit testing, milestones and reflection. Then Cognos for the death of Corinth and rebirth of PMRC (add to the list Sasa , Viktor, Daniel and Johnathan), PMMT (Brenda, Brian and Steve - aka Chad). Finally IBM and Agile Coaching with people too numerous to name.

Sometime ago I realized that I was no longer passionate about coding and that my interests lie in coaching and mentoring Agile Software Development, TDD etc. Along the way many of you have given me the chance to do coaching/mentoring work and for that I'm grateful. I'm also grateful to everyone who put with my all to frequent harangues about why Agile/TDD etc was better than what we do today. One of the things I have learned since is to ask questions, listen and then harangue :-) Thanks to everyone who helped me evolve

Special thanks to:

• Robi for teaching me a lot about quality and for helping me to get better at writing good code
• A big thanks to Sasa who took a chance on Scrum and put up with a someone who was telling him how to organize his team.
• Ralph for giving me a chance to coach and for keeping me through three rounds of layoffs.
• Guillaume (and the whole BUDDI team) for letting me use BUDDI as an occasional test bed for my coaching and facilitation skills.

An interesting side story on the number of people at each company: Databeacon was ~60 people when I joined and ~30 when we were acquired. Cognos was about 3,500 and IBM is about 400,000. So each time I've been acquired I've joined a company that was 1,000 times larger than its predecessor.

It's been great working with everyone and I look forward to crossing paths again.

My permanent email address is mark@mlevison.com. I would delighted to connect with anyone on Facebook or LinkedIn (yes I've dissed LinkedIn before).

TDD Adoption Strategies Article

Eons ago I promised a blog posting on TDD Adoptions strategy. Well the posting grew and grew and grew (can you tell I read alot of kid's books?) and along the way morphed into something bigger. In end I decided this article would want a wider audience and so I published it on InfoQ. Here's the blurb:

Making TDD Stick: Problems and Solutions for Adopters

Teams in large organizations still struggle to adopt TDD. In this article Mark Levison shares problems he uncovered when he surveyed teams, and his own strategy to introduce TDD into an organization.

Enjoy the reading.

If you enjoyed this post, subscribe now to get free updates.

Do You Suspect You Have a Less than Productive Person on Your Team?

In the past couple of days on the Scrum Development mailing list an interesting thread has developed around what to do with a poor performing team member.

Too my mind there have been a number of key take away points

• Be very careful about the language you use: Strong language implies prejudice and assumptions.
• Reset use a Beginners Mind
• Does the team perceive this to be a problem?
• Possible causes of this perception
• Measuring Individuals doesn't work (nor does measuring teams, but that's a different topic).
• If it is a real problem how to handle it.

Your Perception

Strong language like "Rotten Apple", "Ruins the team", "drag on productivity" etc. imply that you're already convinced that the person is the problem. Unfortunately this can just be prejudice. Linda Rising, author of Fearless Change Patterns, notes that people will categorize or stereotype others in a very short period of time.

"In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice."

In a case like this consider using Beginners Mind (courtesy of Jean Tabaka and David Hussman) - let go of the outcome, take a step back, ask why not how, bring silence listen and observe. The key find a way of letting go of previous conceptions and re-examine the situation from scratch. How is this person working?

Team's Perception

Remember the Star Wars quote (thanks to Paul Hudson):

Obi-Wan Kenobi: So what I told you was true, from a certain point of view.

Luke Skywalker: [incredulously] A certain point of view?

Obi-Wan Kenobi: Luke, you will find that many of the truths we cling to depend greatly on our own point of view

Does the team see the problem? Do they work with this person or avoid them? Are they making jokes about the situation? Behind the persons back? Is the person included in lunch, coffee breaks and water cooler conversation? Has the team raised the issue in a retrospective? If the team doesn't perceive a problem, then maybe they see the situation differently than you.

Possible Causes

Assuming there is a productivity issue, examine what they're doing and see what the possible causes are:

1. Personal problems at home (new kid, divorce, family member is sick, ...)
2. Maybe they underestimate tasks.
3. Maybe they're very careful and leave no loose ends behind.
4. Perhaps they act as glue for the team, holding the team together by communicating ideas, solving little problems. All the stuff that goes unnoticed but really matters.
5. Maybe they're just slow by nature
6. Maybe this person knows much less about the problem domain, technology etc than anyone else.
7. Maybe they're bored and this will come out in your one-on-one's (see below).
8. Maybe they really are a slacker.

Measuring Productivity

We also hit the problem of measuring the individual's performance using the number of story points they completed during the iteration. This was a troublesome topic for any number of reasons:

• Measures of people are entirely subjective
• No meaningful way to measure productivity or even skills
• Measures like this are too easily gamed
• It doesn't take into account anytime the person may have spent pairing, studying, removing impediments etc.

George Dinwiddie recently wrote about measuring individual performance, not by using numbers but by listening and watching: "Working Hard, or Hardly Working?"

Possible Solutions to the problem (if really exists):

• Pair with the person yourself. It will give you a much better idea of how they work.
• Have a one on one with this person (if you're not already doing it then make it team wide habit first so that you're not seen as singling the person out). Ask them how they perceive their own productivity. Maybe they do things that you don't see.
• Put together a plan to solve the issues that you both agree on.
• If none of this works ask the person what they want - maybe the person feels out of place on the team.
• Consider letting someone go only after all avenues have been exhausted. When it happens I  consider myself to have failed.

So before we rush off to action:

• Stop, let go of preconceptions
• Re-examine the person's role on the team
• Listen/Watch - don't measure
• Only if there is a problem - then solve it.

For a great deal more on this and related topics you might like a book by Johanna Rothmann and Esther Derby: Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers).

Caveat Emptor - if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

If you enjoyed this post, subscribe now to get free updates.

Updated: to fix some typos and improve the structure/flow.

Top Ten of 2008

Just for some fun I thought I would toss together a couple of top ten lists for 2008 (hey it works for Letterman, why not me?). There are three lists here: Top Ten Posts (my picks), Top ten items I wrote for InfoQ and Top Ten by Traffic.

My Picks

in chronological order

• Tools, Tools, Tools As software developers we have this innate belief that another tool will solve all our  problems. To that end many agile practitioners search for a tool to track their projects for them.
• Minimally Agile What is the minimum it takes to be Agile?
• Agile/Scrum Smells an initial catalog of common things that go wrong on Agile projects. It needs your help to make it better.
• Minimalist Coding Style when I sit down with you to pair, I'm likely to make some comments about your code - now you know what is going on my brain.
• Coaching Self Organizing Teams - one of the best sessions I attended at Agile 2008
• TDD Coding Dojo (Randori Format) our first attempt at a coding Dojo.
• Advantages of TDD
• TDD Coding Dojo (Randori Format) Round II - where we apply the lessons applied the first time.
• Scrum Case Studies - given the frequent requests I hear for Scrum Case Studies I gathered a bunch up.
• Misconceptions with Test Driven Development - sensing a theme? I hear a lot of objections saying TDD can't work in XXX case or it won't scale.

InfoQ

In a random order

• Can Product Owner and Scrum Master be Combined?
• Scrum Certification Test
• Kanban as Alternative Agile Implementation
• Rewards to Improve Team Habits?
• Performance Reviews Banished
• Questioning Servant Leadership
• Co-location Transition, Tips and Concerns
• What are the Qualities of a Good Test?
• Well Formed Teams: Helping Teams Thrive, not just Survive
• Touchy Feely Impediments to Agile Adoption

Google Analytics Picks

These prove that the world cares more about photography and vista woes than Agile Software Development. Obviously a list like this will favour older posts.

1. Aperture vs. Lightroom - best comparisons
2. Agile/Scrum Smells
3. Nikon D3 vs D300
4. Driver woes on Vista? Sonic Solutions DLA problem solved
5. Scrum in a Nutshell or 5 minutes to learn scrum BTW the presentation here is a little dated, it needs a good rewrite based on what I'm learning about changing brains.
6. Customer Retention Department - Vonage Customer Service Sucks
7. Scrum Case Studies
8. Lightroom Tip: How to Successfully Import your Photoshop Elements Catalog
9. Minimalist Coding Style
10. Writing Clean Testable Code
11. Multiple Returns from a Single Method

Because 11 is better than 10.

Finally just for pure ego's sake some stats for the year:

• 70,000+ page views this year
• 42,000+ visitors with half the visitors from three countries: US, UK and Canada
• 1250+ readers (according to feedburner and that doesn't the readers who found me through Agile Planet), up from ~450 on Jan 1.

Thanks for reading in 2008.

If you enjoyed this post, subscribe now to get free updates.

Agile for Hardware and Embedded Systems

I've never done either Hardware or Embedded Systems, but a number of my friends have and I've always been fascinated by what it would take to extend the reach of Agile to their world. To me it seems the obvious problem is the long cycle times and the cost of getting new hardware fabbed.

There have been several interesting articles and conversations recently that have sparked some digging on my part.

The Players

The people/organizations that I know who seem to be making contributions in this space:

• Nancy Van Schooenderwoert - Agile Rules
• James Grenning - Renaissance Software Consulting
• Johanna Rothmann
• Atomic Objects

Articles

• Embedded Agile: A Case Study In Numbers by Nancy Van Schooenderwoert
• Taming the Embedded Tiger: Agile Test Techniques for Embedded Software (pdf) by Nancy Van Schooenderwoert
• Embedded Extreme Programming Experience Report (pdf) by Nancy Van Schooenderwoert
• PRODUCT DEVELOPMENT AND AGILE METHODS by Jim Highsmith
• What Lifecycle? Selecting the Right Model for Your Project by Johanna Rothman
• Agile Embedded Software Development (Oct 2008) (pdf) by James Grenning
• Test Driven Development for Embedded Software by James Grenning
• Agile Times - Containing Progress Before Hardware - "This issue has many intersting articles to embedded teams and Agile Development topics in general."
• Atomic Objects Best Practices in Embedded Software
• Danube Case Study with Intel

Quotes and Conversations

James Grenning:

My focus has mainly been on the software side of the hardware. One of my early aha moments had to do with freeing the software from target availability, as well as the difficulties in test and debug on hardware. Something I call DOH! Hardware is scarce, not yet developed, expensive, slow to download, etc. Getting the software working independently of the hardware is important to making visible progress without the usual impediments.

For example, client target systems are quite expensive ($1M+), so developers don't each get one. In that environment you would like to have your code in good working order before running it in the hardware. Of course you won't find all problems, but instead of finding and fixing all problems in the challenging target environment, the code is well exercised and tested off-target first. Then the kinds of problems found when in the target are integration problems. The target is a good place to look for integration problems and a bad place to look for application problems. I do have one client that has applied some of the agile ideas to hardware development. They have changed their hardware development process so they could do an over-night circuit board build if they needed it.

Johanna Rothmann:

The key is to have each supplier have a rhythm to their builds/drops to the system integrator. (You have just one supplier? An you're a supplier to an integrator?) As long as everyone is attempting to build feature-by-feature, and that the hardware people simulate before they go to fab, you can make it.

Robin Dymond:

King Circuit www.kingcircuit.com offers 24 hour turn around on PCBs. Most of the physical constraints we worried about 15 years ago when I was building various embedded DSP solutions are gone. The fast turn cycles of PC motherboards has driven the industry to turn designs into populated hardware quickly.

Great hardware designs are modular. With a bit of thinking H/W engineers can build testable demoable components of the system that can be quickly (days) fabricated. BUT(T) they have to think differently about how they work. That is your challenge, to get them to try it.

There are other solutions too. They have Field Programmable Gate Arrays (FPGAs) that can instantiate a chip design with a download. We loved these things because of the risk they removed and the fact that you could play/test with the design. At the time the # of gates you could get was often smaller than we needed. Now they have huge FPGAs and you can test big designs with them long before taping out to an ASIC. In fact the ASIC guys can just hard code the gate array. Its not as efficient on the gate count but you get a tested design.

James again:

One thing you should strive for is getting as much confidence in your software as possible before the hardware arrives.  You can reduce potential problems at integration.  The kinds of problems at integration are: 1)software does not work, 2)hardware does not work, 3)software and hardware do not talk properly, 4) application does not work.  

With TDD and ATDD, along with keeping as much of your code testable independent of the hardware, you should be able to minimize the first and the last problem with this approach.  problem 2 can be lessened through programmable devices, prototyping and fast turn hardware builds like Robyn suggests.  You may also want to build a automated test or partially automated test that looks out to the hardware.  Finding and addressing problem 3 is natural at HW/SW integration time, it goes more smoothly if you are not finding problems you could have found earlier in the software and hardware development cycles.

Jeanne Petrangelo:

I'm an embedded software/firmware engineer and my previous employer made ASICS. Before I left there, I explored ways we could adopt some of the agile practices. I'm sure you do chip simulations; those should be done all along instead of waiting for the end, and you probably already know that. Now, testing the software plus the ASIC together as total end-to-end system testing when the chip hasn't even gone to fab is a different matter, of course. As Robin pointed out, some of the logic could possibly be put on FPGAs or a group of FPGAs. Another approach could be to use a chip simulator which makes a cycle accurate linkable C object, like one we saw from a startup called Carbon Design, but it's not cheap. And if the system controls mechanicals then you can't really automate a total end-to-end system test anyway. If not, you're in luck; most of Carbon Design's customers seemed to fall into that category, like network fabrics/processors. A more practical approach may be to just handle the ASIC development and software development separately. Have the software employ a good hardware abstraction layer where the chip can be modeled. And be sure to define "unit" when you talk about unit testing, as the term already has a meaning to an ASIC team. Testing a chip "unit" is not the same as "unit testing" in the software sense.

John Baker:

I have been investigating how to use Agile for embedded systems that concurrently develop electo-mechanicals, controllers, and software. So far the best advice I have gotten is to use a product like Simulink from Mathworks as a tool to allow the HW engineers to follow a model driven development approach. SW can be concurrently developed and tested against the simulator.

When the HW design is stable it is sent off from prototypic fab. Then keep the HW simulation current and allow testing of the SW against both the real HW and newer versions of simulated HW.

Sorry there isn't really any of my own content here - this stuff is more than a bit outside my experience so I have nothing useful to add. Do you have any experience trying to make Agile work for Embedded Software/Hardware? Please share.

Discovery De-Mystified

In "The Myth of Discovery" Ted Neward complains that the software industry is unwilling to look beyond its bounds for new ideas and innovation. What surprises me is how little evidence he offers. In column against the software industry he cites only: Jeff Palermo's essay on "The Myth of Self-Organizing Teams" (an item I mostly agree with).

Oddly Ted offers evidence from the Agile community suggesting we do borrow ideas - citing Mary and Tom Poppendieck and their refinement of Lean ideas for software development. In this case his problem is that development managers/project leads aren't yet given the opportunity to say a product won't ship because the quality isn't there. Well I understand where he's coming from, but it seems like a mis-understanding of Lean/Agile principals which focus on building the quality in - not refusing to ship because the quality isn't there.

In any case I think that more people than Ted acknowledges, do their research outside of the software industry. Some examples:

Recent Readings

I apologize for the break, I was off sick at the start of the week and am running on all fronts to catch-up. In addition I have an article on TDD Adoption Strategies that I'm churning away at that has taken a good chunk of time. I promise a more weighty piece early next week. In the meantime here are some of the many items that have caught my attention in the past few weeks:

Neuronal Networks – James Zull: "The single most important factor influencing learning is what the learner already knows. Ascertain this and teach him accordingly." While this may seem strange for an Agile Coach - I think all coaching (and training) is about changing brains. In the Agile world we need to bring some scientific rigour to our efforts. How do we approach new situations? What techniques should we use?. James' book: "The Art of Changing the Brain" and John Medina's "Brain Rules" are having a profound effect on my thinking around my work. I will be proposing an Agile 2009 session for this one.

Agile Testing Overview Redux - Elisabeth shares a great set of slides that introduce the principles and practices of Agile Testing. She also draws the distinction between Agile and Traditional testing.