The problem we detected troubles many small Agile companies. Most often, it’s because they are not 100% Agile, and are doing it selectively. That is because they don’t yet have a defined company culture. Employees are still changing, and in a company of 5-15 people, a new person in or out can make a huge impact on the team, free time topics, meetings dynamics, even frequency and duration of meetings, overall enthusiasm, and at the end - company culture. And there are the managers, one or more. The CEO. They have some experience, but they are often engineers who wanted to start their own project. Therefore, they hadn’t got to the “product owner” position step by step, learning about all the obstacles and important non-engineering fields on that way. And it is hard for an engineer to acknowledge the value of sectors such as marketing, sales, of content writters, HR specialists, technical documentation writters, until that fields become needed. (Been there…)

Now, back to the topic. Manifesto could have been more detailed there, but of course, they wanted to stay simplistic, and set only the foundations. Let’s take a look at one such pair that leads to self-destruction in cases of semi-prepared product owners (or even CEOs).

Through this work we have come to value […] customer collaboration over contract negotiation

From the 12 principles, principle number 2 says

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

The problem is that customer’s changing requirements means new features, reworking, redesigning etc. That is more work for the employees, and is out of scope of the initial agreement (contract), as we were following the “customer collaboration over contract negotiation” rule. I repeat - in well established companies, or with hourly contracts, this is not an issue. But I have also had opposite experiences, where customers/clients tended to get advantage on the “changing (adding) requirements” point. Of course, they wanted more work for the same payment. Who wouldn’t. And us, promoting ourselves as naive, and quick to just take the job - gave them the reason more to do so.

Thus, I’ve got to a logical conclusion that contracts exist for a reason (wow effect), and all important clauses of verbal agreement should be put in it. It should also take “changing requirements” into consideration. It should be put on the table before the clients. It must be mentioned, discussed and agreed upon, so both sides could be content. The more experienced negotiators will have everything written in any communication platform — be it contract, mail, or skype. When you have it written, you can always refer to it and say “hey, this is what we agreed, and that is what you have been delivered”. Clients, sadly often don’t know what exactly they want, or how to prioritize their needs. If they make you spend 20% more time on the project, it cannot cost the same. It is simple math. Who pays for that additional 20% (and “why you”). If we are Agile, why should we be stupid?

I think that Agile was revolutionary and forward thinking considering the circumstances in which it was made. It was counter-intuitive for the current planning-execution way of doing the job, and it is great what changes it had brought. But now, when it has decentralized what it had to, gave autonomy where it had to, and removed excess formalities, it has done its job! If we try to go even further with “no importance of documentation”, “less negotiation”, and “accepting client’s changes even in later stages”, we will do no one a favor.

A small anecdote (that I did not make up).

When we were in the HQ IT department, working on “Radar Interruptions and False Alarming” 2-year project, the head of our team was 1st Capt. Millers. He was something like a PO (petty officer) in Agile. He said to us: “Men, we were given the opportunity to do something useful for our country. And also get to stay here on a safe spot, so listen up! I have agreed on the foundations of this project, and we know what are we dealing with. Give your best. Stay calm. Write good code. Don’t go into too many details when it is not important. War technology is changing fast, so we may need to redirect the project if it comes to it(like making a pivot in Lean development). That is why I will have few of us always research the enemy radar technologies, and stay in weekly or everyday communication with our Intelligence Committee, in order to get potential redirecting causes as early as possible. Be ready for changes, but focus on the core problem with the greatest strength! First day we will do nothing regular. I want to hear everyone’s idea about how to solve the problem. I want to hear your… Yes private?

Pvt. Carbonic: Sir, I was working in a civilian IT company for 6 years before I came here. The things you mention sound much alike Agile and Lean development that we followed in our company.

Cpt. Millers: Yes, private. But this is the upgraded version. I call it Strength Methodology. Because it isn’t f*g blind, and not a fad. It is bold and true.

Pvt. Carbonic: Sir… *khm… With all due respect, Agile methodologies are synonym of bold (yup, that’s what I thought back then)… It pivots, or how do you call it “redirects” when it sees an obstacle that it cannot take down… It respects individuals in their fields of expertise, it makes a small autonomous team that builds itself as it builds the product…

Cpt Millers: All right… Carbonic. Believe me, I wasn’t born yesterday. I know how they work. Tell me, why do 95% of them fail?

Pvt. Carbonic: Well… I don’t know.

Cpt. Millers: Is 5% success rate enough for us?

Pvt. Carbonic: Well, probably people do not implement it right. I saw a lot of misinterpretations. Companies follow Agile selectively.

Cpt. Millers: People think they are smart! They want to be a part of “what’s popular”. We are not popular. No one will hear about us. It does not matter what people would think if they saw us. We need to finish the job. We need to do it right. We need to be ready for changes. We need to divide the job between us, and to make an estimate about needed time and resources. Call us Agile if you want, but cannot be the 95%. And I do not want to think that I am smart. We need to be that. Pvt. Carbonic, when you are so smart, shoot: How should we solve the problem.

Pvt. Carbonic: Read the field reports daily. Talk with pilots and AA personnel weekly. Use first week on research-only for whole team. No code until week 3. Paper, pencil, people talking.

Cpt. Millers: Is that Lean? Agile?

Pvt. Carbolic: It’s something that gives the best chances to prepare the best design which would minimize number of project redirections in mid and later stages, at least from our side.

Cpt. Millers: Still a smart guy? Let me see 100 push ups.

Pvt. Carbonic: Sir, yes sir.

100 push ups later.

Cpt. Millers: Is that enough private?

Pvt. Carbonic: Sir, it does not matter. I am right. I can do 10 more, but I will still be right if I fall down.

Cpt. Millers: Good joke is always a good argument. At least that’s what watching Senate live has thought me. Let’s try what you said.

Pvt. Carbonic: Sir, it is not something that differentiated from your opinion very much.

Cpt. Millers: Yes… I just wanted to see how you act in “100 push ups” level of stupid situations. You passed.

Pvt. Carbonic: Oh… Did I do push ups for nothing.

Cpt. Millers: Not nothing… It was amusing. And also, you are missing the psychology layer. Be content with “good job private”. OK, lunch, break, we start researching and talking in an hour!