Working With Suppliers

Working with suppliers can be daunting. In one project however, we applied agile principles and achieved very good results.

Initially we discussed a traditional contract but in the course of the talks it turned out that all participants wanted to have something more flexible. So we put only the basics into the contract, e.g. rates, time frame, responsibilities, etc. With regards to the scope we only roughly described the subject but left the rest open. Principally the contract was time and material based, so admittedly required some basic trust.

Architecturally we were in the fortunate position that what the supplier was to implement could be "isolated" in a separate module with a clearly defined interface. So, we created the interfaces definition which was ultimately a source file plus a set of automated tests against those interfaces. Then the supplier knew exactly what was needed. If all tests pass he would know that he was finished.

If we would find that something didn't work as expected we would then augment the test suite and send it back to the supplier. He would then come back with an estimate of the cost and we would then decide whether we wanted it for that price. In some cases we negotiated, e.g. by asking what it would take to reduce the price, e.g. by slightly modifying the requirements (automated tests and/or interfaces).

Collaboration was improved by sending one of our engineers to the supplier once in a while and viceaversa. This, too, improved trust and communication and working together was much smoother.

Overall, we worked with that supplier for more than 2 years and the results were excellent. Trust was substantially improved and a required ingredient for the success. So in this particular instance, working with a supplier was almost as working with a different department in the same company.

Dealing With Uncertainty in Stories

Extreme Programming uses stories to define the scope of a system. Sometimes teams have difficulties to estimate the size of stories with a satisfying accuracy. Different approaches to address this issue are possible, e.g. making stories even smaller.

Another approach is to look for the elements in a story that represent the risk. Then these elements can be addressed in a time-boxed spike (or experiment). The remainder stays thus becomes a low risk story.

Risky elements may be new technologies that need to be tried first, or a cool new user interface widget. An example of the later could mean that you might want to implement a simple (maybe even un-cool) version of the interface first. And separately you play the story with the spike for the cool widget. That way you deliver value while at the same time pushing the envelope in a time-boxed fashion. If the outcome of the spike is good then you can play a third story to improve the user interface.

With this approach I have seen different teams addressing risk, and at the same time improve their estimation skills. There are certainly more techniques. If you know of another simple way to deal with this I would be interested to hear from you.

Cards Or Planning Tools?

In one of the newsgroups I monitor there was recently a discussion on Project Planning and Tracking Tools. I'd like to add another experience to this.

In a project for which I started coaching earlier last year, I introduced index cards for stories initially. People looked at it as something very "unprofessional". Paper and pen? How could that possibly work?

Well after a while the team decided that they wanted to introduce XPlanner. After yet a while some customers on the team decided that they were not exactly getting what they were asking for. As a consequence they started to put more details into the tool. Sometimes there were a lot of details even for how to lay out widgets on a screen and what colors to use. Screenshots of mock-ups were eventually added.

Yet another while later the team discovered that this didn't really help. Now the stories were very big and therefore hard to put into a short iteration. And the bigger they were the higher the likelyhood that they were underestimated. An extreme case was a story that was estimated at 47 units but which took 228 units in the end to implement. It actually consisted of a sequence of four stories.

It was clear to them that they had a problem. Now they have reverted back to using index cards. Writing or even drawing on an index card limits the amount of information you put on it. The team decided that the best and most important information on a card was the business value that the completed story tries to provide.

Having less details on the cards themselves has triggered more and better conversations or negotiations between the customer and the engineers. More options are discussed and it is much easier to move storie around. Estimation is better, and the geam gained more flexibility with regards to how to implement a story.

Bottom line: You might have an excellent justification to introduce a software based planning and tracking tool. But sometimes it is better to just go using simpler tools. If your team is co-located you certainly have more options, but even for distributed teams it is worthwhile to look for alternatives. Simple tools may lead to simpler and better solutions.

Question from Java Certification Test

I found this question at www.javaprepare.com.

Which of these is a correct fragment within the web-app element of deployment descriptor. Select the one correct answer.

1. <exception> <exception-type> mypackage.MyException</exception-type> <location> /error.jsp</location> </exception>
2. <error-page> <exception-type> mypackage.MyException</exception-type> <location> /error.jsp</location> </error-page>
3. <error-page> <exception> mypackage.MyException </exception-type> <location> /error.jsp </location> </error-page>
4. <error-page> <exception-type> mypackage.MyException</exception-type> </error-page>
5. <error-page> <servlet-name> myservlet</servlet-name> <exception-type> mypackage.MyException</exception-type> </error-page>
6. <exception> <servlet-name> myservlet</servlet-name> <exception-type> mypackage.MyException</exception-type> </exception>

Does this ask for the abilities for writing correct XML files, or does it ask for whether someone understands how to specify an error page in the deployment descriptor (web.xml) of a Java web application.

I think this confirms my concern that someone who is "certified" does not necessarily have to be an expert on the subject he/she has been certified.

My suggestion to an agile leader is therefore: Ignore the certifications and focus on the real output of your candidates. Use auditions, for example design sessions or pair programming, to assess the real skills of your candidates.

I don't believe that certifications will help you to determine whether a candidate has excellent social skills. And I also don't believe that this kind of questions helps to determine whether a candidate is able to find novel solutions.

At best the candidate can repeat previously learned canned answers. Is this what you are looking for?

Quote From Today's Scrum

I thought you'd like the following quote from a daily Scrum I attended today:

"If you click the add or delete button in a table, and nothing happens, something is wrong." (Author to remain unknown)

Two Hour Technical Task Too Much?

Our recruitment process includes a programming task, which we give candidates as a preparation for the first one hour interview. The task is typically very simple and it is possible to complete it within roughly two hours. The intention is to assess whether a candidate is a) able to solve a simple task independently, b) able to demonstrate know of how to ensure quality (e.g. automated tests), and c) willing to invest that time for joining a team of highly skilled people.

In over 100 applications in the recent months we have never had any complaint by the candidates. Instead we see good results with regards to the performance of the successful candidates.

However, there was one case where a candidate sent an almost "rude" response after he received the programming task:

"IMHO only a fool will spend 2 hours sitting for a technical test without the employer having gone through some trouble to have a pre-selection round first."

And later he added

"I happen to be not only adept on the technical front, but also socially observant and capable of making (mostly correct) strategic decision."

Do we expect too much? I know of several other companies who use technical tasks for engineering positions as well, for example ThoughtWorks.

In this particular case we decided to not invite the candidate based on him not being willing to comply with some simple rules which are part of the policy of our company.

I wonder who else is using technical tasks as part of the recruitment process. It would be great if you would be willing to share your experiences.

Customers Writing Executable Specifications

About two years ago I worked with a team which had to live (or suffer?) from requirements specifications with hundreds of pages of prose. This kind of document is hard to read, understand, and maintain. If you want to change it, and your customer is external, you have to follow a change management process which typically includes exchanging and having drafted and approved even more documents.

Ideally, requirements would be written in a way that makes it easy for the development team to verify whether the system satisfies them. So why not making requirements executable? That way your team members can run them as often as needed, and they could stop immediately once the system passes those tests.

The way to go forward is therefore executable specifications, or story tests. The most prominent thought leader on this is probably Rick Mugridge, on whose web site you can also find further information.

One tool to create and maintain such customer tests is Fitnesse. It is available for many different languages.

The benefits are very compelling. You have a much tighter link between your customer (might also be a product manager) and your development team. Executable specifications are a means for improving communication. You also get a tool that reduces the gap between what your customer wants the system to do, and what the system really does.

From my experience, it's worth playing with this concept. It might turn out to be an excellent addition to your toolbox for agile project management.