In his talk at the Agile2008, Bob Martin proposed an addition to the Agile Manifesto:

Craftsmanship over Crap.

Although most of us can identify with that statement, it’s probably not easy to sell the idea put that way. But now he rephrased it to:

Craftsmanship over Execution.

I confess the first time a thought about software development being a craft was in a Joel Spolsky’s article disagreeing with the use of this term. In the post he suggests creating software is more related to design than craftsmanship, but he reinforces the idea of software not being simple execution.

After working with a lot of different people, it’s easy to distinguish who think about software as being craftsmanship or mere execution. And undoubtedly the best developers and consequently the best software always come from the first category. They care about what they’re producing, are passionate about it and never stop learning. They want to become master craftsmen and know it depends only on his own attitude.

The question is: should the Agile manifesto include that statement? Personally I don’t believe so. The “Individual and Interaction over processes and tools” part already implies that. Focus more in processes and you’ll end up caring more about execution. Value people and the craftsmanship aspect of building software will become natural.

1. Is the easiest and cheapest way to invest in training

To run a coding dojo people don’t need much more than a computer and a projector. Paying for the pizza and some beers for the end of the meetings is not expensive either, and is surely welcome. But if the company is really cool, some dojos can take place during work time to get more developers involved. Note that none of those items take lots of money nor is too complicated. The only things needed are some engaged developers and good sense of the company to invest in their professionals.

2. Stimulates social and self-organization skills

Many developers have some hard time when talking in public, exposing their ideas or collaborate with other people. Others have problems to self-organize, work in a team or even lead. When does a company invest on those kind of skills of a developer? Rarely. The dojo is a great start for those people, and even who doesn’t have any of these difficulties will have a chance to exercise their skills and explore points which may need some improvement.

3. Is good publicity for the company

If the company took the first step and the developers are already comfortable running a dojo, why not open the doors for the public? The company name will become associated with the agile principles behind the the coding dojo and developers won’t have to leave the company to network. Better, if everything goes well the company won’t have to publish ads to get new developers since the potential candidates will be part of the company’s routine.

4. Helps developers to be active in the community

Discussing the techniques applied in the dojos can be a good incentive for some developers to participate more in the software development community. It can also be a first step help some open source projects, publish articles or participate in conferences.

5. Breaks the routine

Code something different from the daily projects, using other languages, tools and techniques, with other people and in a more relaxed environment may be very stimulating.

So, do you need more reasons?

Three simple steps to measure velocity in a software project:

• Estimate your requirements using a size metric.
• Agree on the concept of done.
• Define a timebox size.

Then we just need the formula:

Velocity = Points done / Timebox

Sometimes in a project:

• People are treated as mere “resources”, being part of the project only to work on predefined activities and nothing else.
• The managers want to be sure that everyone is doing exactly what they think it’s the best, and forget that people can have good ideas.
• People prefer to work on tasks defined by someone else because they don’t want to be responsible for their work.

Having self managed teams is a good way to change this reality but to make people capable of managing their own work is a tricky task. With that in mind, the principles I consider most important to achieve it are:

1) Shared vision

The first step to build a self managed team is sharing the project goals. A good start is to define SMART (Specific, Measurable, Achiveable, Realistic, Timed) goals and to make sure that the goals make sense for the whole team.

2) Commitment

Once the vision is clear, the next step is to build the commitment. When the members of the team agree to work to achieve the defined goals, the perception of the their actions changes and they start thinking about the best solutions to get closer to the goals.

3) Trust

If people trust each other, a bond is created and there’s no reason to control other people’s work. On the contrary, people start helping each other.

4) Support

Every self managed team needs an “interface” with the rest of the organization. That’s why one or more people should be able to help when the solution to a problem depends on external factors. These people should be considered part of the team since they share the vision, are committed and trust the other members of the team.

Conclusion

Although these principles look very simple, they’re forgotten all the time. And they’re usually replaced by micromanagement, which on top of wasting people’s time frequently becomes the biggest cause of stress to the team.

After taking the Asshole Test, now is time to know about the Asshole Driven Development and other “alternative” methodologies

PS: see all the comments about the Scott Berkun’s post. There’s a lot of new acronyms there too.

For the last year I’ve been involved with the organization of Coding Dojo meetings in Florianopolis/Brazil. This kind of “coding meetings” started in France and spread to Finland, United States (Pittsburgh and Houston), United Kingdom, Canada, Brazil and Sweden.

The sessions are basically about solving a programming challenges using Pair Programming and Test-Driven Development. Everyone is welcome since there’s no skill prerequisites for attendees. The main goal is simple: improve coding skills through practice.

Apparently today when it comes to Agile, there’s a huge gap between the software Industry and Academia. I thought it was just in Brazil, but it seems that there’s too much students out there finishing their degrees without even heard about it. Well, the Coding Dojo doesn’t fill this gap, but it seems to be right at the middle: it’s a simple way to learn about some agile concepts and it can benefit both Industry and Academia.

Today I’m not living in Florianopolis anymore but I’m helping my friends there to keep the sessions running. New people are asking me about the next meetings and in the last weeks I heard about at least more 2 possible Dojos (one more in France and other in Sweden). I think it’s just the beginning for the Coding Dojo Global.

The first agile principle is about “individuals and interactions over processes and tools”. How can it be managed when people are not all in the same place?

Dave Churchville wrote about it and classified distributed team as:

1. Type A: All developers are together, all customers are remote
2. Type B: Multiple development teams in different locations (but each team is together)
3. Type C: “Virtual” team where nearly everyone works remotely (e.g. from home, in various offices, etc.)

I’ve been working in the last years mostly with Type A and Type C teams, and I believe the main goal in these cases should be improving the communication channels between people to be as effective as if everyone was in the same room. Long story short, this isn’t possible, but we can still make it work.

For remote costumers, the first challenge is having they available to talk with the development team. It can be painful at the beginning because “build software” normally is not their priority, but as long as they realize how their contribution is important to get the best results, they will probably change. And in this case, cellphone, skype, IM or even e-mail will become very important for their collaboration, and both costumer and team should not underrate these communication tools.

Here’s some tips to work with remote costumer:

• Try to build commitment since the first day.
• Ask for their oppinion during the development and show how their collaboration affect the results.
• Define open communication channels. Give preference for phone calls and instant message over e-mail.

The “virtual” team is an extension of the previous scenario, and beside there’s less people together, it can be surpassed easier if the team already realize how communication is important in an agile project. That’s because in this case the communication channels are already open. They can use Skype/IM/e-mail to talk to each other, and even VNC to share their desktops during coding sessions.

This means that if there’s lack of communication among team members, the challenges will be similar to the faced with the costumer. And probably the approaches to fix it will be similar.

Software contracts that define all software requirements up-front make your project half-way to failure. The software company will try to do exactly what is in it, and the client will try to believe that none of those requirements will change. And at certain part of the project both will realize they were wrong.

Let’s face it. Software requirements always change. But it doesn’t mean that people got they wrong, it means that after seeing a piece of working software people learn more about it and they will always have a lot of new ideas to improve it.

Let’s see how could we change this situation:

Don’t define requirements in the contract. Well, this sounds obvious, but the problem is that people most of the time confuse software scope with project scope. The project must define clear vision of the goals to achieve, but should let the software change during this period to get to these goals faster.
Define an initial cost and time. Once you have no requirements in your contract, people can argue that you can’t define the project cost and time. That’s wrong too. Even with requirements in your contract, project cost and time are just estimates. So, to create those estimates you can think about requirements (the MoSCoW or the Joelonsoftware technique should help), and you can even keep these written items as initial ideas, but they really should not be written in the contract.
Build the software in short cycles where working software has to be produced. And define that requirements can be changed and the development velocity can be evaluated between those cycles. This way it’s possible to guarantee that changes will not scare the development team and the client will be able to check the team productivity. By the way, that’s other myth about scope-flexible contracts, that people will work less if they don’t have the requirements defined up-front. But this way of thinking ignores the fact that the software company should have interest in get the software done as fast as possible. After all, it’s a way to impress the client and get more contracts.
(Bonus) Create a much smaller contract first. If the contractor could not be convinced that this type of contract is better, propose a smaller one (one month, for example). If after this contract he’s still not convinced, everybody will be able to evaluate the risks and try to come up with another idea.

See, all those items are not too complicated. And if you ever experienced the stress that a traditional software contract can cause, you should really think about adopting a more flexible one.

Today a lot of people wants to become agile. Well, not agile in the sense of mentally or physically quick, but Agile (yes, with capital “A”) as written in the Agile Manifesto. Why? Because it seems like a better way of doing things. This way involves:

• Empower people
• Deliver business value
• Get the client involved
• Embrace changes

Is the word “agile” good enough to represent all this? I don’t know. And to be honest, I think we really shouldn’t care. As long as people get what it stands for, the word “agile” is getting the job done.