Why Senior Developers don’t like Agile

In response to https://medium.com/@obie/where-the-hell-are-all-the-great-senior-software-developers-and-hands-on-engineering-directors-b88b0d15fbdf#.qjyryxpjz

I think “Agile” is not compatible with other qualities like OO/Solid and mentoring. There are the following factors:

Problem Solving

The key here is that real engineering is about Problem Solving. And this is something more fundamental than just crunching a 2–3 pointer coding task. Complex problems could not be “just brainstormed”. I need to take at least one shower or long walk to be sure that I got a pretty good solution to a problem. Not the first one that came to my head, but that one that will save much time on a long run. A solution that will reduce a time needed to implement “common feature” two-three-five times.

And actual things are even worse. I may spend few days crunching an initial solution (“crunching” may mean laying on sofa all the day, drawing squares on a piece of paper and just thinking). Then we implement the solution. And after two months I come to you and say that my solution is actually far from optimal. We have to spend some time on refactoring to get to a newer and better. And this mean postponing some features, catching on speed next 2–3 weeks and gaining visible advantage after 2–3 months. How should I get this done under “Modern agile” which usually carry only about short-term gains and could not see further than one sprint?

The real large-scale engineering don’t work on “two week” backlog. It just don’t work that way. Period. The true engineering works differently. I work differently. I have a list of “long running” challenges. I need solutions for them. I also know that at this moment I do not know perfect solutions. I could make a decision if I have to do this right now. But I’ll prefer to wait until there is a good solution (which usually came to mind in background) or until the decision is absolutely necessary.

To do that long-term planning I need a “long view” on the problem. Not just a short-term feature. I also need a space to experiment. Consider I have a “solution” but there is no capacity. Should I wait one or two weeks to include prototyping? To fit that one/two days spike? And then figure out that my idea was wrong and think more? I have to experiment in code, without it I won’t be able to progress on that particular issue. And I do not “own” the backlog. Agile just delays necessary iterations through “capacity planning”. And then it forces developers to make a choice between suboptimal ones. These sub-optimal are really far-from-optimal by the mere fact that not enough iterations was spent on trying different approaches (code, APIs, libraries, etc…)

Do you want to say that “we have a spike”? Well, this does not work as well. It is usually very hard to get something in “time-boxed” manner. Yes, something will be done. But most likely it will not be good. The real measure will came later. In few weeks or months. But there is no time in agile to review the solution done. Just because there is “no business value”. Or, in fact, because managers does not see value. And this happens because these managers are outside of the development loop, they just don’t understand developers.

Mentoring

The same story is with mentoring. What can I teach in a short-term two-week race? The real wisdom come over long projects. The qualities you need are developed by being responsible for a long-term project. Not by being a member of something larger that delivered some mediocre product. But by being the person ultimately responsible for any possible project failure. By being responsible for doing not the best it was possible! Agile don’t have this. It does not allows “ownership”.

And on the ownership. This is the only way to achieve the seniority. Yes, it is hard for both mentor and student. But this is the only way. The student must own some software piece for a relatively long time (3 months at least). It does not mean that there should be some active development. But it mean that the student will be a first point of contact. She will make her own mistakes (not team’s mistakes, her own). She will excuse and will fix them. I’ll just guide this. It is hard to actually allow people to make mistake, but this is required. And I have to be in control to ensure that any mistake is not critical to the project success. Good engineering practices like SOLID are learnt only this hard way. The consequences are just not visible on short-term basis.

Do you really need a wizard who could teach other people to do magic? But real learning takes time, concentration and experimentation. The only things I could teach in “two weeks” are some dirty tricks. This have nothing to do with real wizardry. And asking to do that is insulting! You do not need a wizard. Find somebody else. Some local rogue will be pretty enough.

“Good” Agile

There is a kind of “good agile”. However, this is not the agile you want. It is used to manage requirements. Not developers. Not capacity. Requirements only.

“The team” will define it’s capacity. And “the team” will define what work to be done. On some stages (usually early on the project) most of the time will be spent on internal tasks. And these tasks are not to be put into the backlog! These tasks just have to be done no matter if business see the value or not. Engineers see the value. And that’s why these engineers are hired for!

Yes, business need their precious features. Engineers are not stupid. They know that and appreciate it. But they also know that some things have to be done to ensure project safety (even if they do not know how to do this yet). Explaining this to business could be very hard.

If I have to lead the team, you won’t get an agile you want. Most likely you will see the team as a “black-box”. You see only some people on planning. I (as a lead) will define what they do. I’ll invite them to meetings if I have to. I’ll discuss a backlog with you. Not team, just me. Well, if we have one or two strong developers — you will usually see them along with me. But we will keep the team closed as much as possible.

And you will have to agree with leader(s) on the scope and backlog. However terrifying it sounds, you have to agree with people under you. Managers don’t have that power over the developers to mandate their will, only other developers have. So you have to talk and make compromises. And yes, sometimes it means sacrificing some features just because “developers have to do something this sprint”.

Good (and scalable) development is not like a “set of agile teams”. This is more like a military ship. A captain is responsible for overall success. He have to delegate different tasks to different people (responsible for their parts). And so on. This organically grows team members and provides them a “supervised playing ground” to make mistakes. It is not a dictatorship. Dictatorship will not work, sabotage is a good feedback channel. It is leadership. Leaders have to understand their peers and to work with people they have.

Process For People, not People For Process

Continuing a thought from the previous paragraph. Do you need a people to perfectly fit to your abstract process? Or do you need to achieve some goal?

Do you need a process? Well, you get a process. You will find people who are either highly conformant or ceremony masters. Former ones will write smelling code just because everyone around them do that (and that’s what managers like!). Second ones (majority of them) does not have mastery you want. They just follow the cargo cult. It may look impressive and nice, but they do not have power, they just have rituals.

Or do you need a result? Then build a team. Manage the team! Build process for them! Do whatever they need to succeed. Is it hard? Yes, it is hard. There is no silver bullet, each team may be different. You as a manager have to work hard. But this is probably your job anyway. And if it is not your job, then do not touch my team! I will find a best way to use people. I know that I have to work with different people and I know how to leverage their uniqueness. This is the leadership. Just don’t interfere by imposing rituals.

One tricky part us to distinguish real leaders from good “actors” or “players” following rituals. I think it is pretty easy if you work with the technologies and processes. Developers are good at feeling power and hierarchy between them. And they are capable of working with people of same level. However, managers are not part of that hierarchy, so they do not have real authority to control developers. Any attempts to control instead of finding a compromise will hit team’s morale.

On Autonomy, Mastery and Purpose

Many engineers (and especially good ones) are similar to people of art. They are people of some strange art. And they are driven not by money or a fear of punishment. Key motivators are Autonomy, Mastery and Purpose. Do you offer any of these?

Autonomy? Well, no. There is no “autonomy” in the Agile. There is a team. And the team make decisions. The team owns the code. For some unknown reason there should be a compromise inside the team (but strangely not between team and customers, customers just dictate a set of features to write). There is no place for mistake (except by mistakes caused by lack of the seniority in the overall team). Everything is “transparent”. Strangely enough, “single-person leaders” usually recognize a need for autonomy and give it for their subordinate developers.

Mastery? The first my chapter is about it. You can not get mastery here. Period. Agile is not about mastery. It is about selling and short-term concentration. And how could you achieve a mastery if you have to make hard compromises each sprint?

Purpose? “Business value” is not perceived as a purpose by developers. There should be something else. And the hard compromise is the killer of any purpose. Real purpose usually lessens business value to some degree. Could we create a best music player (whatever it means) by just sticking most marketable features? Maybe Agile-powered player will bring great reaches. But most likely it won’t be something people love. Could you create something that some people will call Great because it is great just for them? Just a few will count. OK, I’ll be happy if you will show just one of them. But the person have to be completely happy with the product. Quite often marketable products don’t have that happy users! People have to choose best from the worst, not “just something they need”. Could you give me a purpose? Not your company’s purpose. But a purpose to make something better in this world?

Most likely your are lacking all of them. At least I do not see this in the offering. I see some shiny things like technologies. Technologies does not matter much to me any more (and by the way, why developers could not choose their tools?). The text says what I’ll be doing and what perks I’ll get. But not why I should do this.

Conclusion

Given all that I’ll go and search the least agile place possible. Maybe I’ll get less money. Not much less, actually. There is a huge shortage of really good developers. But I’ll get all the motivators: Autonomy (in making decisions), Mastery (in the ability to find the best possible solution for at least some problems) and Purpose (of making the world better as much as I can, this is a consequence of autonomy).

Seniority is about problem solving, broad vision and experience of project evolution. Agile is not compatible with that. It is absolutely not surprising that you won’t find really strong seniors for agile positions. You will find either process fanatics or cargo cultists. They are in excess and they do not last for too long in good engineering teams (remember, these teams have completely different values).

Change your requirements. Do you need agile? Then don’t search for stars. Still need stars? OK, drop agile. Let the stars decide on process and methodology. Seriously. Look on yourself. Your company could not grow required people inside! Do you grow too fast? Are your leaders (those who chose the process, architecture and technologies) are competent enough to make their choices? What if your hiring problems are caused by their decision. Is it the right time to stop and learn other approaches? It will be so agile to try another approach, why does not your top management do that?

Engineers could work with any reasonable requirements. Mandating methodology or architecture is not reasonable for most of us. You (and your company) have to learn to make compromises. Technologies and processes in a nice place to start. Otherwise you will have what you have.

References

  • Hammock Driven Design — a very good video about problem solving in general. (James, if you are reading this, you have to create a blog so I could give you thanks)
  • “Drive” by Daniel H. Pink. This is where I read about Autonomy, Mastery and Purpose.
  • “Peopleware” by Tom DeMarco and Timoty Lister. First part of the book goes along with “mastery” and the idea that developers have to define a minimal acceptable quality, not the managers. (Developers set much higher quality bar).
  • Agile is the New Waterfall by ayasin here on Medium. Another story from developer’s side of barricades. Exactly the same feeling as I have. Modern agile is wrong for the development. It could not work.