Scrum for Beginners

Are Scrum Meetings Unfit for Small Startups With 25-50 People?

“Are Scrum meetings unfit for small startups with 25-50 people?”

One of my x-colleagues asked me this question. His name is Dave. Dave grew his startup from 3 to 30 people in two years.

Dave had heard some good and some horror stories about how an agile framework such as Scrum can serve or disserve a startup.

Here was my answer:

Scrum meetings are a good fit for small startups with 25-50 or even 100 people also. The purpose of having a Scrum meeting is to identify the problems that will be dealt with by the relevant subgroup immediately after the meeting.

No matter how small or big, businesses are all about identifying and solving the problems and creating value. And, Scrum meetings, often known as Daily Standup and Daily Scrum, are good solution enabler.

During the Daily Scrum, which is time-boxed for 15 minutes only, each team member answers the following three questions:

  1. What did I do yesterday?
  2. What will I do today?
  3. Are there any impediments or blockers in my way?

Scrum is more effective if the team size is between 5 or 9 but if the team size is bigger then there is an alternate called Scrum of Scrums.

By providing focused attention on what each person accomplished yesterday and will accomplish today, the team gains a very good understanding of where the team stands against the set team goal.

If the startup has a clearly defined team goal, then Scrum meetings could be very effective. If the startup does not have a clearly defined team goal, then it might seem like a Scrum fitment issue but in fact, it is the business problem not the process problem.

Nonetheless, it is important to get clear about what Scrum meeting is not:

  1. Scrum meeting is not a status update meeting: In a typical status update meeting, the boss collects the information about who is behind the schedule and sets her on target. In Scrum meetings, each team member makes a commitment to each other.
  2. Scrum meeting is not a problem-solution meeting: In a typical problem-solution meeting, the problem is clearly communicated and various ways to solve the problem are brainstormed, agreed upon and next actions are identified. Scrum meeting facilitates the “problem identification” job, which is usually followed by a problem-solution meeting.

Scrum meeting is a ceremony which cannot fit or unfit. The fitment of a ceremony depends upon parameters such as organization’s belief system, enterprise environment factors, short term and long term goals and the most important, attitude and priorities of the people participating in the ceremony.

Additional reading: My $0.2 on How to Conduct On-target Daily Scrum Meeting.

How to Decide Budget on an Agile Project?

Recently, I was asked these two questions by an Agile enthusiast who works with a services organization and have recently started practicing Scrum.

How do I know the budget without having to analyze all the features, especially when the feature list is too long and can’t fit in a sprint of 2 weeks?

The answer I gave was well received. Not because it was right from the process perspective but it was effective from the business perspective.

My simple point was: Who would disagree with the fact that processes and frameworks are created to serve the businesses and not otherwise?

Read on for the answers.

There is no way to know the budget without analyzing all the features. If the project is big and feature list is long then it gets even more challenging.

How to Deal With the Budget Problem When the Project is Big and Feature List is Long

  1. Analyze all your features
  2. Estimate the project as you’d normally do (using any conventional, non-agile methods that you’re comfortable with)
  3. Calculate one-month time-boxed cost of iteration. Refer to this excellent article by Jesse Fewell on the subject: How to Calculate Budgets for Agile Teams (Disclaimer: My entry in agile world is thanks to Jesse so I might be biased but his words of wisdom are way beyond any biases. Any Agile practitioner would vouch for his contribution in the world of Agile Software Development.)
  4. Now you have calculated your budget using two different methods. Use a variable factor to deal with uncertainty, that will come up
  5. This way you’d know how much margin you’re going to keep – now, you can make an offer that makes the business sense to your service company

When we execute a project using Scrum, the opportunity is to retrospect at the end of each sprint and ask ourselves:

  • Are we going in the right direction?
  • Did whatever we do in the past sprint is of any value from the business perspective?
  • … and take corrective actions.

In theory, taking corrective actions means that you can stop developing further or pivot if the business value is not found in the delivered increment. Practically, many people (and companies) fear that practice. Which is normal because in business we need predictability although we know that life itself is not predictable. It’s agile!

So, business-people want predictability and budget is one such practical problem so rather than dealing with that problem using agile techniques, we can choose to deal with it using any technique that works.

Sure, since we’re considering Agile, we’d get the cost of iteration and add a variable factor to make some changes but it is, at its best, a kind of guesstimation.

This is not a perfect way. This is not where you will get optimum value from Scrum. Scrum framework is effective when the focus is on delivering value, not on finishing something by the budget.

If you can, avoid Scrum – or other agile practices – for these kinds of projects. If not, then you can tweak but in that case you’re not using Scrum – or agile.

Also in some cases, the clients of a service provider company would not much care which development framework the service provider uses. All what matters to them is how you will deliver the value. So make an offer to them that they cannot refuse.

  • Is this Scrum? No.
  • Is this Agile? No.
  • Is this business? You know it better 🙂

In my opinion, when not to use Scrum is a distinction that every practitioner must have because then Scrum remains a tool, not a magic wand.

The war has to be won; does it matter if you win it using Swords or Guns?