Come to XPSD on October 1st where I will share my ideas and experiences gained while in Shanghai.  I am not sure if I will turn my presentation into a post, but I will give away my key point now: you will have much more impact improving the performance of your Scrum teams by providing soft skill training to the ScrumMasters rather than training on hard skills, i.e. estimation, Planning Poker, Scrum mechanics, etc.

Obie Fernandez writes a blog post about how pair programming is not for the masses.  I find it interesting that his post addresses many of the items that were not discussed at the Agile 2009 session on how to debug pair programming.

Three ideas identified by Obie are common stumbling obstacles I have observed when trying to consistently use pair programming with product teams:

1. Most software people don’t understand pair productivity: unfortunately this is so true and it applies to both management and programmers.  From the management perspective, I cannot understand why pair programming is not embraced more fully.  You get higher quality code and the programmers are focused on doing work (as opposed to reading the Internet or working on side projects).  For the programmers, pair programming just makes the work more fun and less frustrating.  Granted, pair programming is not for everyone, but when coaching teams on this practice, I insist teams try it out for 3-4 weeks and learn what the boundaries are.
2. Most software managers don’t want to invest in the necessary hardware: if you do not understand the value of the practice, you are not going to invest in tools that make it easier.  And yes, pair programming is an investment in the future quality of the system.  If you invest in something, you are serious about it.  Or put another way, put your money where you mouth is.  Spending a few thousand dollars on good machines gets people’s attention.
3. Most software shops are not configured for pair programming: if you are not going to invest in tools and do not understand the value of the practice, why would you fight the office furniture police?  Why be a squeaky wheel in the corporate world if you don’t believe pair programming is valuable?  Management investments in the environment are cues workers use to know if management are serious about changing the development practices.  Nothing says change more than tearing down cubicle walls.  Being able to do that shows you have management support and goodwill.

So, what is the solution?  I am not really certain I know the answer since solutions are context sensitive.  I believe some of the prerequisites are maturity within the developers, desire for code excellence by all parties and an open mind.IF we have these prerequisites in place, then we can begin to have a conversation.

I came across a question on a usergroup asking the following (it’s condensed):

“In our projects we maintain product backlog and do high level estimates in story points. Then when we actually start the iteration we do estimates in the sprint planning meeting in story points and then when the story gets completed we mark the actuals against it. Our understanding of story point is one ideal day (i.e.6 hours). Our estimate for the story include analysis, design, coding and testing. Now the CMMI group is recommending us that we should divide our story into analysis, design, development and testing substasks and track estimated and actual efforts against them. Their argument is that by doing this, there can be some data available which will tell us on how are we doing on each of this area and where we need to improve. For example if the analysis tasks are taking longer then estimated then we should identify reasons and actions to handle it. My argument was that we can not go below the story level because in agile way of working analysis, design, development and testing is kind of merged into a story  and since the story is a smaller piece its not possible to break it further in such a way. I told them that this will be too burocratic and there will be lot of administrative overhead. The CMMI group told me that in their previous implementations they have done it only this way even in organizations where they are using agile methodology (Scrum, XP etc.) and this was the only way they could find to handle this situation.”

There are so many things wrong here, I will just highlight a few.  Having worked at a CMMI ranked company, from perspective of a contributor most of these rankings are pure bunk.  The CMMI ranking had absolutely no impact on the quality of the system delivered or the timeliness of our delivery.  In both aspects, the CMMI process produced a lower quality, more costly system than an Agile approach.  As applied at this company, CMMI only served to reinforce all the bad habits and waste of waterfall (I really hate the term waterfall since it is SO pejorative.  Just exactly who admits to doing waterfall? – CEN).

When I hear the phrase “this was the only way they could find”, it just sets off warning bells in my head.  My only advice is to trust your instincts in resisting the mindset from the CMMI auditors. From the short description, it seems to me they are trying to create mini-waterfalls within an Agile process. As for the improvement the CMMI auditors are looking for, they are simply suboptimizing by focusing on tasks – that is such Taylorism.  I am reading an excellent book by Craig Larman and Bas Vodde talking about using Lean thinking to scale Scrum to larger product organizations.  This book provides the intellectual firepower to destroy the last vestiges of the waterfall in modern software development.

From my experience of CMMI and talking with some auditors, in many instances you only need to show evidence that a practice is occurring in order to pass an audit. There are many legitimate and creative ways to provide evidence your are following the practices described in CMMI. If your instincts are telling you the auditors are wrong, trust them.  Learn what the auditors are looking for and work with them to provide the same information.  Don’t let their intellectual laziness strangle real change and innovation in your organization.

As a practical matter, you need to placate these CMMI folks because they obviously have the attention of management. I would try to understand what management is looking for with a CMMI rating – beyond the obvious we need a ranking to get more and bigger contracts. What advantages would it give the business? How would you know that the organizational change caused by CMMI is producing the effect your company seeks? Then I would show your management how Scrum is helping in some areas and where it is deficient. In the deficient areas, maybe CMMI can help. Perhaps the CMMI people are right and the processes are unstable. Think about what you could be doing to make the entire system more predictable (hint – think Lean, not CMMI).

I was having a really interesting conversation with Susan Elliot Sim at Agile Open SoCal.  I was asking her why is it so difficult to get peer-reviewed articles published on Agile.  She responded by telling me this story, with the instruction to identify the emotions you feel when hearing\reading the story:

“Suppose I told you I was going to tell you that in order to understand what is wrong with your dog – he’s been limping and you think something is wrong with his leg – we are going to take him to a dog psychic in Nevada and this dog psychic is extremely good, highly recommended and gets great results and you take your dog there.

You ask the dog psychic, ‘Can you ask the dog if his leg hurts?’.

The dog psychic talks to your dog and turns to you to say – channeling your dog, ‘Well…thank you for asking about my leg, but that is not what’s bothering me.  It’s my back.  It hurts a lot when I jump up and down off the bed, especially on cold mornings, so could you please get me a ramp to make that easier?’

‘Also, I really like it when you come home to play with me during the day and I remember that time we went to the park and chased the birds in the pond, so let’s do more of that.’

‘Oh, and I really don’t like that dog food we have been eating all these years.  Yes, I know that I eat it all up and I probably shouldn’t have, but I didn’t want to hurt your feelings cause you do so many nice things for me.  However, since we are finally having a conversation after all these years, I thought you should know.’

And you respond to your dog, ‘Oh my God!  I never knew you felt this way about so many things.  When we get home, I am going to make all these changes.  I am so glad I spoke with this dog psychic!’”

So how did you feel after hearing this story?  It is a bit farfetched isn’t it?

According to Susan, this is experience is very similar to what academic researchers think about Agile – it is nothing more than dog psychics.  That you really have to believe in dog psychics in order to get any value out of them.  In addition, the people who believe dog psychics sound a bit evangelical in talking about how great dog psychics are and yet there is no (scientific) evidence on the mechanics of dog psychics.  I thought this anecdote is a really good concept to keep in mind when we encounter skeptical people; sometimes we just sound loony.

Thanks to Lisa Crispin for pointing out this article on pair programming in the Jobs section of the New York Times.  In the article, they do a profile of a company in Florida that uses pair programming.  It’s a very first person description of the practice, the benefits and some conflicts uncovered by pair programming.

Unfortunately, since it is the New York Times, they make you login to the site in order to read the content, so use these credentials I created:

    username: lookforward9

    password: lookforward9

Looking through some old notes from China, I noticed there were a number questions about the roles in Scrum, the importance of each role and how each role balances the other.  As a review, here are the three “offical” roles in Scrum and an additional role I consider important for the success of your product as well – stakeholders.

1. ScrumMaster: their role is to ensure the integrity of the process, that the preconditions for the framework are met, all the roles are filled and the players are following the Laws\Rules (I like to use the terms Laws since in rugby the rules of the game are called Laws – CEN).  They also encourage the Team to self-organize, remove obstacles, teach others about the Scrum and be on the lookout for people trying to minimize the feedback the framework is providing.
2. Product Owner: the person who defines and orders the list of features (called the Product Backlog) the Team is going to build for the organization.  They are given the authority to make tradeoffs about scope and date within the boundaries of the governance model of their organization.  Often times, Product Owners collaborate with the ScrumMaster to get the most value from the process.  Product Owners can delegate some of their work, but never their responsibility.
3. Team: the cross-functional group of individuals given the responsibility and authority to turn the Product Backlog into working software.  The Team is urged and guided by their ScrumMaster to strive for continuous improvement and technical excellence.  They work with the Product Owner to determine the best sequence of features for the business.  When an obstacle is identified, the Team always tries to resolve it themselves before calling in their ScrumMaster or other parties.
4. Stakeholders: anyone who has an interest in the product.  They are outside the Team and as a result, can only influence the Team’s activities at clear checkpoints.

Scrum, just like every other Agile process, is a carefully balanced framework.  Each practice, guideline, artifact and role are the minimum collection of elements needed to be successful with the framework.  When you fail to fill a role, give one role more weight or weaken a role, all sorts of dysfunctional behavior manifests itself.  In some respects, this is a strength of Scrum because it makes all sort of dysfunctions visible very quickly.  That is why the ScrumMaster role is VERY important.  Their job is to make sure people acknowledge the dysfunctions and try to devise ways to eliminate or minimize the obstacles.  In my experience, this is a full time job.

One dysfunction Scrum was created to eliminate was the detrimental impact of meddling Stakeholders.  Too many Teams have trashed about trying to implement this great idea or another from competing Stakeholders, that they end up chasing their tail and getting nothing done.  This problem is overcome through a combination of an empowered Product Owner and the Law that you cannot change a Sprint once it has started.   In practice, the diagram shows the new relationship the Stakeholders have with their Scrum teams.  Generally, they do not have a direct line of communication with the Team.  Most communications come to the Team via the Product Owner and the ScrumMaster.  Again, we must balance the need to protect the Team from distractions and the needs of the business to direct the Team.  Scrum provides this balance through the Sprint Review at the end of every Sprint where the Stakeholders are invited to review the product, give feedback, provide oversight and help the Product Owner reprioritize the Product Backlog.  With the Sprint Review, we can provide the proper balance between protecting the Team from distractions and letting the business respond to changing conditions rapidly and effectively.

Just wanted to reiterate the value of TDD – I am working on a programming challenge and was surprised how easy it was to add a hunting and killing algorithm to my program.  Since it was written using TDD, I had a nice suite of fast tests which allowed me to incrementally encapsulate my new algorithms and keep the system functional at nearly every step.

At the most, I only had two, maybe three, broken tests while adding the new classes, pulling up fields and moving methods.  Not bad, not bad at all.

I was having a conversation with a manager the other day about the difficulties she was having filling a position.  Everything seemed like an obstacle that could not be overcome – the distances were too far, candidates were good on paper only, not enough time to review their work, etc., etc.  It seemed that no matter the issue, it was going to be impossible for her to succeed.  When you have an attitude like that and where everything is an obstacle, it would be impossible to succeed.

The Spirit of Scrum borrows heavily from what I call the Spirit of Rugby: teams, composed of players of different physiques and skills, are united by a drive to win through a strong sense of camaraderie, the boundaries of fair play and good sportsmanship.  Teams that are proficient in the basic skills, respect the Laws are embody the Spirit of Rugby are rewarded with victories.  It is no surprise that the number #1 and #2 teams in rugby, South Africa and New Zealand, embody these principles and year after year are ranked as the top teams in the world.  What I have found is the same Spirit of Rugby in the smallest amateur division is the same Spirit of Rugby seen in the international teams.  More so than the Laws, it is the Spirit that connects the amateur teams with the professional teams.

In Scrum, you need the same spirit in order to succeed.  Everyone on the team has something to contribute and when you compete, you do not hold back.  You leave everything on the pitch.  Half measures do not equal success in rugby nor in business.  Sure, some people may get more glory than others, but their time in the spotlight is due to the hard efforts of the rest of the team.  When the team is united, there are no obstacle can stand in their way.  Just like in rugby, teams that embody the Spirit of Scrum are linked no matter what the size nor the domain.  They are all playing with the same game. 

I was looking back at some old notes of mine from China and I came across a number of questions from the people I worked with about the Definition of Done.  The Definition of Done (DoD) is a very important concept in Scrum and not spending time to construct a DoD is a common mistake with new Scrum teams.

In my opinion, the DoD provides visibility and alignment on just exactly what it takes to get a user story completed in an organization.  It could almost be seen as a unstructured value-stream map.  We write down the DoD to illuminate any hidden queues in the organization and to make visible the real effort it takes to complete a user story.  It is also there to protect the Team since it cannot be changed during a Sprint.  Nothing irritates me more as a Team member, or a ScrumMaster, to move the goalposts of a Sprint after it has begun, i.e. adding a new auditing requirement to the DoD.

The DoD is NOT the same as the acceptance criteria for a user story.  The DoD is an engineering checklist for the cross-functional Team.  The acceptance criteria is the checklist Product Owner and stakeholders use to know if a user story is complete.  They assume all the items in the DoD are complete and if they are not (that is called Design Debt), the Team cannot demo the feature at Sprint Review.  You can think of the DoD as the pre-requisites that need to be finished before a story may be shown at Sprint Review.

Finally, I have found it better for individual Teams to come up with their own DoD rather than be handed one from management.  When first working with a Team, it is normally better to document what the Team is doing and label that it’s DoD and add to it over time rather than forcing some onerous DoD created by some disconnected process people who don’t even do the work onto an uncertain Team.  Of course, there are some basic standards (code reviews, some form of pair programming, unit testing, etc., etc.) that must be in all DoD, but I find most Teams will include them on their own.

So what to do when your company has 12 versions of the DoD floating around?  Well, that is why you have ScrumMasters.  It is their job to get the various Team DoD in alignment, not the process goons.  The process goons have good stuff to add to the DoD and Scrum is about collaboration, not forcing other people to do your will.  If the process groups want Teams to do extra work, their requests on the Team are made visible just like everyone other.