Lately I'm hearing a lot about agile "processes" and teams that claim to be adopting an agile "methodology".  This sort of language speaks as if certain structures and procedures can be adopted which will make a team agile. This thinking is misguided at best, damaging at worst. When Kent, Bob, Ward and the other 17 "Apostles of Agile" crafted the Agile Manifesto, they did not publish a list of procedures or processes.  Instead they provided a set of values and priorities.

Are you part of a team that is striving to be agile?  If so, ask yourself, what is the primary driving force behind your efforts?

• Structures
• Procedures
• Processes
• Methodologies

or

• Values
• Priorities
• Principles

Do we need structures and procedures?  Absolutely! They are the context in which we perform concrete actions in order to fulfill the values and priorities to which we are committed. However, it is the ability to adapt these structures and procedures that makes an Agile team. When methods and structures are rigid and unchanging, agility has ceased.

Agile is not a process, but it is about how we create, shape and adjust our processes. The real question to ponder is this: "Do current structures, procedures and metholodogies enable us to maximally operate according to our values, priorities and core principles?" This is the question of alignment (a concept I will explore further in future posts). If the answer is "no" then are you willing to do something about it?

One of the facets of the Agile methodology I appreciate is the emphasis on transparency.  Rather than ignoring the proverbial elephant-in-the-room, Agile helps us to quickly identify (and hopefully address!) the real issues that affect our teams.  This aids the continuous learning process as we must constantly face hard realities and find creative ways to address them.

A vital part of the Agile process is the retrospective.  In this process, the team members identify the events which have occurred during a previous time-period.  They then seek to discover patterns in these events.  Finally, the culmination comes as the team identifies ways they can continue doing what is working, improve on what is working, and avoid doing what has not been working.

It is important to enter the retrospective process with a dispassionate view as to the events which have occurred prior to the retrospective.  It is non-productive to place blame on individuals or circumstances.  Instead, we must work together to face reality in the form of hard facts. As we reflect on these factual events, we work collaboratively to identify possible solutions that enable the team to reach for ever more productive heights.

This isn't to say there is no room for feelings in a retrospective.  Certainly the team members may experience a range of emotions as they reflect on the events of the previous time-period.  But the idea is to avoid any form of us-them mentality, or to blame circumstances for the outcomes.

Retrospectives can be an exhilarating and enlightening experience.  They are a great tool for improving the continuous learning of your teams.

Curiosity killed the cat - Eugene O'Neill

What is true for the cat is completely untrue for the agile team member.  The best agile teams place a high value on learning.  Curiosity is the catalyst for knowledge acquisition and creativity.  It helps us remain dispassionate about personal preferences and can unlock our potential for divergent thinking. Often it seems that curiosity is reserved for R&D or design processes, but the best way to maximize its potential is to stay curious throughout the entire product development lifecycle.

Curiosity when planning.  This is a vital element in a design process.  We need to stay curious about potential features and requirements.  We need to stay curious about resource allocation possibilities.  We need to stay curious about platforms, tools and technologies.

Curiosity about processes.  There is no perfect process, but there are processes that fit better for a particular context or situation. We should not simply assume that what worked before will work now.  We should not simply assume that what is new is better.  We should continually mold and shape our processes for maximum effectiveness.

Curiosity about personalities.  Our curiosity can be applied beyond the particular task at hand by extending it to the consideration of organizational culture, people, relationships, interactions and influence.  This can enable us to work better together and to maximize the potential of our teams.  This can also help us diffuse conflict by minimizing presumptuousness and assumption, and instead choosing to remain curious about why other team members are acting in a particular way.  

Curiosity when pondering.  Retrospection is reflecting on what worked, what didn't work and what could work better in the future.  Curiosity helps us to look deeply into our processes, our planning efforts, and our personalities to learn the lessons that will help us hone our skills and achieve better results as we move forward.

So if your goal is to effectively function as an agile team, reflect often, ask a lot of questions, and seek to learn from every possible facet of every possible situation.  Place a high value on staying curious.

How do you know if you are an agile software developer?  How do you know if your team is agile?  It is easy to say you are.  It is easy to intend to be.  It is easy to lose agility if not continually maintained.  On long projects focus shifts often.  Success is a moving target.  Agile practices have to be retuned and reapplied periodically.  That’s how it was intended to work.  That’s what makes it beautiful.  It’s a solution to be implemented later.  

The Agile Manifesto is a guideline for writing better software.  You could say it is a loosely coupled collection of best practices.  The Agile Manifesto does not contain a significant amount of detail and I believe that’s intentional.  It’s composed of a dozen flexible recommendations.  It’s not a script or a rigid doctrine of rules.  There is room for interpretation.  This freedom allows for easy adoption.   It also allows for radical variations.  Care should be taken not to let freedom become an evil mutation of agile practices.  If in doubt or debate, remember, “Working software is the primary measure of progress.”

It’s easy for teams to allow existing bad habits to remain when moving towards a more agile environment.  Understandably, old habits die hard.  Agile teams should actively identify their bad habits and discuss ways to eliminate them.  Allowing bad habits to evolve and masquerade as an agile practice is an evil mutation.  To avoid this, a team should continually improve their process.  Review the Twelve Principles of Agile Software as a team.  Eliminate rigid and strict processes.  Remove unnecessary steps in processes.  Find new ways to improve efficiency.  In short, tailor your process to best serve the team and your users.  Determining how best to implement the Agile Manifesto is up to you.

The Agile Manifesto has a lot to offer software developers.  Being agile in your profession is not limited to the software industry.  Many teams can learn lessons from the guidelines put forth.  Just as the software industry gained inspiration from a patterns book written on architecture.  The Agile Manifesto makes good sense in the work place.  So, if you strive to be agile, you should ask yourself often; self, are you agile?

The title of this entry is a standard mantra for agile programming efforts.  And sometimes agile principles apply in other arenas besides software development.  For example, my wife and I came up with a great idea for carving pumpkins this Halloween.  In years past, I carved pumpkins like just about everyone else: with a large, foreboding knife that awakens fearful images of horrific scenes when wielded.  Well no more, because sometimes the quickest thing that works is also the safest thing.

First, set the butcher's machete aside.  Now trace a face on the pumpkin with a pencil.  Next, grab a drill (cordless is handy, though any drill will do).  Yes, I said a drill.  Now make holes in the pumpkin using the drill, following the outline you drew with the pencil.  The end result looks really cool and was much easier than using a knife.

So, I guess the lesson is that sometimes an unconventional approach pays off.  If you try drilling your pumpkins this year, let me know how it goes.

Agilification is dedicated to agile software development principles and team management practices.  To find out more, check out the Agile Manifesto and the Principles behind it, or subscribe our our RSS feed to get updates when new content is added to our site.