The Daily Scrum Meeting is one of the ceremonies described and used in Scrum.

It’s a meeting made every day at the same hour in the same place.

The goal of the Daily Scrum Meeting is to answer to those 4 questions:

Each team member must answer to them. And it’s also a moment to move your sticky note on the Scrum Board.

So why is it useful in a startup?

Because, it’s a privileged moment for you and your team to make them talk about what they do. I know that most of you will reply that in a startup we work together all the time and that it’s not necessary to make a Daily Scrum Meeting because you know what your team do and that you have only one person in your technical team.

But what I mean it’s to enlarge your Daily Scrum Meeting to all people of your team: marketing, technical, etc… Your Daily Scrum Meeting must be a break with your team, a moment to stop the work to make a clear, concrete status of your project, to connect different people in order to let them helping each others.

This a major point: make your team a real team where people help other people.

The main risk is that the Daily Scrum Meeting can become a brainstorming meeting. But as a Scrum Master (project leader or technical leader) you can avoid this by doing a fast but concrete Daily Scrum Meeting.

Let us know your point of view

I became a Scrum practitioner, I asked myself why in France most of startups don’t use Scrum as a methodology.

Scrum looks like a method created for startups in my mind, so why few of them use it?

In France’ context, Scrum is not so popular as in other countries but it begins to become a known and popular methodology. In a startup context, Scrum can be very useful because the principles are simple and practical: it’s not just about theory. Remember the key notions of Scrum:

• Iteration
• Customer ‘ focus
• Visual management
• Communication.

Iteration…

In a startup context, iteration is the key because if we plan something for 2 or 5 years, we’re sure that some other people will develop the idea before the beginning of our work. So the key is to use iteration as a driver for the development of our idea. In a small, very small sprints, we can deliver faster a “functional product” that users can tests and it can bring us feedback easily.

Customer’s focus…

This point can be very difficult for a startup because in this case the customers can be a million of people. In fact, listening, working and understanding a million of people can be very difficult. But not really! We have the chance to have with social media for example, the needs of our customers directly: what they except, what they like, what they don’t like. If you choose the right PO (a community manager, an UX designer, or you as a project leader), you can treat better those needs and focus on the right purpose.

Visual Management…

What is not really appropriate in a startup is to use classic methodologies to manage the project so a clear and simple visual management is the key.  The ScrumBoard can be very useful for many reasons and give a simple view of the project status.

Communication…

Communication is one of the success key in every project. And it’s also true in a startup, even if we work in the same place, or connected by phone, mails, and so on. But we are talking about the large communication in the team. Most of time, in a startup the technical people don’t know about the business issues because we want to keep them focus on the technical development of the idea. But in fact, it’s important to involve them in this too. They can be more motivated and focus on the global project and most of time, they are also the end users as the project leader.

So Startupers think about what Scrum can bring you in the success of your project just by the simple use of the key principles.

The Product Owner is one of the 3 main roles proposed by Scrum and not the last one. It’s an essential on because it’s the product business vision and customer representative, so it’s the factor “Decision”. During the implementation of the method in a start-up, you must quickly identify this role. But who can be the Product Owner?

The quick answer would be: the project leader but is it really relevant?

There are several definitions of responsibilities and skills of a Product Owner. For me it’s the first person that brings the vision of the product through its good knowledge of business domain (often he is a user from the previous version). But this is not the only characteristic of a Product Owner, he has to update the product backlog and adjust priorities, answer questions about user stories, accept or reject the results regarding the acceptance tests, etc…

In practical terms, in our application of Scrum at the StartupWeekend, the absence of a Product Owner was the blocking point of the weekend. The facts are relatively simple; it’s difficult, at least in this format to determine who the PO is. By being 2 project leaders, we thought we could keep our business vision of the product or at least that one of us had always this vision clearly in mind. Initially, this isn’t necessarily complicated, but when everything speeds up (evolution of the idea, constant feedback, coach advices, etc.) the role of PO become suddenly more complex because the vision of the product continually changes in 54hours. So those constant changes make the Product Backlog uneasy to build. Flexibility and scalability are often strained during the weekend; you have to constantly adapt your product to the feedback provided by coaches, team members. We failed sometimes to take stock during our weekend.

StartupWeekend is an accelerated focus on the great moments in a Startup life. And in our after StartupWeekend, we face similar problems, mitigated by the fact that the timing is different. The problems of a PO in Startup are not quite the same than usual. Our issues concern a too shared vision, too productive exchanges, so unstable backlog.  That’s why choosing the Product Owner is very important because its task will be to constantly strike a balance between vision and brainstorming in order to determine and fix the product backlog time for a sprint.
So we can ask the question of who should be the Product Owner in a Startup.

The project leader: This is relevant in view of his vision of the project. But this vision is so advanced and business needs can quickly become unclear. Is it best suited to this role as an analyst?

A business analyst: Again, it is relevant in terms of its domain knowledge. It will be better able to contain and direct requests from brainstorming to keep it in the context of the domain.

A UX Designer: An interesting case which appears more and more often, and which allows for a very close to the PO customer needs because he himself is a follower of that vision. It is also a specialist in user stories.

Personally, I really think that moving towards a good UX will bring you near the success if not a great success. 
Then a slight preference for UXPO can be a guarantee of a product even more user-centric. I think however, if the most common, is a promoter PO, and then it will be very important to keep a vision “final” product. 
As part of StartupWeekend, it is strongly recommended to choose a PO that is not one of the promoters. They will work together and draw in the same direction, but as a project manager you will always want to try to deliver the best possible product to juries on Sunday probably forgetting to fix your product vision for your team.

At CheckMyEvents our vision is a little a mix of both, because we are two project leaders, and both with a particular sensitivity to the user experience and both with a business vision (at least we try ☺). Our difficulty may be to keep this vision end user while the project leader.