Skip to main content

Author: John Yorke

Are You Ready for the Fallout?

There is an old saying – “An Agile transformation is easy, you only have to change two things: Everything you say, and everything you do.”

However as obvious as that joke was, it is also wrong. You only need to change one thing; you need to modify the way you think. It is my premise that when we talk about Agile Transformation what we mean is transforming our thinking from considering our deliveries in terms of “Projects” to thinking in terms of “Products” and transforming from measuring people in terms of their effort, to measuring them in terms of their collective contribution to a shared goal (the value they add).

Project or Product

Project: an individual or collaborative enterprise carefully planned that is designed to achieve a particular goal.

Product: an article that is created or refined to satisfy a need.

As we have all discovered, software product development is complex, both in the development itself where we face a host of unpredictable variables, complications, and unknowns. However, more significantly, it is tough to know what you want until you see it and consequently there is an abundance of quality software products that do not adequately fulfill the need that triggered their commission.

We have learned that reviewing progress regularly with stakeholders and modifying based on that feedback is far more likely to result in a successful product. In most cases, it is a fallacy to believe that for a complex and custom software solution you can know your end state before you begin, regardless of how well you analyze. No matter how good at planning you are if you do not know the end state your plan is flawed, and as you cannot predict the unknown even the best plans are unreliable. We have come to realize that custom software delivery is far more akin to product design and development than it is to project delivery.

“Management is doing things right; leadership is doing the right things.” Peter Drucker

Agile Transformation is about moving from management to leadership. Management consultant Peter Drucker is an inspiration here, as traditionally we put so much effort into getting things right, to be more efficient, or to do this by that deadline. Given that we often forget to ask if what we were doing was bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.

If you are considering an Agile Transformation, it is likely that you have discovered that efforts to “manage” projects are leading to the wrong results and the focus needs to move from a focus on the effort to a focus on the value. To set a direction and “lead” the way in product development. Try to stop measuring output and start measuring outcomes.

Impact on Project Managers and Business Analysts

This is a significant cultural change for many companies and not an easy one. It is a complete shift in perspective, moving from planning the delivery of a project to collaborating on the creation of a product.

For project management to be effective, the end state needs to be [largely] known, and the steps to get there should be familiar and [largely] predictable. With a known end state and predictable building steps, a Project Manager can more effectively work towards that aim.

Software projects are far more complicated with many unpredictable variables with the biggest variable being the end state. In many cases the end state is not known at the outset and emerges while developing the product. The true end state needed to fulfill a need or want can very often be significantly larger or smaller than initially anticipated. The ability and flexibility to pivot based on emerging information is crucial for delivering value and the product being a success.

Business Analysts similarly must adapt, as project planning relies on a knowing as much as possible at the time of planning, and so there is substantial reliance on the Business Analyst. Product Development is again a mind shift for a Business Analyst since there is no longer a need for detail up front. In most cases, it is a waste due to the likely and frequent change of direction and priority as we learn so much as the product emerges.

Business analysis in agile software product development means an early assessment at a high level is all that is needed with detailed analysis happening much closer to when the work is done. At this point what is needed is more known, and so we are not wasting time analyzing something that will not be done.

An Agile Mindset

Agile is a mindset far more than anything else, and when you start to consider it, there is nothing new, nothing original, and you will be surprised to find that while the word Agile has been used a lot by the software industry in the last 20 years or so, the principles and behaviors are simply the good practices of general management going back a century or longer. “Agile” as we have come to know it can cover Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks. In most cases, it means a collection of historic good practices and guidelines identified by successful leaders and businesses that have been collected under one umbrella, polished, and marketed. I say this to discourage the notion that Agile is new and untested. It is essential to note that there are misinterpretations and misapplications but that the underlying principles are sound and based on much experience.

Let’s take for example the Ford Motor Company. If you looked at this company over the last 100 years and assessed it against modern standards of agile, my guess would be that Ford held up quite well.

Agile Transformation Should Not Be Your Objective

Agile Transformation is often presented as the objective when in reality it should be a strategy to reach a goal. Taking some time understanding what your goal really is, will make any transformation far more likely to succeed. For example:

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you (or your clients) feel you are not getting value for the money?
  • Are you slow to market?
  • If you are creating software products for internal teams are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your Return On Investment (ROI) for software development too small?
  • Are you losing critical development staff?
  • Is there a lack of transparency in the software development process?

These are just a few of the many reasons a company may want to undergo an Agile Transformation, they are all global business issues, and that is a key point: Agile Transformation is not an initiative just of the software department, it is a change for the entire business. It is a major cultural change that will impact your business from top to bottom. From the way you sell your products, to the way you hire staff, and particularly to the way you measure success.

Team Leadership on Agile Teams

Yesterday, I had two people both of whom I have a lot of respect for, independently say that having a single person in charge of a team “works.”

I was taken aback by this, partly because of the surprise that two people would say the same thing on the same day, but more so because this goes against my experience and my opinions on good team leadership. This caused me to step back and reconsider my opinion and my reasons for it. For me, there is a great pleasure in being challenged on my opinions, especially ones that I was so sure of and have given a lot of thought to.

My Experience

I have worked for other people for more than 25 years and have spent a great deal of time witnessing leadership in action. I have also managed teams myself and have coached quite a few. By a very quick count, I would say that 70-80% of team leads were poor leaders. For sure, there were a few that got the job done by force of will, by leveraging authority, or by imposing death marches on the team. The organization sometimes saw them as successful, but the teams thought them to be more like dictators or bullies.

Many team leads – often insecure at accepting other people’s ideas – simply were unwilling to see or consider any other perspective. But there were a few good or even great leaders who didn’t see management as a tool for control, but as a scaffold for building the team and achieving great things – if only these leaders could be cloned.

So I am probably tainted by my experiences, but the notion of one person in charge of the team fills me with dread. I wholeheartedly agree that the model of a single leader can work with the right person, that does not mean that it will work in most cases, or that those qualities are the norm, and it certainly doesn’t mean it will work as a model in every case. What is more likely is that those great leaders would thrive in an environment where they didn’t have defined authority- but more on that later.

I can only imagine that just as I have been colored by my experiences, my colleagues have equally been colored by theirs, but they have had the good fortune to see better leaders than I have. We will also discuss this further and why this is a good approach, and whether my instinctive reaction and poor experiences are in contrast to theirs.

Before proceeding, let’s stop here and reflect for a moment. One quote that comes to mind related to what I have said is the following by Author and Former Nuclear Submarine Commander David Marquet: “Leadership should mean giving control rather than taking control and creating leaders rather than forging followers.”

Oh Captain

The military is often used as an example of one named leader, but there is a distinction in the military that differs from industry, and that is that they have needs that are very different to a software team. Those differences are a need for independence and a desire for expedience in decision making: Military units will often need to operate independently without contact with their parent structure.

In a business environment, it is rare that a disagreement is so urgent that it could not be referred up if there was some type of dispute. The other aspect of a military organization is that “life and death” decisions need to be made very quickly; with little time for debate or consensus-seeking.

However, even in military structures, there are examples of leaders who take the view that they are the Product Owners. This means that they will say “this is what I want to achieve, you tell me how” and then suggestions are made, and the leader simply endorses the team’s advice or at least considers it before making a final plan. Naturally, there is an element of accountability, but the trust that this demonstrates in the team is significant in empowering the team and growing it.

This notion is explored more deeply Marquet’s book: Turn this ship around. Let’s take a look at some of the principles outlined in the book.

Agile Principle #5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

We Want Conflict and Debate

In software teams, it is often the debate that produces the greatest thinking and best ideas, so stifling the debate is counterproductive to success. Having a single person making decisions smothers debate, it thwarts conversation, and it disempowers the team. If a team is overruled often enough, they will stop making suggestions, and if one person becomes so myopic in their opinions, it can make the team feel powerless and excluded. Also, when there is a defined leader they often have a tendency to lack transparency, as information is selectively shared and this lack of information also impedes debate.

In short, I believe that having a defined leader is in conflict with another Agile principle.

Agile Principle #11: The best architectures, requirements, and designs emerge from self-organizing teams.

Merging “the What” and “the How”

Having the same person responsible for both the what (vision) and the how (implementation) also stifles innovation. Rather than the team determining the best architecture and the best solution it becomes driven by a single individual. Again, this is at conflict with Agile principles, and while you may say that a good leader wouldn’t let this happen, experience and evidence speaks to the contrary. Power corrupts, and if someone has the responsibility and authority, it becomes hard for them not to use it, especially if he or she perceive the team is making a mistake. And if teams are prevented from making mistakes they will stop experimenting.

We Want Balance

Software development is a balance of content, quality, cost, value, consistency, team growth and a variety of other factors. It is rare or at least uncommon to have a single individual that is able to understand and balance those conflicting elements effectively on their own. More often than not, a single individual prioritizes one above the other, driving to a deadline, or gold plating a solution. In some instances, any other single aspect usually becomes prioritized at the expense of the rest of the project needs.

I believe that a model based on shared leadership and shared management between multiple roles solves many of these problems. Having someone focused on “the what,” others focused on “the how ” and someone else focused on team improvement and consistency might create conflict (deliberately), but it might also create balance and harmony, and it becomes a catalyst for (great) debate.

We Don’t Want a Silo

If we make one person responsible for the direction, implementation and team growth, we are putting all our eggs in one basket. If this person is on leave, out sick, or leaves the firm, his or her absence can have serious repercussions to the project’s success. There can be so much knowledge tied up in one person that they become indispensable, and of course, this puts all at great risk.

Problems with Shared Leadership

However, I would be remiss not to consider downsides to a shared leadership model. First and foremost, there is a cost. For small teams, it may be difficult to find team members that have a natural affiliation to the balanced leadership model, with part-time Product Owners or coaches/scrum masters. It can be a tricky situation when these roles are not officially named, but the responsibilities are shared.

But even then, I would say that calling one person “Lead” or “Manager” can again be destructive. And the notion of combining Coach with Product Owner and implementation into just one named role can lead to dysfunction. In many respects, I wonder if the cost of additional named roles is worth it just to prevent the dysfunction a single leader creates. If the team is too small to warrant the explicit roles, then get rid of named roles entirely. If a team is that small, then naming a leader should be unnecessary and should be self-organized within those boundaries.

This may sound hypocritical, after all, I have spent a good proportion of my career with leader or manager in my job title, but my experiences have been one of an internal conflict in that role. As a Software Development Manager, you become the de facto Product Owner, Project Manager, architect, and team coach.

But there’s often pressure from somewhere, and normally that pressure was to the detriment of the team. In the past, when I challenged it, I did so at personal risk.

Customer and senior management pressure to deliver, cuts costs and drive timelines, which mean that team growth becomes secondary, and team welfare is deprioritized. This leads to making a safe place for teams to learn from mistakes very difficult. Some of that is company culture, but I believe much of that comes from the expectations of responsibility, and bestowing leadership carries pressure and expectation (sometimes real, sometimes assumed). And speaking as someone that has experienced it, I’d rather share that responsibility.

Conclusion

So after reflecting on my interaction with my colleagues about having a single person as a team leader, I am even more convinced that a named leader – whether it be a Team lead, tech lead, manager, senior or nerd wrangler – goes against the principles of Agile. While deconstructing that conversation, I believe more than ever that it undermines self-organizing teams and leads to dysfunction and imbalance. There are exceptions, and there are some team leads that are effective, but I wonder if they would be just as effective, or even more so, in a self-organizing team structure. That being said, there are much more examples of ineffective team leads where power corrupts, and they dominate the team, stifle debate and innovation, and disrupt or impede team growth.

In my opinion, the best leadership model is a balance of “What, How and Team Improvement,” and the more people that share those responsibilities, the better. In practical terms, I’d like to see a team with a Product Owner to determine “the what” but a PO who actively engages with the team. A coach that is focused on the team’s improvement and process improvement and the rest of the team is responsible for “the how.” Within the team, there is no need to identify a senior or a leader as the team can work out decision amongst themselves without titles getting in the way. This model may come with a cost, and it may be difficult to get the balance right, but in my experience, this balance leads to the best results.

Ironically, the examples of leaders that I have seen as being successful (as measured by both results and team morale) have voluntarily and noticeably made themselves servant leaders, stepping back and inviting the team in, choosing to give away authority and creating healthy debate and healthy conflict. So if that is how they lead effectively, why not make that the model from the start?

One Final Thought

I came to adopt an Agile mindset from seeing poor leaders disempower the team and abuse teams into death marches and drive poor design decisions. I saw Agile as a method for empowering the teams and taking away abusive power from lone leaders. The stimulating of constructive conflict and healthy debate are so essential to the process that I object to any impediment to this on principle.
To my delight, in most cases, Agile has done that and so much more, in a creative environment like software, the gains of self-organized teams so massively outweigh the losses that result from a lack of a single clear leader that I am more confident in my opinion that the words “lead” or “manager” have no place in job titles on an agile team.