Tag: agile manifesto

Was Bruce Lee the first Agile practitioner?

Was Bruce Lee the first Agile practitioner?

Let’s take a look at some well known quotes from the legend that is Bruce Lee:

“All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns”

“Obey the principles without being bound by them”

That sounds like Bruce Lee was strongly in favour of responding to change. What about his approach to planning?

“If you spend too much time thinking about a thing, you’ll never get it done”

“A goal is not always meant to be reached, it often serves simply as something to aim at”

That sounds applicable to retrospectives and using empirical evidence to drive decisions. Two quotes this time about using a lean approach:

“It’s not the daily increase but daily decrease. Hack away at the unessential”

“The less effort, the faster and more powerful you will be”

Both reflect the Agile manifesto’s principle “Simplicity – the art of maximizing the amount of work not done – is essential”. Then we have:

“Man, the living creature, the creating individual, is always more important than any established style or system”

To me, this has very strong echoes of the Agile manifesto’s value “Individuals and interactions over processes and tools”.

There are many more applicable examples! I’m beginning to wonder if it’s merely a coincidence that the first papers introducing adaptive and incremental software development processes surfaced in the early 1970’s?

Are you authentically Agile?

“That’s not Agile” is a phrase I’ve often observed, usually from people espousing specific methodologies. What they usually mean is that you’re no longer following a specific approach exactly as written. That may be a good thing…

Whatever Agile software development methodology you have adopted, if you want to claim you’re being (authentically) Agile, you should be honestly subscribing to the following principles. Ask yourself if your ways of working are:


Agile responds to change pragmatically. It tries to adapt rather than relying on prediction, acknowledging that some things may not (or cannot) be known in advance.


Agile aims to reduce uncertainty. It achieves this by taking small steps towards its overall goal rather than multi-phase delivery.


Agile uses evidence to make informed decisions. It changes based on what has been produced or discovered along the way.


Agile’s success is based on working together, with shared responsibility. Everyone needs to understand the goal and how to contribute as a team, to reach it successfully.

That’s it. Moreover, being Agile means that while you value those principles, it doesn’t mean you’re bound by them in all situations. You should respond to changing situations, different circumstances and constraints. That’s being agile (the adjective) and that’s being authentically Agile (the noun).

What is Agile?

Since the original Agile Manifesto was published back in 2001, “Agile” has become an increasingly fashionable buzzword, championed by young, trendy development teams in start-ups, emerging technology companies and small autonomous teams within bigger businesses. So what is it?

What does Agile provide?

For those of you who are unfamiliar with it (or as a reference for those who already are), the Agile Manifesto promotes four key values:

“Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan”

Source: http://www.agilemanifesto.org/

That’s fine in the abstract, but what is “Agile” in a more concrete and tangible form – how might a team or business change in its ways of working in order to become (more) Agile? Essentially we have two fundamental areas to sample and build from; Agile process methodologies and associated Agile practices.

Agile Practices

Starting with practices in mind, there are dozens out there (and more emerging all the time). Just by lifting a selection of some of the more self-descriptive examples from the list on Wikipedia (purely for brevity) we have:

  • Backlogs (Product and Sprint)
  • Behavior-driven development (BDD)
  • Continuous integration (CI)
  • Information radiators (Scrum and Kanban boards, Burndown charts)
  • Pair programming
  • Refactoring
  • Scrum meetings (daily stand-ups, iteration / Sprint planning, reviews and retrospectives)
  • Test-driven development (TDD)
  • Use cases
  • User stories
  • Throughput / velocity tracking

Source: http://en.wikipedia.org/wiki/Agile_software_development

I won’t go into the details or respective merits of the practices that I’ve called out here, as that would distract from the focus of this post and after all, they are all topics easily explained by making good use of your preferred search engine. The important thing is that all these practices scale organically, regardless of the size of your project or team(s)* because they’re either distinct activities (like pair programming, refactoring or CI), the automation of otherwise manual techniques or are purely informational. None of them necessitate change to your wider processes. Think of them as plug-ins you can insert that compliment your chosen process methodology, rather than anything mutually exclusive to it.

* Admittedly, pair programming is somewhat challenging if you only have one solitary developer in your team, but other than that please just trust me. After all “I’m an expert!”. Source: https://www.youtube.com/watch?v=BKorP55Aqvg

Agile Processes

Whilst adopting related practices may be synonymous with Agile development, you aren’t truly Agile unless you’re practising (at least an evolution of) an authentically Agile process methodology. So, let’s see some of the more popular Agile methodologies:

  • Scrum
  • Kanban
  • Extreme Programming (XP)
  • Lean software development

To limit the scope and length of this document, we’ll initially consider how a Scrum based process might scale. You’ll often find that organisations proclaiming to be practicing Agile actually mean they’re incorporating aspects of the Agile Scrum methodology (in a similar way to how “Linux” is misused to refer to a GNU/Linux based distribution). In Scrum’s purest form, requirements move from a “product backlog” (a prioritised list of requirements) to a “sprint backlog” (after a planning meeting) which becomes the list of work due to be completed in the next “sprint”. A sprint will typically last around two weeks, where each day a short “daily scrum” meeting is held where each team member reports their progress from the previous day, their objective for the day and whether they have any impediments or blockers that may restrict their progress. Obviously the method has more depth and substance, but we only need a high-level understanding of the process at this stage:


Source: https://upload.wikimedia.org/wikipedia/commons/5/58/Scrum_process.svg

Agile Teams

Scrum advocates three roles to facilitate this method. A Product Owner, Scrum Master and Team Members. The Product Owner should be a key stakeholder, with a strong vision of the product hope to deliver. They get to prioritise the work in the product backlog, but don’t get to dictate how much goes into each sprint. The Scrum Master’s responsibility is essentially to run interference – removing any impediments in a servant-leader role that facilitates rather than dictates (other than ensuring that the agreed process and the rules of Scrum are adhered to). That leaves us with the team members who deliver our product:

“In Scrum, an ideal team would include seven members, plus or minus two. Usually, teams are comprised of cross-functional members, including software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. It is recommended all team members be located in the same room, called the team room.”

Source: http://scrummethodology.com/the-scrum-team-role/

If we imagine seven team members including an architect, analyst, two testers and one UI designer (like the examples provided in the above excerpt) in addition to the Scrum Master and Product Owner we’re left with two development roles – four if progressing to the recommended maximum. We’re also free to shape the team for the size and complexity of the product we’re going to deliver. This could mean we remove the UI designer and one of the testers from the team and add another developer and a DBA. The makeup of the team can easily evolve as you discover the balance of work. This is ideal for many small teams and businesses, when everyone fits into the proposed Scrum organisational model and as we have a singular Agile squad, work iterates quickly in a serial manner. But does it scale…