Rally recently held a “success tour” event in Boston. I have been using Rally for about 18 months, but recently began using it on a team that is new to Agile, so I was interested in seeing if I could pick up anything that would help ease the transition. The event started with a roundtable of executives who have successfully used Rally, and a quote that hit home for me was from Jochen Krebs who said “every team needs to find its own unique path within the Scrum framework”. Joechen’s presentation at the Boston event can be found here (you have to hit the “older” button a few times to get to his presentation).

An interesting follow-up to Jochen’s presentation was given by Heather Kanser who pointed out the danger of teams “cherry-picking” the parts of Agile that they wanted. Their talks were complimentary as Jochen’s comment about teams finding their own path was “within the Scrum framework”.

I came from a team that has had good success using Rally and Agile in a particular way, and one of the challenges for me has been to tailor the approach for a new team. We’ve been introducing some new processes and adoption has been a challenge for both sides. We introduced some new processes about how we do releases and validation, and recently pushed out a new release of the software. It seemed like a good time for a retrospective. Of course, if I read my own posts, I would have remembered that the right time for the first retrospective may have been right when I first joined the team.

The comments for “what did we do well” were very encouraging. Collaboration, better testing, delivering what we promised, fixing architectural issues were all mentioned. I was particularly pleased that delivery of promised features and improved testing were included. These were areas that I pushed hard for and it was gratifying for the team to see the value. It is always nice too when you hear team members say “that can wait for the next release”. I think one of the hardest parts of initially adopting Agile is having faith that regular releases will provide an opportunity for more incremental improvements down the road. Delivering what you promised is more important than trying to add more features near the end of the development cycle.

There was some good discussion about what we could do better. This was one of those times where as I heard at the Rally event, the team needed to find its own flavor. I tried to stay back a bit from the technical aspects and work more to facilitate the discussion. It was very interesting to see how what we thought were the most important items to address evolved over the meeting. We have some actions and a follow-up meeting scheduled. Should be interesting.

Something that often comes up when discussing the topic of pair programming is the notion of convincing management of its value. Am I paying twice as much to have two developers to work on a task instead of just one?

My experience with convincing management of the value of agile and XP methods has been if you deliver software on time and with few defects management will accept whatever practices get them those results.

The problem I often face and find much more challenging is how to convince other software developers of the value of pair programming. Getting comfortable with pair programming can be a challenge. The evolutionary nature of software development in an iterative, TDD environment means we don’t have all the answers up front. That can be an uncomfortable feeling. Nobody wants to look like they don’t have a clear vision of where the design is going or be uncertain about the best way to implement it. My advice is to get over it. The other person you are pairing with is in the same boat. When you switch seats and they are at the keyboard, they are going to be leaning on you to see the big picture and help guide the design.

Some people advocate code reviews and feel they can serve the same purpose as pairing. That is true in a sense, but one of the problems I have with code reviews is grasping the subtleties of the design and what trade-offs went into a particular design decision. With pairing you are intimately involved in the design, coding, and testing. You talked out the trade-offs as you went along. The tight feedback loop in pairing also reduces the likelihood of having to make a major refactoring that may come out of a code review. I am not opposed to code reviews, I just think pairing provides a better mechanism for good design and coding practices.

A lot of successful pair programming has to do with the two engineers developing a good working relationship and respecting one another. Talk through alternatives, try different implementations, write good tests, listen to one another, and learn from one another. My pair programming experiences have been some of the most gratifying development experiences in my career.

Microsoft hosted a developer conference in Boston today.  I think for the most part, you get when you pay for, and the $99 price of this event told me it would probably be more marketing than technology.  But it’s always good to get out and hear what’s going on and talk with other developers.

There were several topics of interest to me at the conference, ranging from F#, Silverlight, Visual Studio Team System 2010, and ASP.NET 4.0 , but one of the things I was most interested in learning about is Azure, Microsoft’s foray into cloud computing.  I have not been paying a lot of attention to this topic and I thought that this conference would give me a good 50,000 foot view into the technology and Microsoft’s plans for it.

In the keynote, Amanda Silver referenced the Battle of the Currents, where in the early days of electrical distribution Thomas Edison’s system of direct current (DC) was pitted against Nikola Tesla and George Westinghouse’s system of alternating current (AC).  One of the disadvantages of direct current was that the power generation had to be close by due to power loss associated with transmission.  This meant that a manufacturing plant might need to have its own electrical plant, with all the associated capital costs and maintenance. This is much the same as technology companies today incurring the capital cost and IT support of maintaining their own data centers.  The ability to buy electric power from a utility company would allow the consumer to focus on their business and treat the incoming power as a service.

Microsoft’s intention in this market seems to be to offer a similar utility model that would have the benefits of scalability, redundancy, and IT support and allow a company that subscribes to the Microsoft data center services to focus on it’s own business domain.  As any of us who have had internal data centers know, power outages, scaling, and IT support (security patches, etc.) can be a real headache for a developer and data center IT support keeps us from doing our real jobs: design and writing code. 

Now before you think I drank too much Microsoft Kool-Aid, I am just saying that is the idea behind cloud computing in general.  Why absorb the capital outlay and support costs of setting up and maintaining a data center when you can lease those capabilities?  Theoretically, this could lead to better support, scalability, and fault tolerance.  Microsoft seems to be positioning itself for proving data center services and support in the future.  How far off in the future is a question that remains to be answered.

The presentations on Windows Azure presented a fairly realistic picture of where the technology is today, and I give the presenters credit for that.  Michael Stiefel’s presentation was good and gave the 50,000 foot view that I was looking for.  He also drilled down a little bit into the services provided in Azure, including  high level.  Ben Day’s presentation was particularly good I thought, pointing out the potential of the technology while balancing that against some of the limitations of the current implementation, particularly related to Azure data storage.  I would assume their blogs will have the presentations at some point in the future, so you may want to check in.

The presentations and keynote showed how you can get started with Azure today using Visual Studio 2008.  You will need to install the Azure SDK and Azure Tools for Visual Studio that you can find here. Azure applications can execute locally on a Development Fabric, which is a simulated cloud environment on your desktop. You can also deploy a service to run in the Azure cloud, but you need to set up an account for that, and for the purposes of learning about the technology it would seem that the Development Fabric is adequate.  The developer “experience” (another big buzzword at the conference) is the same as developing other Windows apps in Visual Studio.  You can debug applications normally if they are running in the Development Fabric, however once they are deployed the only debug mechanism is logging statements.

This is definitely a “down the road” technology, and there are several kinks to work out, but if you want to be ahead of the curve it might not be a bad idea to try some of it out.  One of the things that came up in the presentations is that Microsoft is on the fence on some aspects of the implementation and will be looking to the developer community for feedback.  We’ll have to wait and see how all this plays out, but I am certainly willing to give it a spin.

I got a new car recently.  For the last 10 years, I have been driving a Jeep Cherokee with roll-down windows, manual door locks, and no modern conveniences other than air-bags.  Now I am getting used to all kinds of conveniences like lights that shut off on their own when I turn off the car, ABS, stability control, and even power windows and locks.  Basically all the good things that the rest of you have enjoyed for a while.

It took a bit for me to come to grips with the fact that a car with ABS can stop the car better on snow than I can by gently pumping the brakes.   And I am pretty sure that I’ll never get a dead battery because I left my lights on.  So what does all this have to do with software you ask.  Well I’ll tell you.

I love all these new features.  But there are a few things that my car does that I think may have been “cool” to the guy that designed it, but maybe not such a great idea in the long run.  My favorite example is the stability control system.  The stability control feature will do wonderful things like help keep me pointed in the right direction if I start to lose traction in snow.  What’s wrong with that….nothing, I love it.

What drives me crazy is that when the stability control automatically activates, an alarm sounds telling me that it has kicked in.  Now I have one job in all this and that is to drive the car, but when I hear an alarm my first reaction is to look at the dashboard and find out what is wrong.  Whoever designed this “feature” probably thought it was a cool thing to do, and we might as well use the buzzer in the dash for something, but is an unintended consequence of getting a driver to take his eyes off the road while losing traction a good thing?   I don’t think so.

We’ve all been in situations when we have wanted to do something because it would be fun to implement or maybe would use a technology that we’ve always wanted to try.  That isn’t a good enough reason to do put something into a product.  It needs to add value to your product and be the right approach.  If you want to try out a new technology, put it in a spike solution where you are free to experiment and where it stands alone and is easier to be reviewed. Prove that it works and show it to your peers.  Determine how it can make your product better and convince the product owners.

Being agile means responsing to changing requirements and technology, but product decisions need to be made in the light of day.

By the way, this has not been a problem on the teams I have worked on.  It’s just that we’ve been getting a lot of snow lately and that stability control alarm keeps going off.

I have been using Agile techniques on a regular basis for about 3 years now.  The team I work in has gone through some interesting evolutions with our iteration and release planning, and at the moment we are using Rally as our planning tool.

A little history first might be helpful in how we got here.  Early in the project it was just 2-3 developers and we were all developing C# code, using Visual Studio Team System.  Team System has a pretty good work item and defect tracking system.  You can enter defects, tasks, provide time estimates, and have dependencies between tasks.  Another really nice feature was that your check-ins could be linked to a task/defect, so to go back and see what changes were made in the code against the work item was pretty easy to do.

When the team was smaller this approach worked pretty well.  Our iteration planning meeting involved going through the open defects and work items (tasks, essentially).  Most of what had to be done was implicitly understood by the stakeholders, so priorities were typically pretty clear and mostly it came down to a scheduling exercise.  Team System did not seem to have any good mechanism for defining user stories and linking them to tasks, but with a smaller group of stakeholders and developers we were able to get by without a lot of user stories.  Was it a mistake to not put more effort into user stories?  Maybe, but that was the world we lived in.

All this worked pretty well while the team was small, but as the team grew it became more unwieldy.  There was no mechanism to graphically display the tasks and do any long term planning.  It was just a big task list.  You could sort it, but being able to lay it out graphically was not supported.  For a time we used a manual process where major tasks were put into a Visio diagram and grouped into iterations.  That allowed the team to see how functionality would be rolled out, but keeping it in sync with the work item system was a manual process and difficult and time consuming at best.  There was also no automated way to see if we were overloaded.

As the size of the team grew both in terms of developers and other stakeholders, we needed to find another solution.  We looked at several tools and decided to try out Rally.  Rally’s Community edition is free for up to 10 developers.  It also has some of the features that I found were missing in our previous process.

• Graphical- Easy to drag and drop stories into different iterations and see when new  functionality will come online
• Supports resource loading, so we can see how our iteration and release plans measure up against available resources
• Hierarchical – Everything starts with a user story or a defect.  Tasks are grouped under the user story or defect.  It is also possible to have a hierarchy of user stories to group and plan related functionality.
• Supports releases and iterations, so I can plan when formal releases will be available and easily see what feature sets (user stories and defects) will be in them.
• Built in reporting tools for defects, and iteration burn down rate.

Like any tool it has a few warts, and I am sure I will get around to posting about them.  But in the two months I have been using it I am pretty pleased.

I held my first project retrospective this week. It was probably overdue, but there is no time like the present right?

I found Peter Steven’s blog and Boris Gloger’s paper on Heartbeat Retrospectives helpful in setting the format. I decided to cover the following topics in our retrospective

• What did we do well?
• What can we improve on?
• Who has ownership of the things that can be improved?
• What are the priorities?

We used sticky notes and a white board. You need to be succinct to state your point on a sticky note. Plus once they go up on the whiteboard they tend to lose ownership and they become the team’s ideas. There were only a few times when we had to ask who wrote something and that was only to clarify an idea. The group ownership of ideas keeps things flowing and prevents the meeting from being driven by one or two strong personalities.

Starting with “what went well” set the tone that the meeting is going to be positive and constructive. At other companies I have been at these type of meetings often turned into a finger pointing exercise and went downhill rapidly. Our team has a lot to be proud of, and it was great to reflect on the things we did well. And if it ain’t broke…..

The things we thought we did well broke down into 3 catgories: Team, Process, and Technology. I am not sure if that categorization was planned or an impromptu decision. Grouping them into categories didn’t really serve any purpose other than it allowed us to acknowledge each point as we decided where it belonged.

Like any project there are things that we can do better. We purposely did not put any limits on what people thought we could do better. Once we put everything up on the board we broke it down into two groups: Team and Organization. Team means we can do it within the framework of our own team structure. Organization meant we had to bring others (HR, management, etc) into the mix to help address the problem.

Once we had things broken down into 2 categories, it was time to prioritize the lists. There are a couple of different schemes you can use here. Seeing the same issue raised by multiple people may indicate something that is important. Ultimately we decided to do a simple voting scheme where everyone got one vote, and that seemed to work pretty well. Next time we may try giving everyone three votes, but that’s for next time. We have a small team, so there were only a few items in each category that got votes, but even that tells you something, and we were able to prioritize those items. The reality is you can’t fix everything, so you focus on what is most important.

Probably the most important part of a retrospective is that you take action on the high priority things to improve. I am anxious to seize the momentum and teamwork of the meeting. That is the challenge for me and the team in the very near future.

To paraphrase one of my favorite quotes from The Mythical Man Month

How does someone go from blogging about Energized Work to being too busy to blog for 6 months.

One day at a time.

I went away for a relaxing weekend, far from cell phone reception and internet access. Given my recent post about not being able to turn it off at the end of the day, maybe it is slightly ironic that I packed two books: The Art of Agile Development and The Art of War.

The Art of War is one of those books I like to pick up from time to time. I am not a fan of comparing war to sports or work, there is no comparison. The book is a good read though for understanding strategy, how to utilize resources, and human interactions. Many of the concepts are applicable to daily life.

I found an interesting passage in The Art of War that could be applied to the concept of Energized Work.

In War,
   Victory should be swift
   If victory is slow,
   Men tire, morale sags
   Sieges exhaust strength;
   Protracted campaigns
   Strain the public treasury.

If men are tired,
   Morale low,
   Strength exhausted,
   Treasure Spent;
Then the feudal lords
   Will exploit the disarray
   And attack.
   This even the wisest
   Will be powerless
   To mend.

Logically, I believe in the concepts behind what the XP community refers to as Energized Work. Software engineering is a complex activity and it requires you to be fully engaged and focused. That is hard to do if you are working long hours. The problem I have with it is that over 20+ years of working as a software engineer, I have conditioned myself to work to the limits.

I was talking with another developer about this recently and I said that it really takes buy-in from management to make Energized Work possible. He turned it around and put the burden back on me. His thinking was it only worked if I made the decision to follow the principles and it would never work if I waited for someone else to make it happen.

That meant I had to make the decision to leave work at a regular time. That I had to make the decision to spend time with my family instead of sneaking off to do work. This developer and I have worked together in the past and he knows my work habits pretty well. His analysis stopped me in my tracks.

Bad habits are hard to break. One of mine is not being able to turn it off at the end of the day. I have to put the blame for that squarely on me. I have no problem saying to another developer “Go home, you’ll get it in the morning”. I need to remember to apply that advice to myself from time to time.

Inspired by James Shore’s recent Energized Work haiku (and feeling temporarily brainlocked) I decided to tap my inner muse

Commented out code!
Detritus of method's past
Time to refactor 

I know…..don’t give up the day job. And give me a break, I know refactoring is a lot more than removing commented out code, but there is only so much you can say in 5-7-5 syllables.

Plus, I really wanted to work in detritus. Not a word you get to use everyday.