Scrum team not following the YAGNI principle

Question

On a SCRUM meeting the product team was debating about a feature on an API that will be consumed by mobile app. We had a mock up that showed how the screen should look like and what key elements it should contain (a "layout").

Based on this and the discussion I had with the product owner I created a prototype for an API response (HAL+JSON). It was very simple, HAL-compliant JSON that did nothing more than represent the things that were on the mockups. I did not get influenced by the future ideas that were foreseen by business people as they have tendency to change their ideas often and I decided to take the minimalistic approach. My proposal was rejected by the team and I've been outvoted 7 to 1.

The team decided to use more complex, non-semantic abstract json structure, that allows for more flexibility in arranging of the layout. The downside of that approach is we ended up with a set of uniform objects that may have null and empty properties by design. They also thought it would be nice to make A/B testing possible, yet it was based on their predictions only as we had no such requirement.

Most of the time we were debating about things that were not a part of the sprint nor mentioned on the mockups. The described problems were "what if marketing in the future will ...", "what if the business might want us to ...".

I and the product owner are experienced programmers and we've seen these kind of problems in the past. We try to follow the YAGNI and KISS principles. The rest of the team is a bit less experienced and although they know these principles, they seem not to understand them.

We agreed on their solution as the team as a whole is more important for us and we did not want to fight over something that is not that important. But I'm afraid if such thing can become a precedent for upcomming, more complicated debates? How to deal with such behaviour? Is there anything that I, as a team leader, can do better?

It's worth to mention that the product is an early-stage MVP.

Answer 1

I feel your pain, have been there. IMHO these kind of problems are caused by the fact you have a team of 8 persons, which is already too big to let you always come to the best strategic decisions.

In a team of size of 8 or more chances are high the number of mediocre programmers is higher than the number of experienced ones. That will often lead to situations where the better decisions are outvoted by mediocre ones. That does not sound satisfactory, especially when you are (or think you are) one of the more experienced guys, but at least the same is often true for really bad decisions.

Fact is, there is not much you can do about it as long as the team does not change, at least if things shall stay democratic, so either

• learn to live with it
• work with the team for one or two years, share your own expertise and hope they learn the value of YAGNI and KISS over time
• work on your own skills of "selling" design or strategic decisions to the team
• try to switch to a different (maybe smaller) team where your own level of expertise is nearer to the average of the whole team

I think the only way to learn and understand the real value of a minimalistic approach and YAGNI is by making some experiences first hand. For example, by getting involved in maintainance of a legacy system with a lot of wrong "what if" predictions, wrong design decisions motivated by "just in case" arguments, or containing lots of overgeneralized framework code which was actually never needed. But that is nothing you can teach your team members in two days, some experiences people have to make by themselves.

Answer 2

Forward compatibility is a legitimate concern

If one of the seven developers who outvoted you is the architect, it is his right to introduce NFRs as needed, and one of those NFRs could be "forward compatibility," especially when you are supporting a remote system component that might have a more sparse release schedule. You don't want users to have to install a new version of an app because you didn't think ahead.

Like other requirements, you need acceptance criteria

That being said, any NFRs must be documented as requirements and must have defined acceptance criteria. Also, you must come up with a means of testing them. That is why YAGNI is important-- you don't want to write code that can't be tested, and if the only purpose of the code is to support a feature that nobody is using, it is difficult to test.

It shouldn't be a judgment call

I would suggest you get the team to agree on the unspoken requirement that you apparently missed and get it written down. Once you have defined a means of testing it, your implementation should fail at least one test and therefore it shouldn't be a matter of voting.

Answer 3

It sounds like your development team is trying to facilitate the product team by creating a framework that allows them to do quick trials, which is apparently what the product team would really love to have. Your approach is more like "literally give them what they ask for and don't think for them".

If I were the product owner I bet I would be a lot happier with a development team taking the first approach than the latter.

Answer 4

Well, my opinion is democracy isn't working properly - neither in political system, nor in a team where most programmers are junior or mediocre.

Your word, as a team leader, and one of most experienced people in a team, should have higher impact then the rest of the team. If YAGNI is important for you, then you should make a presentation about it. Discuss about it, and show them why is it good.

After all, your responsibility is higher then for other people. It is not only to write code, but also to guide people.

Answer 5

It think there is a little confusion about YAGNI.

Developers often think they follow YAGNI when they omit abstractions that will keep the system "closed for modification and open for extension".

Unless you do not "extend" the system with an "obviously" not requested functionality you do not deal with YAGNI. Introducing abstractions where extending might occur is the already mentioned "forward compatibility".

My personal opinion is that only a profound knowledge of the domain will help to make decisions of abstraction and where to locate it.

Answer 6

The trouble with YAGNI AND KISS is that they are completely subjective and vague.

json?? YAGNI! just send a csv string!

objects?? KISSTUPID!!! just use gotos!!

The 'Team Leader' role isn't well defined, but I would suggest that you distance yourself from expressing subjective opinions on your teams technical choices. Even if you feel they are wrong. Stick to a short list of well defined requirements.

• unit tests for code
• integration tests for apis
• automated UI tests for the end product
• performance and scaling requirements

if the team can achieve passing tests for all the business requirements and basic performance at scale technical requirements you have a working product.

After that its just pushing to do the same but faster

Answer 7

Everybody in the team must agree on the definition of done. Without this, you're prone to massive amounts of scope creep, points of view and bastardisation of the core requirements.

Anything delivered over and above this must be on the backlog which will itself also have its own definition of done.

As for priorities, the MoSCoW method has always served us well - YMMV.

Answer 8

My first thought about this is...Why is the team concerned about changes? Do they have some historic understanding of the Product Owner that makes them feel like they need to build the first solution to be a bit more configurable to make future enhancements easier? If your solution would take 2 days, and theirs 5 days, yes, it's over twice as long. But if alteration of your plan would take 2 days each time, but an enhancement to their would take 1 day, their plan does seem more efficient over the long haul. I don't think there is a RIGHT or WRONG decision in this question. It depends on other factors, IMHO. However, you are RIGHT about this mindset if on other solutions they double the LOE without any direct guidance to do that (some evidence that the additional complexity is required for scalability, robustness etc). My suggestion would be to bring the product owner into these conversations, because they need to help with prioritization. If your solution is 5 points, and it would meet the need now, but what they want to do would require 50 points and two sprints or more, the PO may say "hold on, we have a high priority release of this MVP planned and can't spend 2 weeks building out functionality that isn't on the roadmap!"