[Off-Topic] Reading the Agile Principles

The Agile Manifesto is based on 4 values. I don’t know how many times I’ve repeated that. More than that, it’s based on 12 important principles. Many consider them as the 10 commandments. I’m always against anything dogmatized, but on the other hand, if you prefer to dogmatize the Manifesto, never pick just one sentence from it in isolation. If you’re going to take one of them literally, take all of them literally — otherwise it would be the same as dogmatizing the 10 commandments and saying “I obey the 10 commandments: I’ve committed adultery, but it doesn’t matter because I never killed anyone, never stole, and it wasn’t with the neighbor’s wife that I committed adultery.”

Among some of the principles we have:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

This single principle has already led to several discussions for years. In particular, read the article Our Highest Priority and Why Satisfy the Customer?.

In particular, I like to think like Eliyahu Goldratt where he says — simplified, of course — that the priority of any company is to make money. Now, calm down, anti-capitalists and on-duty populists :-) We’re not talking about “making money at the expense of people, customers, and society” or anything like that.

The priority isn’t to create innovation, isn’t to create products, isn’t to generate jobs — it’s to make money. And the means for that can be creating innovation, creating products, generating jobs, for example. What I mean is that we confuse the means with the goals.

“Delivering fast and continuously” is very important to keep in mind. Often this isn’t possible, for example, if you depend on suppliers or other external factors. But let me pick other principles related to this first one:

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.”

Time is never fixed, because every professional knows you can’t predict the future. Delivering value quickly is a principle, not a rule. It means we’ll do everything possible to try to deliver something that works, with quality, as quickly as possible. For that, we’ll try to remove impediments, improve processes, optimize procedures, improve communication, and whatever else is necessary to deliver something. It’s a reminder for every agilist at all moments when deliveries start to take longer than normal.

“Working software is the primary measure of progress.”

The same thing said with different words: software that isn’t delivered is useless software. An agilist should feel bad working for months on software that nobody is using. Softwares are different — sometimes it takes 1 whole day to discover a solution that can be solved in 1 line of code. Sometimes you can write 100 lines in 1 hour. It’s the old productivity dilemma that the industry has already tried to solve with several failed techniques like LOC (lines of code), Function Points, and other nonsense.

I can’t help thinking that Martin Fowler was one of those who must have suggested this principle, especially because of his article Cannot Measure Productivity. Software isn’t measured by productivity — it’s measured by value. And whoever defines the value to be reached via software development is the client/company. If the developed software doesn’t bring value, that isn’t the software’s fault — it’s the fault of the software’s value definition. A tool, by itself, has no value.

That’s why I said LOC and function points aren’t useful. I can have a team that delivers 10,000 function points per Sprint. It means nothing if what was asked to be developed doesn’t bring any value to the client. This is one of a Product Owner’s functions: ensuring that what’s being prioritized for development is something that will actually bring value, whether in the short term or the long term, depending on the future vision they have. If the PO has no vision, no strategy, and no clear direction, they will have exactly this as a result: lots of software and little value, and the fault for this is never the technical team’s — it’s the lack of vision and, consequently, the PO’s and/or the company’s problem.

And speaking of POs, we can’t fail to talk about stakeholders in general, those interested in the value to be generated by the project:

“Business people and developers must work together daily throughout the project.”

Personally I’d hate bureaucrats every day in a development environment :-) But cynicism aside, this is another reminder that whoever is interested in the value generated by a project is who should seek out the team and see if they need anything. A stakeholder who doesn’t go to the technical team shows they aren’t interested in the result to be generated. And we’re not talking about having daily meetings with the team, but exchanging ideas quickly, something like 5 or 10 minutes a day would be enough. And no ritual like a Daily Scrum is necessary for that. An interested stakeholder gets up from their chair and goes to the teams. An uninterested stakeholder stays in their chair and waits for things to happen by themselves. Guess which of the two is more efficient? And if the stakeholder, who should be the most interested, shows disinterest in what’s being produced, why should anyone on the teams show interest?

Teams are a reflection of the company’s organization. If the upper layers are disorganized, indecisive, uncommunicative, and irresponsible, the teams will be the same way. What are teams but sub-systems, copies of the complex adaptive system called “company”?

A company can hire 100 Linus Torvalds, 100 Guido van Rossums, 100 John Resigs, but don’t expect them alone to come up with iPods, iPhones, and other great products that will sell millions. Apple works because — I speculate — a Steve Jobs gets out of his chair and gets personally involved in the day-to-day of research and development teams, even being CEO.

Talking this way, it seems one side is exempt from the other’s responsibility. Of course not — the best way to work is collaboratively. But the responsibility of arriving at the best technological solutions, technical quality, and efficiency is the technical team’s. On the other hand, stakeholders are responsible for market studies, marketing research, product vision. One side can and should collaborate with the other, but unfortunately not everyone can equally do everything. Given that stakeholders bring the vision, the technical team will do whatever possible to fulfill that vision. But the vision isn’t authoritarian, just as some technological decisions shouldn’t be. The criticism remains because normally orders come from only one direction, without discussion, and the technical team, even performing their work correctly, may be following a wrong direction, and in the end the criticism turns back on itself for the failure of a vision that wasn’t even discussed.

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

To me, this is a corollary of the previous principle. Forget automated communication systems, information flow systems, or any such nonsense. Everyone has seen films from the 80s and 90s ridiculing “memos,” which were a technique for spreading information. To this day, people still try something similar to memos, only now they’re spreadsheets, emails, wikis, etc. The most important thing is: sit side by side with the person who will deliver value to you and clearly say what the expectations are, what changed, what stayed the same, and get out of the way. If a stakeholder doesn’t have the capacity to talk live with the teams, again they demonstrate disinterest in the result being generated, and therefore the message is clear: what’s being developed has no value, because if it did the stakeholder would show interest in it.

As long as a stakeholder has the old-fashioned mentality of “these people who work for me have the obligation to guess what I’m thinking and deliver what I want, when I want it,” they will never have any value, and they will keep asking themselves “are my teams all so incompetent that they can’t deliver anything to me?” The obvious conclusion they should have is “hm, maybe if I just ’tell’ them what I’m thinking, maybe they can deliver what I want.”

Finally, there’s nothing worse than an absent stakeholder who only shows up when something goes wrong, to yell, threaten, terrorize. Where was he during the entire process that, by chance, led to this accident in the first place?

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Every agile methodology has a “Retrospective” phase, one of the rituals for teams that weren’t used to talking. No process is a silver bullet, and it needs to be refined constantly. In fact, the ideal is that every retrospective at the end of every sprint should have something to be changed. There is no perfect scenario — there is continuous and uninterrupted improvement. If nothing changes after each retrospective, if no one suggests changes at the end of each sprint, something is wrong.

The other principles, I think, speak for themselves:

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Changes are welcome, but only changes that bring competitive advantages to the customer, not random changes based on the mood of those involved.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Again obvious: either you trust your teams and employees, or you don’t. If you don’t trust them, fire them. If you trust them, don’t keep micro-managing and demanding reports all the time. Simple as that. If you don’t trust them and think you can control via micro-management, you’re a terrible manager and should fire yourself first.

About environment, remember Maslow’s Hierarchy of Needs. If your environment is cramped, hot, dirty, disorganized, don’t expect your teams to be motivated, proactive, organized. Nobody motivates anybody, but it’s very easy to demotivate. Don’t demand the top of the pyramid when not even the base is satisfied yet.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

It means that all the principles above are being considered, that is, there is a good environment, stakeholders are involved, live and frequent communication is happening, priorities are well understood, and with that, we can have frequent deliveries at a constant pace and, more than that, accelerating.

“Continuous attention to technical excellence and good design enhances agility.”

The first principle, in isolation, sometimes conveys the false impression that value should be delivered at any cost, even sacrificing quality, maintainability, good design, etc. And that’s false, and that’s why I said there’s no point in not considering all the principles at once.

Yes, valuable software should be delivered as quickly as possible, but, no, never at the cost of sacrificing too much the future maintainability of that software, precisely when the Return on Investment is happening. Each case is a case, and that’s why stakeholders and teams should communicate frequently and make decisions based, for example, on cost-benefit.

“Simplicity — the art of maximizing the amount of work not done — is essential.”

Together with the previous principle, it also means not worrying excessively about “maybe they’ll need this in the future” and creating “bloat” software, fat, architecturally heavy and complex to try to make it “future-proof.” That’s also impossible and leads to software that takes too long to be delivered and with dubious value in the end.

Again, it’s a matter of communication, negotiation, and cost-benefit based on the value the stakeholder communicated they need.

“The best architectures, requirements, and designs emerge from self-organizing teams.”

This topic in particular I’ve already explained dozens of times in various ways, but I recommend reading this previous article of mine about Agility, Chaos, Self-Organization.

If you don’t understand Emergence and Self-Organization, you don’t understand Agility. And this, by the way, also brings me back to my article You Don’t Understand Anything About Scrum which I also recommend reading now.

As you can see, the world of Agility is founded on very important principles. None of them should be considered in isolation — either you consider them all together or you will never have any of them.

But be careful, many confuse Agility and the concepts of Self-Organization and Participatory Management with the Search for Consensus. Nothing could be further from that. I’m taking longer than I’d like to finish reading the book Systems Thinking. But here’s an excerpt I like:

“Finally, fear of rejection and a strong tendency toward conformity among members of a social system and others are obstacles to social changes. An example is the experiment in a city with a dry law (which doesn’t allow the sale of alcohol) whose constituents were to vote on the ban against alcohol. A pre-voting poll indicated that 75% of voters were in favor of abolishing the ban. However, each of the voters thought that the majority preferred the dry law. When the results were tabulated, 60% of voters voted to keep the dry law. Not surprisingly, after the poll was published, the next election on the subject produced a 65% majority in favor of abolishing the ban.”

Democracy based on the Tyranny of the Majority isn’t useful. This subject is much more complicated than simply making people vote on the options, and it shouldn’t be treated lightly. Political Scientists, Philosophers, and various researchers have been studying this subject, and I guarantee there is extensive literature about it.

By the way, this whole subject is more complex than merely reading the 12 principles. An Engineer, a Doctor, a Lawyer study for years and are always far from being masters in their fields. A Manager, on the other hand, studies very little about the subject, and therefore they decide based more on folklore than anything else. That’s terrible and, especially in these cases, when they’re right it’s by luck, and when they’re wrong it’s nothing more than expected.