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.

Are there Leaders in Agile?

I recently had an interesting discussion about what part leaders play in an agile team. Specifically team leaders, CTO's and project managers. This is a part of this:

In my experience, the word leader instills a certain image about a strong "command and control" person, who manage people into doing stuff. Words such as authority, coordination, structure and timing springs to mind. A leader is generally highly committed to the work and feels personally responsible that the task gets completed. This of course is a heavy burden to carry, especially since the leader is not the person who personally works on the task. Instead, the leader is completely dependent on his team. This can often be frustrating and some side effects of this is that pressure is added or moved on to the developers, followed by the occasional flogging (if they slack) or partying (if they success).

You don't really need that in an agile setting.

In fact, having a person on the dev team who is supposed to be a leader may instead disrupt the teams work, since the other members looks to the leader for answers instead of themselves and thus negating the effect of any self organization. Also, implementation decisions should be solved by the team during their estimation effort. If any one person on the team is regarded as a leader, he or she may sway the balance and non-technical arguments may influence the design which could lead to bad implementation.

Another problem is the need to "look good" in front of your boss. This may result in completing tasks that the leader feels is important rather than what is most important for the business right now.

Contrary to this, agile teams are self-organized. Being self-organized means that the team members themselves sign up to the tasks they want to work on and decides how they are going to do it. When you choose what do to and truly commit to it, you feel empowered, energized and take a personal interest in getting the work done. The result is increased team motivation and a much higher chance of success.

I suggest that, instead of having one person act as a leader, you let the interaction between the customer (prioritize) and the team (estimate) do its thing, preferably using the planning game. For this to work, you need the courage to trust that the framework has everything it needs to solve any problems. Some calls it "the magic of collaboration" and when it works, it is extremly powerful.

Note that the role of agile coach is nothing like this. It may be a type of leader, but their primary goal is not to control, but rather to support the team being their "servant leader" carefully helping the team to grow their skills and learn to use their abilities as best as possible.


So in short, I cannot really see what a leader could do in an agile environment.

Related to this is the cool presentation about "The amazing truth about what motivates us" which I highly recommend: