So what is the Product Backlog?

Trying to define what is a product backlog is always a tricky business. One definition I use from time to time is:

The product backlog is just another way of describing the system requirements and serves to describe the work needed to be done

Which is a good way to simplify it to death. I had reasonable success using this definition with agile beginners, but clearly it doesn’t start to capture its entire meaning.
The more official definition taken from the Scrum guide at Scrum.org is:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Which is more complete, but still raises quite a few questions. for example:

• What is everything? (new features? bugs? technical enhancements?…)
• If it’s a single source does it contains all the details? (i.e. the requirement docs)
• what is actually written inside it (how do we write those requirements? use cases? stories? plain English?)
• Is it a business facing document (i.e. read by clients and user) or is it a technical document (i.e. serves the team who needs to understand what to build)

So what is the Product Backlog

when trying to answer this I go back to my first initial encounter with  agile. At that time what I actually read and first saw was the work done by Ron Jefferies and Kent beck on eXtreme Programming. and what I still recall today is the simple statement in which Kent Beck explained that the whole purpose of agile is to bring all involved parties to one table and make them work together in order to create great products. (unfortunately I cant seem to locate the exact quote). At that time I didn’t know what a Backlog was and I was just starting to understand all the various agile techniques. but that statement just stuck and for me it’s the best way to describe what is the main goal of the Product backlog.
Forget about stories, requirements prioritization, acceptance criteria and all other technicalities which are associated with the product backlog.
In essence, when done right, the product backlog is the one “thing” that makes all involved parties converge communicate and cooperate in order to make the product a success.

The interface between the problem space and the solution space

To take it down into more specific terms what I think that the product backlog main role in the project is to serve as an interface between the business facing aspect of the product AKA the Problem space and the technical sides AKA the Solution space. On one side the Problem space is using the backlog in order to help it define the problem and describe on his terms WHAT its need to be done in order to help with the problem and on the other hand the Solution space uses the backlog in order to sort out the actual work. the team need the backlog in order to understand what is actually expected from him, what exactly he should build, what needs to be developed first. and most important use it to create a shared language he can use to talk to the business people and create a shared understanding.
And I’m guessing that this dual nature of the product backlog is what sometimes causes all these misunderstandings we see. here are some examples:

1. Every team occasionally needs to do things which are very technical in nature and involves a significant amount of effort. Being the single source of incoming work its not unreasonable that they will want to add it to the product backlog. However, these kind of things tends to be less understood by the business side, and suddenly there’s a conflict: “why do you add theses things that has no value to me?” asks the PO. “you know what, if you need it lets keep it there but please reduce the priority of it” which practically means ok I will let you put it there, but lets make sure that you actually wont work on it.
2. Being the single source of work, a reasonable team working in short iterations will expect backlog items to be of a certain size (typically a few days worth of effort). However, splitting requirements in a sensible manner is really hard work. The “Problem space” natural tendency is keeping the items size much bigger. I’m guessing it makes things easier to manage on their side (and of course avoid the extra work of splitting those into small chunks) and again we have a conflict
3. Not only that the Solution Space demands the things to be small, it also needs them to be FULLY prioritized. Even more hard work for the “Problem” side.

Now don’t get me wrong, there is no right and wrong here. All sides in all these situations are “right”. IF you look at it from there side. 

Treating the Product backlog as an interface

The moment all sides respect the fact that the product backlog is not only there to serve their needs alone, things tends to become much easier. When Technical people understands that the product backlog is the place in which business side describes the “Problem” and respect that. They find it much easier to keep it in a way which is understandable by the business side (avoiding the regular technical language they tend to use internally). When the business side respect the fact that the backlog is used to manage the actual work done. they find it reasonable to invest the effort needed in splitting, prioritization and other activities needed.
So don’t forget the Product Backlog is an interface. it’s the one thing that can be used to establish effective and productive communication by all sides of the business. Take advantage of it.


if you are also

• Having a hard time splitting user stories to shippable items?
• Struggling with predicting when will we reach the deadline?
• Having a hard time with prioritization of requirements?
• Does it seem that the team never understands what you mean?

Then come join our Product owner workshop.

Read more »

Posted in: Agile practices,Scrum

Can your team agree to this?

Read more »

Posted in: Agile practices,Engineering Practices

Must programmers know how to Test?

I was never asked before if a programmer should know how to test. The underlying assumption is that programmers know hoe to test their own work, and therefore are skilled at testing. Problem is that they are not. And the sad thing is that so far they have managed to get away with it. I’ve been a professional programmer(that is writing code for a living) for more than 10 years, in all the places I’ve worked my managers did ask me if I tested my work. And my answer was always “of course”.  But never was I actually challenged on that. No matter how many bugs were found in my code, no matter how much empirical proof there was that I did a bad job at testing. None of my technical managers ever told me, “please take this work back and test it again, and this time for real”, ever. And never have I seen it happen to any of the other programmer I worked with. I did get work back from time to time with claims that some of the functionality was missing, I did get a lot of bugs to fix. At times it was so bad that my “testing” activity usually only included making sure it compiled executed and didn’t crash on my machine. and that what I called testing.

Programmer who Cant test will become obsolete

As automation gains more hold in our industry people start to expect much more from testing at the unit level. In my last work place doing test reviews was part of our on going process, in fact we probably invested more time in reviewing test code than actual production code. For us it was extremely important to make sure that written code was properly tested (verified) at the unit test level. I expect this is very common to all software teams doing TDD. And while I’m sure many of us just wait  for this weird TDD notion to go away. its my strong believe that it wont. on the contrary latest surveys suggest that as agile is gaining in our industry the necessary engineering practices are also

Programmer – catch up on your testing skills

if you as a programmer want to stay relevant in future markets, you should really start increasing their testing skills. Yes there is still time before testing skill will be listed as one of the mandatory skills in job posting. The growing need for writing automation at all levels, gives a definite advantage (at least in my book) to programmer that has some sort of formal knowledge or experience in testing. (and yes I will need to see some actual proof and will verify such claims during interviews). No I don’t think a programmer should be a professional tester as well (although that might help), but basic concepts of QA, properly designing test suites and understanding that there are more than just unit testing is something I would expect every self respecting programmer to know. In  my limited experience I have found that programmers that posses this knowledge and skills are just better programmers.
And if you want to know how to start here’s something you can try: STARTING TDD – ONE DAY EXPERIMENT

Bottom line

As a programmer you should want to know how to properly test your work(at least at the unit level) ,in order to decrease the time you will be looking for a new job

Read more »

Posted in: Agile practices,ATDD,Random Thoughts,TDD

Must Testers know how to Program?

One of the most common question that rises when talking to testers in an Agile context is
“Does testers have to posses programming skills in an agile team?”
For a long time my answer to that was no, since testing includes vast number of activities which doesn’t require programming skill there will always be room for testers who cant program.
However I think that I was mistaken. these days I would expect anyone who claims the title of a professional tester to posses some level of programming skills. 

Testers who cant program are obsolete.

This fact can not longer be ignored.  As automation gains a firm hold in our industry a tester must be able to significantly contribute to all automation effort. And while certainly one can contribute to this effort without knowing how to program, the room for these is relatively limited.
Yes, even 10 or twenty years from now our industry will still have a large number of testers who cant program. The same way that even today there are still professional Cobol programmer or programmers who cant do object oriented programming.  But I would expect that this will be the minority

Testers who cant program – CATCH UP

If you want to stay valuable in the market, start learning the basic skills of programming today. no, I don’t think you will need to become an expert top notch developer (not that there’s nothing wrong with that). The actual skill level required in order to become a productive test automation engineer (i.e. significantly contribute to automation effort) is lower than that. But Unless you will start to aquire these skills soon you will find very hard to find new open positions.
Here’s an interesting post that backup these claims with some concrete data. And while I don’t consider this in any way as scientific proof or even big enough to indicate anything with significant statistical confidence, it still suggest that   ~80% of testing job posting indicated a programming skill as necessary. Also notice, this post was published as early as 2010.  My personal observation of recent job ads, which is certainly skewed towards Agile culture, suggest that the percentage is even higher.

Bottom line

As a tester you should want to know how to program in at least one major programming language ,in order to decrease the time you will be looking for a new job.

Read more »

Posted in: Agile practices,Agile Testing,Random Thoughts

One question at a time

Taken from Agile Testing list:

If someone asks me a complete list I tend to ask what is your most valuable question you want to get answers now.
And because I am a man I can only do one thing at a time ;)

Pascal Dufour.
What a great way to describe the process of test automation.
Yes I now the context of this quote was completely unrelated to anything about testing, But it did ring a bell for me.

Where should I start?

A very common question I hear many time when I talk to people about the need to test their feature. Many times that not because they don’t know what needs to be tested. But because there are so many things to test that it gets a little overwhelming and from all the many things its really hard to know where to start.
So here’s an idea. Treat your tests as question you would like to get an answer for. Each test case ill reveal a piece of information about the feature you write telling you some specific a fact about how the system behaves.
for example when you test a trivial add method one question can be: I want to know how my method adds too positive integer values. another question could be: I want to know how my method deals with adding a negative value to a positive value. and so on.
The trick is to ask yourself:

what is your most valuable question you want to get answers now"

that should be the first test you write, and when you get an answer the next test should give you an answer for the next most valuable question. and you continue to write tests until you don’t have any more questions to ask.

only do one thing at a time

Does this sounds like one assert per test?
To me it does. and now I have a good answer when people asks me why just one assert per test.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile practices,tips

TDD exercise for beginners

Two years ago I posted about this excellent site that contains various TDD problems that can be used by beginners to practice their TDD skills.
Over the last couple of days at the TDD mailing list there’s a thread in which people are putting links to all sorts of great resources for such exercises so I thought to put them all in one places for future reference

1. Http://nimblepros.com/resources – a site containing 11 code katas. I actually participated in a testing dojo that used the Gilded Rose Refactoring kata and it was great
2. http://stackoverflow.com/questions/2443697/tdd-exercise-ideas -  a thread discussing the same subject with several problems for TDD.
3. http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue – another (the original?) Kata catalogue. contains all the classics and then some
4. Roy Osherove blog contains two katas the first has variants in almost every language out there, and the second is a little more advanced aimed to teach interaction testing
5. http://cyber-dojo.com/ – when pushing the setup button you get a nice list of various problems.
6. http://coderetreat.org/gol – the classical Conway’s game of life used in Code Retreats

If you know of more sites and resources please write them down at the comments below

Read more »

Posted in: Agile practices,TDD,Unit Tests

Agile Contracts

Agile contracts is an interesting thing. one of the main push back against going agile I get in places is that while agile is nice and all there is no way we can convince our customer to work like this. “they want a fixed price fixed scope deal”. In any case this post is not going to talk about why Agile contracts are a good idea, or how to get buy-in from your clients to sign an agile contracts. This post is going to talk about:

The forces against an agile contract

The power of Inertia

People don’t change easily. The fact that our industry has been using a “Fixed …” contract for several decades now goes against trying anything else. Especially if that something else is substantially different. An agile Contract is exactly that. Different.

Risk

An agile contract puts the risk on the paying side (the customer), he is going to pay for the work done, even if that work is of lesser value. Naturally if its value is low enough  he can bail out. But still the risk is on him. While a “Fixed …” puts the risk on the development team. they need to fulfill their part before they get paid.

Trust

our industry has not been that great at delivering working software. (to say the least). Most software projects either fails completely or significantly does not meets expectation (either they miss the timeline, exceeds the budget or reduce scope)Potential Profit. An agile contract actually says exactly that. By going for a flexible scope (or time) we actually say we don’t know exactly what will happen, we don’t know what we can deliver (or when). That’s a hard message to tell the one who is paying.

Potential Profit

This one is a little elusive. One of thing we do as a development team when we go for a “fixed …” is add buffers to mitigate our risks. At one place I used to work I saw a two days chunk of actual work being priced as 11 weeks for the client. And he was willing to pay (there is a cost for putting the risk on the developers). For us as a development team this represent a significant potential profit. If we could just estimate accurately and actually finish the work in the time we say we can. The buffers just become easy money. No matter how many times we under estimate work, every time when we do a new estimate we are always sure that this time it will be different. This time we have considered everything. After all we are smart people.

As you can see there are strong forces affecting both side to resist going for an agile contract. Can you think of more?

Read more »

Posted in: Agile practices

Starting TDD – One Day Experiment

A repeating question I encounter a lot is how to start with practicing TDD. in fact a while back I wrote a series of post on how one can start this in various contexts
(part 1, part 2, part 3, part 4, part 5, part 6, conclusions)
some people claim that TDD is a group activity, therefore it’s a waste of effort to practice alone. I believe that TDD is a personal skill, and while its better to have the whole team doing it, it can be practiced alone. Nothing should prevent you from trying to improve the quality of your code. (and in most cases the added value will negate any delays you might experience initially).
in this post I’m offering another way to start. in fact I think that a controlled experiment might be a better way to describe this. but anyway

Practicing TDD for 1 Day

To start you should dedicate a full day for this. while I'm sure this exercise can divided into several sections, I think that to truly benefit from this (and avoid the cost of context switching) it should be done in a single day.
By the end of the day I expect you to achieve the following:

1. have a good understanding of what TDD is and what are the rules to follow
2. write some basic unit tests on a simple problem
3. write a test case for your own system
4. have a basic understanding of the tools involved in the process.

I also expect that you wont achieve the following:

1. fully appreciate the costs and benefits of doing TDD
2. understand how to apply TDD in all situation
3. Be able to write tests to all parts of your system
4. have a deep understanding of Isolation techniques

(or put simply at the end of the day you will know some of the basics, but that’s about it)

Setup

in order to complete the day you will need to download and install some tools. specifically you will need a Testing Framework and a mocking framework.

Testing framework

any framework will do, really its not that important at this stage.

• .NET use MsTest or NUnit
• Java – JUnit
• c++ – GoogleTest

Mocking framework

pick one of the power tools available:

• .NET use Typemock Isolator or JustMock
• Java – PowerMock (you’ll need either EasyMock or Mockito in addition)
• c++ – Isolator++

(some of the tools are commercial so you will need to use their trial edition which is good for a few weeks)

Learning phase

The first step is to get a basic understanding of the principles involved. for this I would recommend the following session by Uncle Bob
Attempting as it might be don’t skip this part. It takes about an hour, but the important basics are in this. In order to succeed one must know what are the rules of the game and what are the expectations. doing TDD is not just about writing tests, its about how to write code differently. And the goal is to try this different way, not just write tests.

Do a Code Kata

pick a kata from the following page, any kata will do but I would recommend going with one of the katas in the Beginner++ section.
your goal in this step is to practice TDD on the kata.
that is apply the basic rules of TDD while trying to tackle a relatively simple problem.
I would expect you to be able to go through the kata (mostly) in under an hour

Learn Isolation Principles

The next step is to get familiar with your mocking framework of choice. Most likely, the easiest way to do it would be to go the the relevant tool website and get through the “getting started” or the “Introduction” parts. The goal is to understand what are mocking framework, what they are used for, and specifically learn the API of the tools and be able to use it.
If you want to invest a little more time and learn some of the theory behind this, here’s a very nice session (hour and a half) by J.B. Rainsberger which I personally like very much.
you should end this part by doing the following:

1. Create a new project.
2. To this project add 2 classes one that you want to test (Class A) and one which is used by Class A (Class B)
3. Add a method that just throw an exception to class B and make Class A invoke that method somewhere.
4. Next write a unit test which test Class A, specifically the part should activate the code in A that invokes the prepared method on class B.
5. Use the mocking framework in order to make this unit test work/pass.

Yes this is a very simple exercise, but in order to finish it you will need to pass through all the basic steps for using the mocking framework tool.

Take a break for lunch

Tackling the real system

The last part of the day is dedicated to write some unit test on your real life system. What we want to achieve is to actually write some tests on the real system that you actually works on.
The first step is to pick a place in the system to start in. The trick here is to chose an good part that on one hand wouldn’t be the hardest most complex part, but on the other hand still would surface the real issue that will be encountered later on. The ideal place should be a place that is focused on logic. Try not to go for upper part containing any GUI sections, and also try to avoid the lowest parts dealing with the data base (if there is one). If possible try to pick a class that reside somewhere in the middle tiers. hopefully somewhere inside the business logic.
After you picked your part, locate the class you actually want to write test for. When you have it, the first step is to locate the dependencies of the class you will need to handle. Start by writing those down on a piece of paper, and then dedicate some time to figure out how they are going to be isolated. Usually what helps is answering the following questions:

1. How are the dependent instances (the one used by the class under test) get created
2. How are they get “connected” (injected)into the class under test
3. what is the expected behavior you need in your tests

answering these question will help you later on in setting up the fakes (mocks) in your test.

Write some tests

next just write a couple of things you would like to test. The key here to start simple. think of a specific behaviors you want to test. for each behavior, think what is the initial state the test should start at, what is the action you want to test, and what is the expected behavior (result) of that action (and how you clean up after the test). When you have all those just try to write the test.
And always remember to have patient.
The first test in a new system is always the hardest to write. Even an experienced TDD’er is likely to take a couple of hours to actually get some tests on a new system. For a beginner it might take longer.

Summarize the day

Last action of the day is to think and reflect on the experiment. if you followed the steps, then you should have some tests on your real system. Now it is time to reflect on those and see what else you can learn. Think on all the things you accomplished during the day. Chart down the things that you need to invest more time in. Recap the main difficulties you encountered, and most important decide upon a few key actions you would like to take in order to continue your learning.
And of course let me know how it went.


Update
It seems that the kata site went permanently down so here some links to some code katas sites:

1. http://codekata.pragprog.com/
2. http://www.codekatas.org/
3. http://katas.softwarecraftsmanship.org/
4. http://content.codersdojo.org/code-kata-catalogue/

Read more »

Posted in: Agile practices,Development Practices,Self Improvment,TDD,tips

Moving from Fix price to Agile Contracts

One of the major roadblocks in an agile transition is the fact that when adopting an agile approach fixed price, fixed content contract does not make much sense anymore.

sure, some organizations are succeeding in doing agile under such contracts but one of the promises of Scrum is to be able to easily cope with changing requirements, and change the work plan to contain the most valuable features seen at that time.

On the other side, after so many years working under fixed price,fixed content contract its really hard to change especially since much of the time the other side (the one paying) is not really involved in the decision to adopt agile.

Its all about risk

a couple of weeks ago I had the chance to talk Giora Morein during a conference, after a while we started talking pricing schemes at which point Giora pointed out that when working under a fixed price contract, the risk involved is mostly placed on the side providing the services, while when using an hourly/daily rate most of the risk is taken by the paying side.

I believe that this fact is part of the problem we face when trying to adopt to an agile contract. The problem is how to convince a customer that is used to having the risk placed at the supplier to accept the risks involved in committing to a project under a flexible budget and content.

Moving Into an agile Contract

The first thing I found useful when I try to switch to a flexible more agile contract, is to start by acknowledging this fact. I than counter to with the benefits of such a move, focusing on the benefits the client will see.

In many cases this is not enough and the customer will still choose to use the same fixed price, fixed content agreement and in this situation I found the following steps to be very useful to establish a level of trust needed to actually change the working contract.

In order to actually change anything the first order of business is to sort all requested features by order of importance. In most cases this is grasped by the client as a reasonable request and it opens several channels of communication whiled doing so. its very important that the client will be involved in this as much as we can since this phase build the basic understanding both parties can build upon later on.

Second I try to add the following key points to the contract

(since all this points are actually controlled by the client most have no real objection to include them in the agreement):

1) Scope can be changed - The client can swap any requirement/feature by a new one of similar size, as long as it conforms to the basic priority scheme.

2) Priorities can change - by the client at any point of time. These changes will be reflected to the work plan (excluding things which are currently under way).

3) The client can take a working version of the work so far. In fact he is encouraged to do so and provide any feedback he can n it.

4) Termination - at any point of time (subject to a reasonable fee – I use 25-30% of the remaining cost) the client can terminate the project taking all the work done so far.

I have tried this scheme on a couple of occasions and found that after a few times the client actually invoke any of this clauses. He usually see the benefits involved in such an agreement and the next time he actually insist on this ability and is much more open to a working under an “agile contract”.

Read more »

Posted in: Agile practices,Scrum

Starting TDD – Conclusion

How do I start TDD? is a question I’ve been asked too many times. Unlike many I don’t believe that in order to start you need the entire team approval. In this series I’ve described a few situation one might find himself in and offered some ideas on how to approach them. Although each developer has its own context i hope you can find some resemblance in the described cases and find the ideas useful. Since this is what I’m doing for a living this days, I would love to hear about your way on the TDD road and specifically on how you started and what were the initial experience.

last in a previous post i was asked by Daniel the following:

So if a single developer on a team is driving the design of his code by TDD, do you really think it would work? The code is probably going to be different in design hence other will probably have problems reading it since it could be a bit of paradigm shift. Also, if the TDD-developer has a similar skill-level as the rest of the members, the implementation time of each future will probably be longer for his items, even if the total time including corrections after QA-people, do you really think things like this will go unnoticed?

Daniel, I don’t know if it will work for you, but i have seen it to work several times. The differences in designs does tend to invoke a design discussion, which i have found to be a good discussion in which testable design is always defendable,in fact I encourage this discussion since they are a tool for winning people over. regarding your second question, I think that a reasonable developer (in many scenarios) can make the overhead nearly unseen, and i would also expect that it wont take too long for that developer skills to rise over his fellows programmers. However, I’m a believer of honesty and visibility, I wouldn’t try to hide what I was doing from anyone, and when challenged I would answer that this is the way i know how to code and point to the low defect rate resulting from doing things this way.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 6)

if you are really lucky you will find yourself joining an team which already practice TDD:

New developer joining a team doing TDD

You are just starting a new job (maybe in a new company). You have heard all about how the team is doing Agile (Scrum/XP) and how the tests are written before the code (TDD). In fact you are nervously waiting to start doing all those wonderful things.

Take a breath.

Joining such a team is not an easy switch. If this is your first time doing TDD (and Agile). It is going to be kind of a shock, working in an agile team is different in many aspects TDD is just one of them. It can take some time to make the needed adjustment. I myself have not fully experienced this, but helping other pass through the transition, I have learned that it can be a frustrating process, especially if you not a new developer.

The best way to speed the process is to make sure to pair a lot, i.e., Don’t work alone! Always ask to work along with somebody else on the team. Even if the team is not practicing pair programming on a usual base, insist that for your initial phases you would like to sit with others and learn how to do things properly. Pairing is a great way to get the needed knowledge and expertise (and the fastest way I know of).

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 5)

With some luck, one day, the place you are working in will decide it want to fully adopt TDD. On that day you might find yourself in the following scenario:

A lone developer in charge of implementing TDD

The team/ manager have considered TDD, they chose to evaluate it and decided that its a good idea. the decision as made and in fact most of the team is quite happy with the change. However, since its a busy time they want to approach the subject with some care and have chosen you to start the ball rolling. that is you are expected to lead the transition for your team first by doing it yourself and then by helping the rest adopt the methodology.

The steps in this scenario are very similar to the one described in Part 4 the focus however is to gather as much real hands experience the fastest way possible.

Sometime this kind of experience can be bought. If possible, bring in an outside consultant that will help you in the transition. If not, try to to make sure the next hire has hands on experience.

if this options are not present, arrange for the whole team to attend some relevant gathering/conventions. Go with the team to TDD courses. and in any-case, when following the steps described in part 4 make sure to share and include other team members in the process. And last practice a lot of pair programming TDD session.

remember the idea is to share and include the rest of the teams even if they are not actively practicing TDD yet. A successful TDD adoption is much a matter of mode and spirit, not only a technical problem.

But always remember, The key factor is to gather as much hands on experience as possible and having the patience to build upon such expereince.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 4)

In some cases the idea of TDD is seen as a promising idea by the organization. lets consider the following

A Lone Developer in charge of evaluating TDD

You talked with your manager and thinks TDD might be a very good idea. in fact he has given you a green light to evaluate the approach. most likely other team members are also in favor of checking this out all are waiting for your conclusions.

In this context the plan of action is very similar to the previous scenario. The difference here is that you are expected to do a more thorough job, and you are expected to show result in a given timeframe.

Therefore, you still need to pass the learning phase, you also need to setup a CI Server and pick out the tools before starting. Time boxing the learning phase will be a good idea, while you still need to gain the knowledge you would like to do it as fast as possible, so pick the training solution that work fastest for you (for many a TDD course does a decent job in a short timeframe). On the other side you would like to invest more time in comparing and evaluating several options for your tool set (which include the CI product). at the end you will be find it easier to justify your choices if you can show that alternatives were considered.

Next step, is picking out a good place to start the actual writing. Since you are evaluating the approach, you probably have the option of picking out where you want to start, and the idea is to pick (for the first experiments) a place that you feel comfortable working on. a Place which will not be too hard. Try locating a small, decoupled section that is logic oriented. At this stage don’t try to tackle the most difficult place, there will be time for that as well. First gain some hands on experience with TDD.

Like initial stages, you would like to time box this first effort. When you finish it don’t forget to share your finding (and your difficulties). sharing along the way will help you when you finish the evaluation and a decision will need to be made.

According to the time allocated, you might have a chance to tackle a “tougher” piece with unit tests. If you are working on a legacy system now will be a good idea to approach the issues such a system present. You will need to gain more knowledge on refactoring and reading Michael Feathers book is also a very good idea at this point. Going through legacy code is harder and takes time. The trick to success with TDD is to have plenty of patience, this will become evident when working on legacy code. Getting help is also a good idea. If possible try using other team members via pairing sessions. Paring on the harder challenges is a great experience by itself and will also make the time for resolving the issues shorter. As a side effect you also introduce TDD to other in your team.

at the end always remember that you have a specific goal, to understand why TDD will be good for you and your team. And to show how it can be adopted by the rest of the team. So don’t wait for the time to end always remember to reflect on what the experience has thought you what were the benefits and what are the challenges. during the evaluation communicate with the rest of the team and draw them into the discussion. at the end you will probably need their weight to make the organization commit to TDD.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 3)

In the previous post I’ve talked how a even in the most hostile environment one can do things that will help on the road for becoming a better programmer. fortunately however the scenario described in the previous post is quite rare and in most cases things are not as bad.

The following is probably a more reasonable scenario

A lone Developer in an indifferent organization

You discussed TDD with your boss and while he is not against it, he doesn’t see enough value in it . Most likely his reaction went along the lines of:

Yes, automated unit tests are great but …

On the other side, you generally get enough freedom as long as you get the job done. other team members also think TDD an interesting concept, but again no one has yet made any move.

Start Learning

If you find yourself in this situation (which I believe is quite common), there’s much you can do. As always you start out by learning. Books, blogs, lectures, videos,.. anything will do. There is even a slight chance you can persuade your company to spend some money and sent you to an actual TDD course.

Setting up a CI server

Next step is setting up of a Continuous Integration server. Yes, I’m serious. If you are going to practice TDD, you should have a full blown CI server at your disposal. Setting one up takes somewhere between 30 minutes to a few hours. The benefits are huge, and down the line it will definitely help you convince others (most managers just love the visibility given by a CI server)

BTW You don’t need a dedicated machine for this. If you can’t locate a spare machine (and any machine will do) just set it up on your own personal development station.

Picking out the toolset

Next step will be to pick up the actual toolset for TDD. the most important thing about it is not to let this slow you done. While there are several options out there for every technology, for the most part the differences between the tools will have no affect at this point. Later on you might want to change the tools but even if that happens the actual cost of switching is usually minimal, and you will have much better understanding then. Just pick the tools you feel will be the fastest to learn. Don’t let the tools get in the way.

Practice TDD.

Now comes the fun part. Just start doing TDD. Pick up you next programming task and allocate some time for doing it the TDD way. If possible try to pick a standalone piece of code if not never mind. Don’t worry about doing mistakes. Don’t worry if your tests doesn’t seem like unit tests at all, and don’t worry if your are not following the TDD rules by the letter. You are just learning. And remember, in most cases it can take a couple of hours, maybe even half a day to write the first test. Things will become easier as you gather more practice.

You are not alone

Starting out TDD is hard. Without help it’s even harder. The fact that you are alone in your organization doing TDD doesn’t mean you shouldn’t have any. Reach out to the mailing lists. Luckily The web is filled with very nice people which likes to help. It might take some time but you will get the answers you need. The real trick for succeeding in TDD is just to have patience. It take some time to master a new skill.

Share you accomplishment

Hopefully after a few weeks/months you will be able to demonstrate the real benefits of TDD. If you stick to doing it, you will overcome the initial issues and will prepare the ground for the team to follow. You will have real experience, and it will be much easier to convince others of the value in TDD.

But even if not, if you got to this point you already are a better programmer.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (Part 2)

In my previous post I explained that you don’t need the entire team in order to start TDD. So lets see some options for the lone programmer.

The question of where to start depends upon the context you find yourself in. For example lets consider the following:

A lone programmer in a hostile organization

You are a team member (or a team lead), you tried running TDD through the team but they feel its stupid, in fact they are strongly against it. If that’s not enough your manager also think TDD is a total waste of time and is closely monitoring to make sure you are focusing on writing production code only. And the worst thing is that the organization is a strict one, no tool can be used without going through the proper channels.

Yes this is as worst as it can get and there is not much you can do (other then maybe start refreshing your CV). But still you can start with the learning parts. TDD takes some knowledge to do properly, its not enough to just decide and jump ahead. there are practices to follow tools to be learned and techniques to be adopted. I have never encountered an organization that will block a determined programmer from acquiring knowledge, even if that knowledge is not directly related to current work.

Here are some places when TDD knowledge can be gathered:

Books:

1. The Art Of Unit Testing - Roy Osherove.
2. Test Driven Development: By Example – Kent Beck.
3. Working Effectively with Legacy Code – Michael Feathers.
4. Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin.

Mailing Lists:

1. TDD on Yahoo Groups
2. Extreme Programming on yahoo

Also there are numerous conventions and blogs dealing with TDD and other Agile Aspects. which deals with various aspects of agile development and some are even more specific to talking and helping with Conventions (and recording of)

It might also be a good idea to refresh on proper design principle and refactoring techniques as well. Even if you wont be able to practice TDD writing clean properly design code is always a good idea and i have yet to meet someone which object to that.

Read more »

Posted in: Agile practices,Development Practices,TDD

Starting TDD (part 1)

One of the most common question I encounter is how to start with TDD. Usually the questions is formed as how do I get my team to pick up TDD.

There are many answers to this, and in fact it really depends on the specific context (more on this later) but one thing I do know.

You don’t need the entire team

A popular mistake is to think that a lone developer can’t do TDD and you need entire team do it together. This contradict the fact that TDD is a solitary practice i.e. you can do it all by yourself. Think about it, don’t you write code alone? TDD is a development methodology, its an exercise in producing high quality code, in that aspect its not different then doing low level design or writing clean code.

Do you need the rest of your team to design properly in order to produce good design (of your parts)?

Naturally the effect a single developer has is limited and will probably won’t go beyond his code, however doing TDD even if done alone will allow for his code to be better (and most likely faster). Of course its better to have the entire team do TDD. It’s usually easier and will increase quality of the entire product, but there is no reason to wait for everyone to realize that, is there?

So where to we start?

like always the answer is, “It depends…"

but more on this later

Read more »

Posted in: Agile practices,Development Practices,TDD

Gathering worthwhile feedback

Tobias Mayer has got me (and I guess several other) thinking about the common feedback process used by trainers. While I think that there's much to learn from the general purpose form handed out at the end of a training, clearly doing it only at the end of a training session means you cant use it for improving during a lengthy course.

Therefore I use two different techniques for gathering feedback during a course

Course Retrospect

this is actually quite simple and effective technique, towards the end of the second day. usually after I cover the sprint retrospect meeting. I conduct a short "retrospect" meeting with the aim of improving the actual course. My current favorite way is borrowed from Alistair Cockburn and we try to list out (together in an open discussion) the things which are:

1. Going good for us so far,
2. causing issues and difficulties,
3. and things that we want to try to do different on the next day.

That way not only do I gather feedback that I can use to improve on, we also get the chance to practice and witness the power of Sprint retrospect meetings.

Guided Questions

The second technique I'm using was inspired by Roy Osherove, and its a little more subtle. The basic idea is to ask a few (usually 2) open ended questions regarding the passing day. For a concrete example read these 3 posts: day 1, day 2 & day 3.

And this works really well. First, asking these question at the end of the day makes people go over and reflect on what they have learnt during the day. It take 5-10 minutes in which I see them going through the written material trying to fish out an answer. Just for doing this I think its a great practice. Second, I really learn a lot about how they grasp Scrum, what are the main difficulties, what is seen as beneficial, what they think will be easy and so on. And last in most cases the answers show me how well I did as a trainer. For example on the first day I got an answer saying that "Documentation is not needed." That was not the idea I was trying to convey (In fact I clearly specified that "its not that documents are not needed...." at least twice) therefore I need to improve on that (clearing that point again on the following day).

Both technique are simple, quite fast (takes between 5-15 minutes) and results in good feedback. combining them with the general purpose feedback form really works great for me so far.

Read more »

Posted in: Agile practices,Course,Feedback,tips,tools

Iteration Zero – using Testify

One approach when starting out a new project is to dedicate the first sprint/iteration in order to build in the framework for the development process. that is building in all the stuff which will be required during the time life of the product. things life setting up the build server, preparing the installer establishing the framework for unit and acceptance testing. in short all the technical details an agile development environment expect to just be there.

Today I managed to go into Mike Scott session in which he demonstrated his very nice tool called “Testify”.

I don't want to go into all the details since it appears that just today Mike has finished to ‘open source’ the tool. (can be found here). I would however say that during the short time in the session (about an hour), Mike has managed to create a new project which contained :

1. Some source.
2. Executable Unit tests (using NUnit)
3. Executable Acceptance tests – using fit
4. Setup a source control repository (Subversion based)
5. and Setup a continuous build server (using CC.Net)

Since I have done this kind of things a couple of times. i was really really impressed.

Read more »

Posted in: Agile practices,Conferences,TDD,tools

Myth Busted - NOT

In a recent post Scott Ambler starts by claiming

Agile Myth:High Quality Costs Less than Low Quality - Busted! (at scale)

later on when reading the actual content Ive learnt that he refers to very specific cases :

For example, in situations where the regulatory compliance
scaling factor is applicable, particularly regulations around protecting human life (i.e. the FDA's CFR 21 Part 11), you find that some of the URPS requirements require a greater investment in quality which can increase overall development cost and time.

and

This is particularly true when you need to start meeting 4-nines requirements (i.e. the system needs to be available 99.99% of the time) let alone 5-nines requirements or more. The cost of thorough testing and inspection can rise substantially in these sorts of situations.

In my opinion he went a little off charts with his claim.

First is the exact "Myth" so to speak? Is it a simple "High quality cost less"?

Well actually its a little more subtle than that. What the agile community has found once and again (as Scott mentions) is that it cost less to work in high quality mode, when you need to reach and sustain acceptable quality. After all quality is infectious. In general it cost less to produce crappy systems, but mostly those just fails when quality needs catch up.

But back to the examples.

I don't have experience with life critical systems. However, is there a possibility that what actually cost are the regulations themselves and not the underlying quality? Is there a way to reach the necessary life safety quality without following those costly regulations (at lower costs)? I don't know, I do know is that the FDA regulations are costly to implement and originate in a time before the Agile paradigm shift.

High Available (HA) system, on the other hand, I do understand. In fact I was in charge of developing a HA solution for a big billing company. And here Scott argument falls short.

Reaching 4 and especially 5-nines has nothing to do with the quality of the developed system. In order to get to that level of availability you must have an integrated solution and there lies the cost of 5nine systems.

So what myth has been busted?

Yes there are cases in which a specific aspects of quality will drive costs up. But taking a very specific examples and generalizing it to "Busted (at scale)" that an obvious Mistake in my book.

Read more »

Posted in: Agile practices,Engineering Practices,Quality