Chris Johnston

The empty lot next to my office has been converted into a parking lot. The interesting thing is how they have gone about doing the construction. The architects and contractors could have brought in the pavers and cement trucks and built a full parking garage immediately. The work would have taken several months to a year and been very intrusive to everyone trying to work near by.

Instead, they brought in a minimal amount of equipment, put down some dirt, graded it, install fences and a pay system and left. That minimal amount of effort, the simplest thing that could possibly work, was good enough for several months.

We had a warming trend and the dirt was starting to get pretty churned up with large ruts starting to form in the middle of the lot. So, the crews came back with some gravel, re-graded the lot and covered it with stones. As I look out my window now, the lot is functioning great. It isn’t perfect, but it is completely functional. Everyday there are cars parked in.

I am sure that eventually the crews will return and pave it, making for a more permanent lot, but for now, it works.

Too often in software development people feel that they have to release the perfect product or, at least, release a fully functioning piece of software. I know were I work this is something we are trying to move away from. In my opinion, it is much better to release the functional, dirt version first and let people play with it. Give it enough time to figure out where the ruts are forming and then go in and gravel.

I have a theory that, with most software, all that is need is about 60%. We only need to implement most of the functionality for people to be both productive and happy, e.g., the gravel version. By starting with the dirt version and working up, we are able to stop when we hit the right point, be that the gravel version or the initial paved version.

I recently did a retrospective with my team which is located in Toronto and Chicago. I wanted to do a fairly traditional retrospective, but having people write things on stickies on posting them on a wall was not possible. Instead, I decided to use Google Docs and created a simple text document. It had the prime directive on the first page and then, when we scrolled down, there was a section for Good, Needs Improvement, and Confused.

This worked out really well as it gave everyone time to think about they wanted to write and also allowed everyone to modify the document simultaneously. I then was able to organize the ideas presented easily by simply copying and pasting them. Voting was done by putting a * beside the idea the person thought was most important. Another great benefit was the fact that we now have a record of everything presented in the retrospective.

…if you don’t keep your smartest people fully-informed, you’re going to wind up telling them what to do. And telling knowledge workers what to do is one of the biggest causes of mistakes, waste, and general low morale that I’ve ever seen.

I really like this quote from an article about letting employees take control of their time. The two points I got from the article were, one, that in order to make this work, you need to give your employees ownership of the success of the company and, two, that leadership needs to be completely open about everything and tell employees not only the what but the why.

These two points, plus the quote above, translate directly to development teams. One of the practices of an Agile project is group ownership of the code. So if one development pair sees a problem in the code, it is their responsibility to fix it and not ignore it because it is someone elses problem. If there are bugs in the code or a project fails, then responsibility for that is shared by the entire team, not just the developers that implemented it.

Transparency in business decisions can be seen in the use of story cards. I worked on one project were the “so that” part of story cards was missing. We were implementing bits of functionality and not adding business value. This lead to a lot of debates with business as to why we were implementing certain things.

As for telling people what to do, this one drives me crazy. One project I was on, story cards were placed on a wall and given out by the tech lead. Dev pairs were not able to sign up for stories. You could request a story, but it amounted to asking for permission to work on a particular story. You could not just pick up the next story without asking if it was okay to play it first.

People need to feel that they are trusted and once you give them that trust, they will surprise you. Trust them, give them ownership of the project they are working on and allow them to understand both the what and the why and you will amazed at what people create, because now they are not creating something for you they are creating something for themselves.

Siva Jagadeesan has posted an interesting article titled, “Fresher and Experienced Developers – Friends or Enemies ?” In the article he lists some of the advantages and problems of pairing freshers with experienced devs. He touches on many of the problems I have with pairing and does a much better job expressing some of my frustrations then I did.

I think I fall somewhere in between a fresher and an experienced developer, but I can definitely relate to all the problems listed. It is amazing how your morale suffers after 5 days watching someone else code cause you don’t know enough to contribute.

I have a problem with the solutions Siva gives though because they all seem to be aimed at the fresher. It takes two to have a problem and as such would like to offer up some advice to the experienced dev:

1. Be patient and allow your pair to make mistakes to the point where they get themselves in trouble. We learn best from our mistakes.
2. Even if your pair is moving slowly, stay focused on the task at hand. I really hate when I start driving and my pair immediately starts doing something on his notebook computer.
3. Ask for and accept feedback from your pair, you are not always right regardless of how experienced you are.
4. Pairing is about more then just finishing a given story card, make sure you also teach. And teach more then just the task at hand, make sure you also teach the overall context.
5. Accept the possibility that your pair may know more then you in some area and be prepared to learn from them
6. Do not just jump all over the code base, wildly scrolling through pages. Slow down and explain what you are doing and what you are looking for.

Also, one thing I think we miss is that fresher is both someone new to programming, e.g., someone just out of university, but also to someone new to the code base.

One thing I have been thinking about lately is who owns, or should know about, tech tasks. The team I am on right now, we need to justify every tech task we do with business and if business value for that task cannot be found then it doesn’t get done.

For some reason, I really don’t like this approach and for the first time, I have read a blog that expresses what I have not been able to as of yet. John Pither calls this tech leakage and explains it as such:

If we can see the dev team as an animal in the jungle (and so forth we have other ‘animals’ such as QA teams, BA teams, Project Managers etc), then ‘dev team leakage’ refers to the cutting open of such a large and volatile jungle beast and of letting it’s gooey entrails slide out and slither amongst the wider natural setting of which the poor animal finds itself.

Yep. Basically it’s about breaking encapsulation. In the case of a dev team, there are many inner workings that need not be externalised to the outside world.

As graphic as this analogy is, I really like it (okay, I have a morbid sense of humour). Tech tasks should belong to the dev team and simply be a part of how we do our day to day jobs. I find that I spend far too much time explaining why I am doing a particular refactoring to a BA or business because the team does not own these tasks. In addition, far too many tasks never get done because we cannot justify them with business value.

One consequence of this anti-pattern is that nothing really comes out of retrospectives. Yes, do them every week, however, every action we create must first be justified with business and given some business value before we are able to carry it out. This means that we never have the chance to clean house and carry out those dev tasks that we should be doing as a part of our jobs.

One practice that I have observed that seems wrong to me is re-estimating cards after they have been completed. The dev pair completes the story card and the BA comes over and asks them to re-estimate the card based on the implementation.

From the BA’s point of view, s/he is asking for the re-estimation for planing purposes. The reason given is so they can accurately plan out the stories for the next iteration. On this same project, there is also a lot of talk about correctly estimating cards. To me, this completely misses the point of estimating cards.

Story card estimation is a best guess of either the complexity, the story card size, or the ideal days needed to implement the card. That is all. This means that the estimations are inherently wrong. The point though is that they will be consistently wrong and over time, with the addition of velocity, the amount of work a team can get done will be correct.

If a team consistently underestimates, then the first iteration they will do more cards then they committed to. The velocity will show this and can be corrected the next iteration. So the first iteration they commit to doing 12 points and they actually do 15. The next iteration, simply select 15 points worth of story cards. Rinse and repeat.

By asking devs to re-estimate cards once they are completed you are breaking the corrective effect that velocity has on the process. The points on the cards carry less meaning because they have been adjusted after the fact. This means you now need to add a correcting feature into the teams velocity.

The team committed to doing 12 points and completed 15 points, but two of the cards they originally committed to doing were actually 1s and not 3s so did they in fact do 15 points or 19 points? So which cards for the next iteration are going to be re-estimated down and which cards will go up? Does this mean that the team should be doing 15 or 20 points for the next iteration?

My guess for the re-estimation requests is that the BAs do not trust the process. They do not believe that velocity will naturally add the needed correction. So instead, they try to do it themselves. In addition, on this particular project, I also think that business is trying to add to many features during a single iteration and the scope is just too large.

I think there is a time and place for re-estimating a story card, but after the card has been played it not one of them. If, before playing a card, more information becomes available that directly reflects the implementation of a card, that card should be re-estimated. This might include the outcome of a spike or the introduction of a new technology or a change in the development team for instance. The point is that this happens before a card is played, not after.

What do others think, can a story card’s estimate be updated after it has been played?

I have been trying to learn Agile software development for the past several years and there are several things I don’t quite understand and I’m hoping people can enlighten me.

Why comments are evil?

This one I think I might understand to a degree. I agree with the idea that comments can very quickly get outdated and far removed from the code that they are suppose to comment. I also understand that if you write clean code then “what” comments are unnecessary. The thing I don’t understand is why this means that we should actively go through a code base and delete all comments? Or why we as developers should deride code that contains comments?

I personally think there is a place for “why” comments in a code base. I come across an odd bit of code, an odd business rule implementation, should I have to go and find the user story to find out why that particular odd decision was made? Or should I have a unit test explaining it: shouldDoThisBecauseIn1973BusinessMadeAOneOffDealWith...(). Where is the right place for this information to be captured? I would think that a story card would travel farther away from the code even faster then a comment.

Why design is evil?

This is probably my biggest pet peeve about Agile and the thing I really don’t understand. Why is design evil? We seem to have this idea that doing up front design before starting a story is not allowed. You cannot be doing XP if you do design, “design is waterfallish, we have organically grown code here.”

Personally, I think that in order to have well designed, clean, layered code, you need to do some design up front and you need some kind of architectural model to which your organically grown code adheres to. Otherwise, instead of lasagne, you get ravioli.

Why must you pair all the time?

I have already stated that I don’t really know how to pair and this is an outcome of that. I have heard of shops were if you are not pairing you are not coding. Heaven forbid that either you or your pair are ever sick. Are there no kinds of coding jobs that can be done by one person? Is there no benefit or place for a single programming sitting quietly in a room with the door closed focusing on a problem? What about all those studies that have been done about flow and the fact that open offices promote sickness and disease? What about a little privacy during the working day?

Why Agile principles become Agile rules?

This is the thing I don’t understand the most. Why is it that for many people and many shops, Agile principles become rules and the only way to do things? I have met people and worked in shops were they have Agile all figured out and any deviation is heresy. If you are doing Agile this one way, then you are unprofessional and a very bad programming. I always though that principles were just that principles, guidelines, starting points, rules of thumb. Things to be discussed, to be examined, and possibly bent or even broken when the situation calls for.

Isn’t one of the prime tenants of Agile the idea that we should analyze what we are currently doing and make it better. Doesn’t this mean things need to change? Or does it mean we are not disciplined enough in our adherence to one true path of Agile?