Be Agile not a doers of Agile

Companies throw themselves at organisational wide transformation effort to move to use Agile processes, but what are they once they have transformed? What would make you say “Wow! X is Agile....”? Companies seem to have their transformation mark of success as the establishment of a common, certified, set of Agile practices. Until a company has fully adopted the use of an Agile processes practices; stand-ups, refactoring, iterations, card grooming etc a company doesn't seem to say they have transformed. However, do the activities people undertake at a company truly identify it as Agile or alternatively should it be the way a company decides what to do and how it guides the actions it takes? In my opinion, most organisations value the establishment of practices as their goal and I think it's wrong, they are missing the mark.

A transformation is not about the establishment of a set of different certified practices! It's about a cultural change to use a new set of principles to guide the decisions a company makes. Once that new principle led culture has been established you can look at embedding practices, ones that are guided by those principles. To be a company that has performed an Agile transformation, a company must prescribe to frame the way it acts by meeting the Agile principles! None of this is really about the establishment of a process like SAFE, LeSS or Scrum. It's about how you decide which practices of a process you use, how and where you will use them, how you change them to meet your needs, and which practices you discard. To be frank the pursuit of a standard way of doing things, the establishment of a single repeatable process misses the whole point of being Agile, it's an instant transformation disqualification.

Companies need more than one process, Scrum doesn't really help the code writing practices of a developer any more than Scrum provides a great framework to guide your desired culture of innovation and experiments. Backlog grooming is a practice that is suitable in multiple situations, however, it's rare for two business situations to be the same, so a practice, like backlog refinement/grooming that works once may not work again.

What makes a software development process an Agile process? There is a gaggle of processes that are termed Agile; Scrum, XP, SAFe, LeSS, DSDM, FDD, Crystal… There are also lots of written descriptions of what makes a process Agile; It is iterative, It is Scrum, a process where things evolve over time, it guides cross-functional teams etc. My take on it is that a process is Agile when you can see that the processes practices apply Agile principles. Behind the Agile Manifesto, there are twelve principles - (https://agilemanifesto.org/principles.html). All of an Agile process practices are framed by those 12 principles. Historically the principles came after a lot of the Agile practices. However, when people debate if "Something" is Agile or not they are arguing if the "Something" applies those agile principles. 

When you look to transform, spend time absorbing the principles of Agile before you start establishing any specific processes practices. When you start looking at the establishment of a practice first look to understand what the practice is there to achieve, what it tries to do and how the principles guide them. When both the Agile principles and the objectives of a practice are understood, the value of them is understood then and only then try a practice. Companies rarely seem to spend any time on the why. Companies seem to want to get going, people need to act so they jump straight into the action and start doing Agile, never understanding the why's! Most companies, in my opinion, do Agile, however, they are rarely Agile, you need to apply the principles in what you do to be Agile. You hear people making statements like "He or She is just not Agile" or "That's not Agile", but there is no real depth to those types of statements because the accuser has no real idea what Agile is in the first place because all they know are practices.

If you move straight into enacting a practice, without understanding the why's, you have no measures to use to understand if your practice is right! If a team only understands the details of how a practice works then it is only able to improve the way they enact that practice. No process or practice will work, out of the box, without it being adapted to suit the environment in which it operates within. Teams and companies need to understand their environment, what their needs are and then explore what parts of a process work in their environment. If companies can only improve the action whilst performing a practice, they are unable to radically change the practice to make it really work in their specific situation - they just aren't Agile. 

As an example, today's Stand-ups have become irrelevant in teams - In my opinion. However, companies are quick to hold their stand-ups as great examples of their wonderful Agile-ness. When Agile started in Australia, 12+ years ago, most companies office workspaces were configured into cubicles. When a team was put together they very rarely worked together in a common space which allowed them to regularly converse as they worked. The customer was normally someone in the business, with another day job, which meant they were rarely with the team. Teams needed a way to come together regularly, face to face, to understand what they were doing.  Teams had stand-ups, once a day and used them to talk about what they did yesterday, planned what to do today and talked about the help they needed - The team reset/realigned itself every day. A stand-up had a purpose! The stand-up process was guided by a couple of principles:

Business people and developers must work together daily throughout the project

&

The most efficient and effective method of conveying information to and within a development team is face to face conversation.  

Today most teams are cross-functional, work together all day, sit at a common straight desk configuration and converse frequently/multi-daily. The customer is normally a product owner/manager, who is part of the team. If you need stand-up's to understand what is happening then your team is in trouble. When you work together, in a common area, on straight desks, can converse regularly the need for a stand-up is a smell rather than a practice you need. In the last few years, stand-up’s have become more ritual like and quite often a waste of time. Their benefit seems to be a regular question raised at retrospectives. I believe they mask bigger issues within teams. Run a stand-up then at the end ask the last person to tell you what the first person said? I reckon there is a real chance they won't know. 

If your team works together, face to face, with a product owner the purpose of the stand-up better not be to understand what people did yesterday or what they are going to do today or are they aligned.  If they are doing the wrong thing yesterday then you’ve needlessly wasted a day, you cant afford to undo that work. The team should have known yesterday and should have self-corrected. 

Maybe the stand-up should be a mechanism to gauge team alignment over a tool to gain understanding/alignment? How about getting people to say what someone else in the team is looking to achieve or did yesterday. Guage if the team really understands what is going on. If your team is confused then you need to get the team talking day-to-day more frequently. Add practices into the team to keep it aligned as the day progresses. Maybe get developers to take the headphones off. Remove meetings where sections of the teams are regularly missing. Use the constant misalignment to push people to pair more frequently or rotate more frequently. A company will only pursue improvements like the ones above when it follows principles and understands the why. 

A company that looks at how effective they are measured by the practices they use is just Doing Agile! A company that looks at the principles they use to make their decisions, using the Agile principles, is an Agile company. If you're transforming or considering a transformation, don't jump straight into embedding new practices, spend upfront effort in the adoption of the right principles - you'll be better for it.