Today in the Agile series, we have Agile Principle 5. Lets dig into this very controversial one.
https://agilemanifesto.org/principles.html
Would it surprise anyone that I have a strong feeling about this principle. To me, if you want your development team to succeed, you, as management, must provide this environment. I am actually conflicted on if this should even be an agile value since its subject to the culture of the organization as a whole.
What kind of nonsense is Agile Principle 5 is subject to the culture of the whole organization? Why are you so down on it?
Lets unpack this principle to try to explain.
Projects, Not Software
First we have the main goal, the thing that delivers the value of our work. We have the projects. Here is some of the issues I have with this being on the list. Mind you that I totally agree with the sentiment. In my successes, they came from execution of this principle. So don’t take this as a criticism of what it tries to mean.
First we have projects. Before we talk about software and how it delivers value. We have deviated from the main topic by expanding it to projects.
Motivated Individuals
Next up is what is a motivated individuals. Most people I run across think this motivation should be from the passion individuals’ have for the project. While it is a nice luxury to have a true believer, rarely is it something that is desirable to have all true believers. It often horrible if you have a team of nothing but true believers.
Besides in my experience people who are passionate about a project often cause its failure. It has a tendency to become their baby. They are prone to violate an important rule of software ideas that no one likes to talk about. It is better to fail quickly than fail slowly.
What I say sounds wrong? There is a reason your Doctor’s professional ethics discourages them from treating their own family. They are too close. The odds of not seeing the bad is much higher because they don’t want to see the bad. On the other extreme they see all the possible things that could be wrong and overreact.
In your mind, your baby may need to have feature x, y and z because its important. This can create massive scope creep and scope creep causes project failures.
This is weird but in my experience, projects are better served when the locus of motivation comes from professionalism. It is totally out of vogue with the follow your passion culture we have today but a sense of duty born from professionalism tends to produce better results than passionate dreaming.
Environment, Support and Trust
The environment, support and trust often have starting levels determined by management. I have worked in places that make the average toxic work environment seem healthy. In those environments most projects fail because groups cannot overcome the deficits caused by management. Image each of those characteristics being a piggy bank. Management filled it with IOU’s and you are now responsible to figure out how to dig it out of debt. Then go and build a surplus.
It can be done but traumatized, frighten people have issue with building those things. Very few were capable of actually executing in that environment because their team could not do it.
I will say that job was a place where I had some absolutely amazing successes. I was the most miserable I ever been but I pulled off some seriously awesome successes.
We pulled off that feat because we overcame the management debt on those three things. So if you are in a place like that, know it is possible.
Dig into your professionalism for your orientation, trust but verify the actions of your team and provide no strings attached support to them. You may not be able to alleviate your own suffering but you can help them bear theirs. Most people are caught in the web too and if you can do those three things they will mostly likely respond. Beware the people who are exploiting the chaos. There is a reason to verify their actions is in with trust.
Functionally however, if management does not create at least a neutral environment there is not much the average team can do to compensate.
Concluding Agile Principle 5
Wrapping this up, I understand why it is in the list but I am not sure if it belongs as stated. I feel like it is out of scope for the team and its terminology is out of scope for a software delivery philosophy.
If forced to I would refactor it into something like:
Build projects around ethical professionals.
Management must give the team the environment they need so they can provide the support and trust required to get the job done.
Or something like that so what do you think about my modified Agile Principle 5. Do you agree that it feels out of scope with where the first 4 rules took us? Do you have a better version? As always leave any questions or comments below.