Don't Protect Your Team!

I was involved in a project which had not gone as smooth as we'd hoped. By the end of the project we had a chat about tying up the pieces, so I asked the project manager how she felt we could do better next time. I explained that looking back at the project to see what we can do better next time is a way to avoid repeating the same mistakes again.

One problem with this project was that the team had to work extra to correct and implement things too late in the project time frame. The reason was poor planning, which in turn was a natural consequence of the team not having enough information available. It's worth noting that there had been enough time for them to do everything, but they thought they were finished and had started to work on other things.

Why did that happen? Well, it turned out the developers had no contact with the customer and was left in a vacuum once the initial sale was completed. Promises where made and then shifted over to the team to "make it happen". The customer had absolutely no idea who was on the team, and the team had no idea who the customer was (apart from the company name). Not a single time during the project did any of the team members talk to the customer.

I asked why the developers were kept out out the loop like that. The response I got from the project manager was that "shielding the team from the customer is a way to save them from having the customer calling all the time and disrupting their work". In other words, don't give them your phone number.

It turned out the project manager had been in a situation once where one customer had been a real pain, constantly disturbing the team. This can happen in a maintenance/support situation, but it was not an issue in this case. I said that I thought the developers were professional enough to deal with such issues if they popped up and that is was no big deal.

I honestly don't believe this was the real cause for blocking the teams communication. I'd rather think the project manager didn't want to give up control. Loosing control can be frightening, and the only way to deal with that is to have a bit of confidence in the developers ability to do their job. Or it may  be that the project manager was so used to doing things that way that it didn't even occur to her that letting go of the reins might be a valid approach.

In the end, the project manager dismissed this idea and said her approach was preferred: is is better to shield them from their customer and instead channel all communication through her. (Side note: the project manager had been absent for most of the project, increasing communication problems even further. From that point of view she did trust the team... to fend for themselves.)

Here is what I think. Allowing the team to interact with their users during development makes it much more likely that problems are dealt with and helps make adjustments quickly and timely. It also increases trust between the two parts which allows for more ideas and better creativity, not to mention improving chances of doing business with the customer again.

Another important factor is that the team, through direct communication, feels more responsible and committed to the tasks: "I'm doing this because I want to make a great job delivering as I've promised." as opposed to "The project manager wants me to do this, because she says so." What do you think is more likely to produce great results?

Teams, Architects and Decisions

I know lots of great programmers. Some calls themselves architects. This text is not, in any way, intended to lessen what they do. Also, I want to make it clear that I don't support cowboy coding or poor design in any way. Agile, done well, holds quality and correctness in high regard. So do I.

Let's talk about Software Architects. The title itself doesn't really mean anything, it's just a label and everyone has their own definition of it. Also it seems everyone and their uncle is calling themselves architects these days. I suppose that is natural, because the title has a nice ring to it and it tends to come with benefits such as better pay and authority.

Unfortunately, many architects are just average programmers who never should have been given that particular rod of power in the first place. This has far reaching consequences, not only for poor developers having to work with the mess, but the entire organization and its customers. It's also worth mentioning that architecture, as a term, associates development with construction work and that has nothing to do with creating software.

All this dilutes whatever meaning the title once had. I kinda think that is good, because in the end we are just programmers with different amounts of experiences and skills. Some more than others. So should a highly skilled programmer be called an architect? I don't know, and it's not very important. What is important, on the other hand, is making sure your teams have enough competent programmers who understands how to structure the system in such a way that it ultimately makes your customers happy. I don't know if that is good architecture or not, nor do I care. What I do know is that we are in the business of deliver working software, not architectures.

Creating software requires all manners of technical skills: analysis, test, design etc. That's what all developers have to deal with on a day to day basis. From the top of my head, I cannot think of a single thing an architect should do that an experienced programmer should not (I leave customer/requirements out of this, those tasks are handled by the Product Owner).

What is your definition of an architect as compared to a developer? How can you single out the architecture from the system?

My definition

Not surprisingly, I think of a software architect as a great developer. A great programmer should be humble, patient, eager to explain and use her experience to coach and mentor her team mates and not wield her knowledge as some kind of power. Having a least one experienced programmer sharing her knowledge with the team is very important, so I think the definition of an architect as an experienced programmer with coaching skills is spot on.

I recommend Martin Fowlers take on this topic. In short, he says that architecture is "the shared understanding of the system" which makes the architecture a social construct. Further, the role of the architect is "to mentor the development team, to raise their level so that they can take on more complex issues.".

I agree with him. It makes the architect a servant leader and not a decision maker. Again, a great developer.

Teams and leaders

The reason for having a team in the first place is that it should be able to perform better than just the sum of its parts. That is obvious, but you cannot simply throw some people in a room and expect them to work as an effective, coherent team from day one. All teams have to go through several stages to start performing better than its parts. Unfortunately, you cannot skip any of these stages.

Getting a team to the performing stage takes effort and courage from the organization. Not surprisingly, this is where it fails. The team does something wrong and/or conflicts arises so the organization feels the need to "step in" and do something about it. Take charge. Usually this is handled by putting a powerful leader into place to make sure these things does not happen. This person is called their team leader, project manager, architect or something like that. She is put there to control the team and make sure it doesn't fail.

Putting a leader with decisive authority in the team is the classic way of dealing with problems. What happens is that the developers becomes dependent on a single person for direction and decisions, so they never really learn to trust their own skills. In the end, this effectively blocks the team from reaching the performing stage and never learns to perform effectively. They end up being mediocre at best. How ironic is that?

A better approach is having a coach on the team. A coach is a type of leader without decisive power. Her primary goal is not to control, but rather to support the team being their "servant leader", helping them grow their skills and teach them to use their abilities. A coach guides the team through the decision making process, helping them come up with new ideas and thinking in different directions.

Creating a powerful team costs a bit in the beginning, but you make up for it in the end. It's like technical debt, but for teams.

Who should decide then?

I like the Scrum definition of a team:

"There are no titles for Development Team members other than Developer. Regardless of the work being performed by the person, there are no exceptions to this rule". 

A team should consist of cross-functional developers with equal authority, able to deliver the next product increment (it's the same in XP as well).

There is always someone with more experience, but that does not mean they should make the decisions. A team working to reach a convergent decision does a much better job with that compared to a single person on his own. So there is no need for any single person (architect or team leader) with decisive powers. In the end, decisions are made and owned by the team.

Summary

1. Self-organization and collaboration is the best way to create software
2. This requires every developer on the team to be an equal when it comes to decision making
3. A person with decisive technical power is contradictory to that

A few questions with answers

How can you treat everybody 'equal' if one has just one year experience and one has 20 years experience?

The team should be able to handle this. It means they should self-organize to create their own decision making structure. The team will eventually learn to know each other and start trusting each individuals area of expertise. Naturally, the input from a senior will carry a bit more weight in the eyes of the other team members, and that is as it should be. It does not mean he can override their decisions though.

What is the problem if somebody is in charge of some specific topic and lead the team?

That is not a problem as long as the team is making the decisions, not that single person. Obviously the teams database admin will have much more to say about databases than the other guys, but he are not allowed to do as he pleases.

We are looking to hire an architect. He should have these skills: testing, design, deployment, support, business knowledge, clean code, gui, networking, databases, legacy…

That does not look like the skill set of a single individual, but rather the skill set of a cross-functional team of developers. When complexity increases you don't go look for one single person to deal with it, you start looking for teams of people collaborating better to solve the problems.

What Makes a Project Successful?

The other day I had the opportunity of introducing agile to a client. I usually do that by walking through how Scrum works; backlog, sprints, sprint planning and spending time talking about organizations and how they deal with change. 

That approach usually works well, but this time I decided to use another approach. I simply posed this question to the team:

What makes a software project successful?

After a short, but great discussion they came up with the following answer:

• Specification - So we know what to build.
• Estimation and milestones - How long will it take.
• Project manager - Keeps project on target.
• Resource utilization - So people have things to do all the time.
• Testing - So we know it works.

Quite possible it was the first time they had ever talked about it, so I'd say this was a new experience for them. 

To make it a bit more interesting, I had prepared a list of my own what I think is most important in a project: