As a scrum master of a small startup made by friends, How do you solve these impediments?

Question

We are a small team of developers(fresh graduates) who have decided to create a software to manage a store.

We have just a small amount of experience in a real world environment of software development.

My idea was to develop this software in an agile way, to deliver it as soon as possible. But two of the developers are arguing about how to define the software's architecture.

Developer 1 : We could use a framework like django rest or something else to speed the development of the API and focus our work on front end / mobile.

Developer 2 : We must use a microframework like falcon to be more versatile also we could use SAM pattern because MVC has some flaws and it sucks.

I know this discussion will not ever end and we'll lose our chance to develop this software since they all only care about planning and documentation. Also only Developer 2 knows about this 'SAM pattern'.

What do you think?

How would you solve this impediments?

Answer 1

This is not a development method question. This is a how-to-get-to-agreement question.

The three of you, sounds like, are equal partners in this endeavor. You need to get to an agreement, and remain in agreement, to get to your finished project. So before you continue discussing project issues, this one and future ones, the three of you need to agree on how to play the game.

So set up some rules of engagement. For example, your first guiding principle is to arrive at consensus on any issue. So each of you will have an opportunity to make a case and then work to agree on an alternative. Second guiding principle might be, in the event you cannot agree, is to vote and then majority wins.

Whatever you end up choosing as your set of rules, you should stop the project until you get this squared away and then restart your project.

Answer 2

+1 on David, setup your working agreements. You don't have to reach an agreement, you need to reach consensus.

When in doubt, experiment. The nice thing about using agile, for your development practices, is the ability to adapt and change.

Ask if there is a way you could do a short experiment with both frameworks. Everyone goes all in for each experiment and at the end you can reflect on both to better decide.

Answer 3

There are some great points above to review.

But to add to this from a Scrum POV you need to remember that Scrum is here to deliver Business Value. No customer ever parted with their hard earned cash to buy an application written in django or a micro-framework or anything else.

You guys are stuck in a mindset where you are putting the technology 1st ... if you want to survive you need to think about your customer 1st!

Remember you can always refactor your code if needs be later on, provided there's business value in it, but as a startup you need to drop the developer mindset and adopt a business one, and fst before you go to the wall!

Good luck on your journey.

Answer 4

You being a Scrum Master, I hope you have already put in place the Scrum rules and ceremonies (described by Muhammad).

To resolve the issue between two of your best guys arguing about technology, be a mediator and pull them into a room. Have them put the pros/cons (eg: scalability, security, time to market, effort to build etc.,) of their preferred technologies on a white board or a piece of paper. When you put your ideas or thoughts on white board it gives better picture of what each person thinks and gives time to reflect on your own ideas. Weigh each of the points for pros/cons by giving numbers. Highest for Pros and lowest for cons. Allow them to speak and discuss about. Are they ready to come to a conclusion based on what is on the board and the weigh points? If they still stick on their stand, then make them realize the importance of moving forward with a decision. How the delay in making a decision could impact cost and market competition (if any).

Answer 5

In addition to what Muhammad said. Get away from concrete positions and point the discussion to find common criteria to which the architecture decision can be evaluated against. With some spike implementation you can measure against these criteria and decide based upon the common criteria. Bear in mind that whatever technology you will use you will learn fast (as you have no experience so far). The solution/architecture/code quality from today will not be appropriate anymore tomorrow. So better be prepared for a continually refactoring and redesign of your solution. Also try to deliver at least some functionality each Sprint.

Answer 6

Due to the context, this may not seem relevant to Scrum but I have seen issues like this arise all the time in scrum teams in the industry.

The issue here is the lack of progress because certain members waste way too much time debating technology (this can apply to other aspects of the work too). Before I share my thoughts on this, a bit on semantics. I tend to use the word "impediment" for issues that arise externally, not within the team. So as Scrum Master, you would remove these external issues and protect the team from them. Nevertheless, this issue also falls within the scope of the SM; you must also protect the business by minimizing waste in the team.

Semantics aside, I think you can indirectly solve this problem by simply enforcing Scrum rules and ceremonies (sometimes it helps to follow things strictly to build that muscle memory; after a while, it will all make more sense). So to give a few examples of Scrum indirectly helping:

• Do you have all the business requirements written in your product backlog? In other words, someone must have spent time with store owners and come up with a list of prioritized backlog items? This someone is the Product Owner, who will have the final say about what should be built. Are these backlog items written as user stories?
• Once you have user stories ready for selection in the first sprint, you have 8 hours of the sprint planning meeting to kick off the sprint. Make sure the team understands the importance of these time-boxes and get them to stick to it.
• Ask the technical team members to come ready to the sprint planning meeting in terms of the technology stack as they would have roughly 4 hours (second half of the sprint planning meeting) to decide how they would deliver the selected user stories and they would even have create granular tasks representing the team's work for the next few days.
• You can also suggest a spike solution.

So although I get your point about this being a startup, but don't most startups have co-founders with defined roles?

So if you are the co-founder and responsible for operations, who is the co-founder and product visionary (the Product Owner)? No harm in these people doing some development too; doing a bit of role play is more productive than just arguing over technology.

At the end, the team may have to decide which co-founder will be the CTO and thus make all the final technology decisions.