Agile Thinking: Leading Successful Software Projects and Teams

Agile project planning can help your project come in on time and within budget. ExtremePlanner is web-based software for agile project planning and tracking.
Table of contents

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. 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.

Agile Thinking: Leading Successful Software Projects and Teams

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. 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? 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.

How to Build an Agile Team

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. Wednesday, 15 March 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.

My Experience

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. In short, I believe that having a defined leader is in conflict with another Agile principle. We Want Balance Software development is a balance of content, quality, cost, value, consistency, team growth and a variety of other factors.

Problems with Shared Leadership However, I would be remiss not to consider downsides to a shared leadership model. Return to Book Page. Preview — Agile Thinking by David Churchville. Leading Successful Software Projects and Teams 2. Are your dealing with serious challenges in your Agile software project implementation? Looking for some inspiration?

Team Leadership on Agile Teams

Based on his popular Agile Project Planning blog, this new book by ExtremePlanner Software founder David Churchville is a page guide packed with tips, solutions, and thought-provoking essays. Organized into relevant themes like planning and estimating, tes Are your dealing with serious challenges in your Agile software project implementation? Organized into relevant themes like planning and estimating, testing, and team dynamics, this book is was written to deal with the everyday challenges you face in your software projects.

Kindle Edition , pages. Published December 1st by ExtremePlanner Software. We've learned a huge amount about using agile methods in enterprise settings and are committed to sharing this learning to help foster their intelligent adoption.

It's been over a decade since the developers of agile methods first started to talk about their approaches. In this time agile thinking has changed from a niche activity to an approach that is widely used. However, like any popular technique, agile software development has suffered from semantic diffusion , so much of what we see under the name of agile doesn't bear much resemblance to what the early pioneers were doing. So I think it's important to revisit the essential elements of agile thinking.


  • Uncertain Near Future: Likely Disruption; Logical Precautions; Help From A Distant Civilization: Ada.
  • The Road Taken.
  • The Loom of Battle (The Saxon Tapestry Book 2).
  • .

I've always seen the essence of agile thinking resting on two contrasts with traditional plan-driven software engineering. Plan-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design.

Success is measured according to how well development follows this plan. Agile plans are a baseline that we use to help us control change. Agile teams plan just as carefully as traditional teams, but the plans are constantly changing to reflect the things we learn during a project.

Agile Software Development

Success is based on value delivered by the software. Plan-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer, and is easier to define skills and career paths.

Agile engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes and tools can enhance a team's effectiveness, but are always second-order influences. I explored these contrasts in more detail in my essay The New Methodology which I originally wrote in and updated in I continue to feel it best expresses how I think about the essence of agile software development. It may not have started it all, but the manifesto gave the movement a name together with a dollop of initial energy.

A decade later it still captures the essence of what agile methods are about. In this twenty minute talk I introduce the essence of agile software development and the agile fluency model.


  • Rethinking the SAT: The Future of Standardized Testing in University Admissions.
  • See a Problem?.
  • .
  • !
  • !

Adopting agile software development is neither a quick nor easy path. Diana Larsen and James Shore experienced agile coaches have come up with a way to think about how teams progress through stages of fluency in agile thinking.