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.

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.

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.

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.

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?

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?

I only want you to tell the team what you think is valuable to them; what did you do or find yesterday that is of value sharing with the team; what do you know, that we need to know.

Ever since I was on a project where we were told to not talk about anything technical, I have always wondered about what is of value to the team. I am a developer, valuable things to me are usually technical and of no value, or interest, to the business people. Does this mean I should say nothing at my stand up?

At my current project, our stand ups have gotten very dry and boring. They have basically devolved into status meetings about we did yesterday. We then have a dev huddle around the story wall and actually discuss things of possible value. In reality, this is also just a status meeting where we give our current status to the tech lead. He goes through the stories and we say where we are and when we will be finished.

This has always bugged me. First because I don’t really like giving my status twice and second because it seems a tad redundant. Shouldn’t I be saying in my stand up what I would say in the dev huddle? Also, because the dev huddle has no real rules assigned to it, it can get quite long and boring.

Okay, back on track and enough with the complaining. I merely offer up the above as an example of my question about what the point of a stand up is and how does one decide what is appropriate to say and has value?

So, I would like some help. Hi, my name is Chris and I can’t pair.

There, I’ve said it. I have taken the first step and realized that I have a problem. Now if I could only figure out what the other 11 steps are to becoming a great pairer.

Here’s the thing, I keep hearing these stories about pairs who sit in front of a computer all day long, so much in the zone that they are able to right code telepathically. They never talk. They never argue. They never discuss and beautiful, simple code drips from the finger tips into the computer. Every line is surrounded by tests and their api’s will be studied from now to the end of time.

And then there’s me and my pair. I go to touch the keyboard and my pairs fingers are twitching above their keyboard like their life depends on entering one more line of code. I haven’t even written anything and they are correcting me.

So, I ask a simple question, “how do you pair”? How is it possible to work with someone so closely all day without stepping on each other’s toes and fighting about what it is that you are implementing?

I think my problem is that I am not an experienced developer (I’ve only been doing this for a few years compared to most of my pairs who have upwards of ten years under their belts) and I want to contribute something. I don’t really want to sit their and watch someone else type. However, the people I am pairing with don’t know how to pair either. They are used to sitting in front of a computer alone and banging out code.

And due to my inexperience and lack of pairing know how, I have no idea what to do?

This really rubbed me the wrong way. Agile is not about what works today, it is about making things better tomorrow. It is about identifying that little, or big, thing today that we can do just a little better tomorrow and implementing the change. If it works, we then find the next thing to improve and if it doesn’t work, then we try and figure out why and implemented the idea differently.

When it comes to the processes and practices we use everyday, “but it works fine now”, is simply unacceptable. It means that we have stopped moving forwards and have stagnated as a team. Regardless of how good things may seem, we always need to be asking how we can make thing better tomorrow.