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.

  • 11
    I'm afraid if such thing can become a precedence for upcoming, more complicated debates? -- That also violates YAGNI: worrying about a future that might not happen. If you were going to stand your ground, you should have already done so. Commented Feb 6, 2017 at 19:51
  • @gnat: This doesn't appear to be about time constraints. Commented Feb 6, 2017 at 19:52
  • Is being HAL-Compliant not subject to YAGNI?
    – Matthew
    Commented Feb 6, 2017 at 19:54
  • @Matthew the whole thing took one week and I also prepared another prototype using plain JSON just to get rid of HAL, but it was also rejected seen as "not flexible enough". The team modified it and that modified version was finally used. The HAL works for us as a standard, a set of guidelines, and it is easier for me to enforce uniform structure on all endpoints. Previous API was not using any standards and it did not end well. Commented Feb 6, 2017 at 20:02
  • 5
    Flexibility adds complexity. As long of the team understands that, one can move forward.
    – Jon Raynor
    Commented Feb 6, 2017 at 21:28

8 Answers 8


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.

  • 5
    Most people have to touch the stove to learn it's hot and not to touch it. Software is much the same. ++
    – RubberDuck
    Commented Feb 7, 2017 at 10:58
  • 2
    Keeping a project log/diary is key for this sort of thing. Once you have recorded the various discussions that have taken place, they are far more concrete that people's recollections of conversations months or years later. There is a good question on the practice here.
    – Robbie Dee
    Commented Feb 7, 2017 at 11:41
  • @RobbieDee: sure, if it helps the team to learn about YAGNI and KISS.
    – Doc Brown
    Commented Feb 7, 2017 at 11:48
  • 3
    The 3rd bullet (working on your own skills in "selling" a design) doesn't get enough attention. It's why developers still need to have (or work on) good communication skills. Commented Feb 7, 2017 at 18:40
  • @RandallStewart: absolutely. But even with the best communication skills it can be hard to sell YAGNI to people who have not made some experiences by themselves, or confuse it with "quick and dirty", or were educated that "abstraction is (always) good" and so try to abstract things for the sake of abstraction instead for the sake of simplification. Communication needs two sides - one who can explain things well, and one who is willing to listen and understand.
    – Doc Brown
    Commented Feb 8, 2017 at 6:06

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.

  • 1
    Where in the question do you read that the OP's team left the path of YAGNI because of a forward compatibility requirement?
    – Doc Brown
    Commented Feb 7, 2017 at 6:37
  • Forward compatibility is what the Content-Type header is for
    – Jack
    Commented Feb 7, 2017 at 7:38
  • 2
    I am willing to call it something else if you want, maybe extensibility. The point is the same; it is still an NFR.
    – John Wu
    Commented Feb 7, 2017 at 9:15
  • 1
    There are two ways to make a system extensible. Way one is trying to foresee lots of potential requirements changes and make things heavily configurable "just in case". I am sure one can invent lots of acceptance tests for this kind of extensibility. Or, keeping things as simple as possible, so the code base stays small, easy to grasp, and extension points or abstractions can be added later when they are really needed. The latter is nothing you can (or need to) write tests for. Thus I don't think this can be solved easily by "writing unspoken NFRs down"...
    – Doc Brown
    Commented Feb 7, 2017 at 10:07
  • ... so this is more about how to hold a team of maybe creative developers back from making assumptions about NFRs and invent some.
    – Doc Brown
    Commented Feb 7, 2017 at 10:09

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.

  • 3
    +1 anticipating and planing for change is not the same thing as going full architecture astronaut and creating an inner platform. A bit of groundwork right now can prevent a lot of work in the future. While OP's team is perhaps leaning a bit too much into the direction of hypotheticals, a fundamentalist YAGNI approach is certainly suboptimal.
    – amon
    Commented Feb 6, 2017 at 20:22
  • 4
    It sounds more you would happily outvote the OP and make the same mistakes of planning for "what if marketing in the future will.." than the rest of the team. When people start building frameworks instead of application software when the task is to build application software, they are almost always doing it wrong.
    – Doc Brown
    Commented Feb 6, 2017 at 21:41
  • @DocBrown Technically I would agree. This case however seems to be about willingness to facilitate versus demanding personal respect. Being "right" on the one hand versus being useful or helpful on the other hand. What I read between the lines is that the OP is losing ground and chooses to pump up his ego by underscoring his experience to an online audience instead of contributing in an environment he does not feel comfortable in anymore. This dynamic is typical to the introduction of scrum. Commented Feb 7, 2017 at 7:02
  • @MartinMaat I was a bit disappointed by the fact that they disagreed with me. I did not understand why it happened. During everyday work I help them with code reviews etc. We often argue but I like it, because the final result is better; I know that they respect my opinion; I always try to use valid arguments that support my theories. In the end they choose the best option and also take responsibility for it. The team did what it was supposed to do - they solved the problem. It was my and product owner's mistake, that the matter was too broad and poorly described from the beginning. Commented Feb 7, 2017 at 21:50

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.

  • 3
    Democracy is probably the cause of the problem here, but not being democratic is IMHO no solution, because it can easily introduce bigger problems than the ones described in the question - it can actually ruin the team.
    – Doc Brown
    Commented Feb 7, 2017 at 8:41
  • @DocBrown You just contradicted yourself in the same sentence. IMO some decisions are not up to people to decide. What OP explained is one of them. To quote Armstrong for people not using YAGNI: You wanted a banana but what you got was a gorilla holding the banana and the entire jungle Commented Feb 7, 2017 at 8:57
  • 2
    No, this is not a contradiction (maybe I did not express my point well). Things are just not always "black and white". Just because democracy does not work well in some situations, being not democratic is not a guarantee for improving the situation and making things better. It is often not that simple.
    – Doc Brown
    Commented Feb 7, 2017 at 9:45
  • 1
    With democracy you do not neccessarily get the "right" thing you get the thing most of the persons aggree on. And this can be flawed. And often the "right" thing has a problem with social acceptance. YAGNI should not be handcuffs that will hinder you to introduce proper abstractions that will enable you to easily add the "gorilla" or the "entire jungle" if needed.
    – oopexpert
    Commented Feb 7, 2017 at 12:57
  • @oopexpert The problem is: you may need them. YAGNI talks against over engineering. Proper abstractions are one thing, adding stuff that you may not need are different matters. Commented Feb 13, 2017 at 7:23

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.


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


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.


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!"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.