Mindset vs. structure in agile organisations

"Agile" has become mainstream, but there is no consensus on what it means. Here are three general patterns about agile structures,

Is agile really the right solution?

"Agile" is now mainstream. However, I put it in quotes to illustrate that "agile" has different meanings depending on who is using the word. To some, it means little more than the mindset of moving iteratively toward a goal. To others, it means a rigorous structure of product development processes that promote developer:ing satisfaction. Still others use it because they have to, without having the mindset or processes to truly reap the benefits of "agile."

Having been involved in over 50 projects in all types of organizations, I believe I have learned a few things about "agility". The important point is that depending on what organization and team you are in, a different approach to agility works best.

Here are three common patterns I have found.

A. Minimum structure

In this pattern, which I would call the agile ideal, only productive work is done that moves directly toward a goal. This means no strict structures or processes. Instead, a clear vision guides the team.

Requirements

  • Ein extrem erfahrenes Team, das eher klein ist (< 8 Personen)
  • An organization that allows this team the freedom to achieve their goals however they wish
  • A clear vision

Advantages

  • No unnecessary meetings or documentation, no stressful work atmosphere
  • Quick and deliberate action

Dangers

  • Try this with the wrong team or the wrong leadership and you could end up with nothing useful.
  • Work only with experienced teams (no juniors) who ideally know each other well
  • Does not work for projects that require larger teams

B. Custom process

Bigger projects require bigger teams, bigger teams require more structure. In this pattern, you take an approach like SCRUM or KanBan, extract what works for the organization, and leave out what doesn't work.

Requirements

  • Manager:inside who has enough experience to establish a good, individual process and who has an agile mindset (does not insist on strict, complete and predefined requirements)
  • Organizational freedom to use individual instead of standardized processes
  • Enough experienced team members to provide quality feedback and improve the process over time even for newcomers on board

Advantages

  • More flexible than SCRUM by the book, less time wasted
  • Adapting the process to the team will result in a process that everyone can be happy with

Dangers

  • Can sometimes go too far and misappropriate essential elements of agile processes
  • Can lead to agile waterfall without iterations
  • Can run into problems in larger organizations because each team creates its own version, which hinders cross-team collaboration

C. According to the textbook

Organizations for which agile is completely new could benefit from adopting a rigorous, textbook process like SCRUM to change the way they think about the development process.

Requirements

  • Time and money, because implementing a process like SCRUM will require both (but in the long run, waterfall approaches are easy to beat with agile)
  • Management support for agile transformation

Advantages

  • Comparatively easy to introduce, as there are trainers that you can hire
  • Standardized and structured, easy for new team members to onboard

Dangers

  • Structure cannot completely replace mindset. If management gets stuck in old, ineffective paradigms, in the worst case scenario this becomes a waterfall duplicate
  • If your management likes to hold meetings, SCRUM is a good excuse to hold more and longer meetings with many people, wasting unimaginable amounts of time and money.

Conclusion

It was a hard lesson for me to learn - that sometimes the at first sight inefficient and wasteful structure of a process like SCRUM is the best option. Today, I see that. Yet I still feel the yearning for minimal structure whenever I'm faced with a development challenge. And I would still say that for new prototypes or innovation projects, pattern A. is the optimum - if you have the required team.

In later phases and larger organizations, this small team creating the first prototypes needs to be followed by more structure that defines and expands the project in the long term, with approach B. or C., depending on your organization and team. And when it's time to reinvent for a new major release, maybe whip out the expert team A. again to build something great in the most agile way possible!

Written by:
Sebastian