If its too hard - do it more often.

During a panel in the latest Scrum gathering, a question was raised regarding how deliver a potentially shippable product each sprint if it takes 3-5 days of stabilizing the product to get it to a release level.

Its a relatively common question which has various answer, however Scott Ambler has given it a gem of an answer(in my opinion at least). His answer went something in the spirit of:

if it takes you that long then you must do it more often, in fact keep on doing it until you learn how to reduce the time that needed for stability.

This somewhat relate to a previous post of mine,  Cost of Change – The Fear . Investing the effort to fix pains that we learnt to live with is always a low priority. In fact the bigger the pain is, its harder to fix so it slips down the list. After all, if it was easy, we would have done it already.

So Scott gave a good way out. Basically he advices to enhance the pain! If its a scratch cut it with a knife. if its a twisted leg, break it completely. Make it hurt so bad that ignoring it is no longer an option, and the only course of action will be to fix it. A drastic approach but one which works.

Read more »

Posted in: Agile practices.,Random Thoughts,Scrum,Self Improvment

Distributed Card Meeting

I'm a big fan old low tech tools when it comes to meeting and information sharing. There's nothing more informative then a plain white board and nothing more useful then a bunch of sticky notes when trying to plan something.

There are times when these tools are not optimal, usually this happens when all the participants are not physically present. In such cases try using CardMeeting, its a "whiteboard sharing" application that give imitate the behavior of a board and notes just done on a virtual wall that can be seen distributed places.

On the up side the setup is very easy the use is very intuitive and it does keep it very simple. Also, the data can be exported into an excel sheet for future usage.

Read more »

Posted in: Agile practices.,tools

Documentation in an Agile Process

One of the more common misconception about agile is to think that it means no documentation. In the original Agile manifesto we can find that we value:

Working software over comprehensive documentation

For some reason people mistook this to mean that documentation has no place in an Agile process.

In my opinion this is very far from the truth. What I do agree is that the commonly form for documentation i.e. text files, that most people mean when they say documentation, is probably not the best way to get the job done.

Why do we write documents?

I recently had a nice discussion with Eyal Katz about the need for documents. Eyal listed the following three reasons:

1. To make the writer really think about what he is writing about. For example by writing a design document the designer is forced to think and formalize his design properly.
2. Documents can later on serve as a mean for sharing knowledge.
3. To store knowledge (so we wont forget)

Are documents cost effective?

well in my opinion the answer is clearly no (in most cases):

I myself think better against a white board. For me sitting against a computer screen is just not flexible enough. When I do a design session using a white board, I usually complete in an hour what can then takes me 3-4 days to write down. So clearly, for me, writing a text file is not the most efficient way to think and I'm sure other people have even better ways.

But how can other people read/understand what I sketched on the white board? Well they cant. But generally it doesn't take me more then a 20-30 minutes to explain it. So instead of spending 3-4 days writing it down, I can personally teach it (and trust me its much more effective that way) to 60-80 peoples in a 1 on sessions. So how many people are really reading most of the documents we write?

but what will happen in a year from now if I don't write it down? Well, the real problem is that without maintenance documents gets outdated. Wherever I go, I see that knowledge stored in text files is almost always either partial, old or just plain wrong. For some reason software companies don't do a good enough job in making sure that their text files reflect reality.

No documentation in an Agile process?

on the contrary  a lot of documentation, just not a lot of the regular kind (i.e. text files). Some examples:

• Product & Iteration backlogs serves as a good place to specify requirements.
• Unit tests serves as good low level design documents
• Burn down charts serves as great progress reports.

When taking into account all forms of documentation an agile project will usually have a lot more documentation then seems at first sight and in most cases that documentation will be more accurate and effective.

Uninstall Word?

All this does not mean that good old text file don't have their place. Just to say that from my experience they are widely misused. Knowledge stored on paper (or in files) is far less important then knowledge stored where it counts in people heads. A true Agile project will first make sure that it gets to there before it goes into a text file, and not vice versa.

Read more »

Posted in: Agile practices.,Documentation,Random Thoughts

The Fifth Value – Respect

There’s a lot to be said about respect but for some reason this value is not stressed enough. I think that much of what troubling the software development world today can be traced back to this value. Lets face it most developers are arrogant bastards(and yes I’m a developer too).

Taken from Kent book:

Every person whose life is touched by software development has equal value as a human being. No one is intrinsically worth more than anyone else. For software development to simultaneously improve in humanity and productivity, the contributions of each person on the team need to be respected. I am important and so are you.

lets take a few examples I’ve encountered (ok, ok I’ve said those):

• “our customers does not know what they want. Ill tell you what they want”
• “our test team don’t have a clue on what they are doing and how to test the system”
• “I don’t trust our system deployment team to properly configure the system in at the customer site”

and the list goes on.

The problem is that this kind of attitude, even if its backed up with real hard facts, leads to a basic lack of respect, and this will effect the project outcome.

I try to treat everyone the same (with partial success I admit), when facing incompetency, I first try to see if this can be fixed (in many cases what looks like incompetency is a result of a simple lack of knowledge) and if it cant, I will look for a replacement. Most project I’ve worked on don’t have the luxury with the less capable.

Read more »

Posted in: Agile practices.,Random Thoughts

The power of combining Unit tests with Integration Tests (conclusion)

Here and Here I explained why I think that unit tests alone or integration tests alone does not do a good enough job at assuring the quality of the product. However, that combining the two test  levels, i.e. investing some of the effort in integration tests and in unit tests is what I call a winning solution.

Investing effort on both levels allow one to benefit from both worlds

on one side integration test will help in:

• formulizing the user requirements.
• make sure that system is working end to end.
• test non functional requirements

on the other side unit tests will help in:

• driving the design of the system to a better one.
• give a good coverage of all parts of the system
• eliminating defects that get shipped with the system.

I have been suing this approach in a TDD style in which the development process of a new feature(user story) started out by writing a few (failing) integration tests then followed by writing some more (failing) unit tests and only then starting to implement. this kind of process has worked for us.

The million dollar question is of course “how much do invest at each level?”, and the real answer is I don’t know. I think that it really depends on the specifics of the project and the system under test. In some cases it makes more sense to invest more time on the unit level while in other its better to spend more effort on the integration level. I really think that the best guide to that will be to use common sense and see how things works out.

Read more »

Posted in: Agile practices.,Integration Tests,TDD,UAT,Unit Tests

Numbers Talk - Real Agile Case Studies

I've recently found about the existence of the Agile Bibliography Wiki.

I believe this site is a must for all those interested in understanding the real measured effect various agile practices can have on projects.

I admit though that after diving into it for a couple of hours there's too much for me to digest at once. Therefore I will need some time to see what hidden gems I can find there.

The most interesting thing in this WIKI (for me) is the existence of case studies which examine the effect specific agile practices such as TDD, Pair programming have. This gives me a good starting point in trying to show organizations that even early stages in adapting agile methodologies can have a good ROI.

At any case I would like to thank George Dinwiddie for pointing me to this site.

Read more »

Posted in: Agile practices.,Research

Source Branches

I hate branches. I think that branches are a bad solution for a stinking situation.

now before you I get jumped, I’m aware that there are cases in which branches are a perfectly legitimate solution to a given situation, but still my advice would be to try looking at what is causing the need for the branch, in my experience there is an underlying problem that the branch will not solve.

In the Last Alt .NET gathering I had a very nice discussion with Ken Egozi regarding branches. In that discussion ken and I represented the two opposites approaches. Ken on one hand is using Git and relies heavily on its great branching ability. To the point (if I understood him correctly) that he treat each source change as a different branch. I on the other hand uses SVN and try to avoid branches as much as I can.

During the last year I have used branches three times, in all of those cases I’ve came to realize that the branching was just a mechanism that allowed my to ignore the real issues but just caused us to waste time and effort. Here are the stories behind those branches:

Branching to sustain Quality

I think this is the most common use of a branch. During our development we reached a stage in which we felt that between solving defects and trying to add new features, we couldn't keep our code quality high enough. Preventing us from releasing in our desired rate (about once every 2 weeks). So we branched. Like many other project I’ve seen we thought to use he branch as our release base on which we would solve defects. leaving us to implement new features over the the main trunk.

quite simple right?

Well not really. after trying that for a while we found out that we were always merging all defect fixes from branch to trunk (as expected) AS WELL as all changes from trunk to branch!!!

when facing reality, each new feature we worked on was important enough and it was finished the business side opted to merge it into the branch so we could release it as soon as possible. The result of course was that the trunk and branch were practically identical. We just wasted time merging between the two code lines without addressing the real quality issues.

Branching To fend off a feature

Just before a trip our “customer” has insisted on implementing a couple of features in the last moment for “demonstration” purposes. Those features were quite controversial and we really didn’t want to implement them as they were especially on such a short notice (in fact we had quite an argument on how those should look). However since the “customer” was quite insisting, we choose to implement them on a branch, hoping to discard the branch at the end of the trip. We really wanted to sit down and do a proper decision on those features.

Naturally, at the end, those features were merged as is immediately after the trip, and all attempts to resist that merge failed.

Branching To avoid completing a feature

My latest experience with a branch was caused by me leaving. As part of my final days I was charged to complete a task I already started a task which is just the first step in a series of improvements which are long over due. When finishing the task, since no one actually knew how things will progress from here it was decided to put the task changes into a branch. putting it on a branch should allow picking them up later.

I myself am very much in doubt. I would say that most likely this branch will continue to exists and will never be used again. A branch in this case is just an excuse for putting this work aside still having a false sense of confidence that this can be picked up again. In fact unless those changes will be continued quite soon, they will be so much harder to pick in the future so they will never be completed.

These were my experiences with branching. In retrospect all these branches were just Mistakes on my part. In the first case instead of dealing with the causes for quality decline I tried to shove them aside into a branch. In the second instead of accepting the decision I tried using a branch to fend it off and last instead of admitting reality again a branch is used.

I would really much like to hear about you experience in using branches. Is the dislike I have towards them is just my own or do people out there share this.

Read more »

Posted in: Agile practices.,Source COntrol