Former startupper, Gregoire started working in digital 6 years ago. Since the closing of his startup Sharette (in 2016), he’s offering his services as a freelance consultant, sharing the experience he gained with small and medium-sized companies, and even big corporations: Open Innovation programs, Scrum/Agile coaching, digital marketing strategy (acquisition funnel, SEO, SEA, …).
Exploring Agile
I discovered Agile methods and more specifically Scrum when I launched my startup in 2012. Like everyone else, I had heard of it. But like everyone else, I didn’t really get it.
I was initially trying to define the best governance model in order to optimize the functioning of the team, without wasting people’s time or the company’s. The question was: when to gather who and what for?
The developers of the team told me about it, as Scrum is specifically well fitted for digital teams composed mainly of developers, and including a product owner. It was exactly our case. Plus we needed to constantly develop and test new functionalities.
Getting started with Scrum
Let’s be honest, I didn’t know anything about Scrum. I started reading articles and talking about it with the team and other entrepreneurs who were experiencing similar situations. I learned and trained myself on the field.
We started implementing meetings and made them evolve over time. For instance, at the beginning, we had weekly sprints: the sprint planning was taking place on Monday morning and on Friday afternoon we had our sprint demo and retrospective. But I soon realized that one week was too short: too often, developers were saying that they didn’t have time for the Friday retro as they had to finish working on tasks.
In the end, we adopted this format:
- 3-week sprints (in general)
- In the morning of the 1st day: 4-hour sprint planning meeting
- In the afternoon of the last day: 45-minute demo followed by a 45-minute retrospective
- Every morning of the sprint: short daily meeting at a set time
These meetings included the developers (the “Team”), the product owner (making the link between the Team and the client), and the Scrum Master (bailer of the methodology, rotating among all the developers).
Improving our Scrum practice
One of the things we struggled most with was the sprint planning (and we’re not the only ones). We had a hard time dividing up the work into well-defined stories that were achievable during the sprint. Little by little, we started calculating/assessing the complexity of each task.
The complexity assessment is a very effective Scrum technique in order to better allocate the team’s time and effort. The idea is to break down each high-level User Story (also called an Epic) into smaller tasks, and to evaluate for each task its level of complexity using the Fibonacci suite: 1, 2, 3, 5, 8, 13… The gap between two levels of complexity grows bigger as the complexity increases, which forces the team to make a real choice. Any task above 8 should be broken down again.
1 = it’s very easy, I know how to do it and I’ll do it quickly.
2 = I don’t think it’s very complex but I have a small doubt.
3 = it’s rather easy but I need to do some research.
…
The product owner constantly receives feedback from the client on the new functionalities. He shares them with the team at the beginning of the new sprint. He also adds new ideas in the backlog every day, and order them by priority.
We also got stricter on the last day, even if everything that was planned during the sprint planning isn’t finished. On the set day, we stop everything and we compute the number of complexity points we managed to overcome, called the “Velocity”, in order to plan the next sprint. If the sprint was well planned and team members got exactly the right amount of complexity points to work on, this velocity can be used to plan the next sprint. Otherwise, the product owner can increase or decrease it, based on the team’s feedback.
Another trap of Scrum is the daily meeting: not having a fixed time, taking it for an operational meeting instead of only sharing information, and being too long. Over time, we chose a fixed hour in the morning (between 9 and 11 am depending on the team), and everyone was supposed to share his or her progress and difficulties in no more than 1 minute. Operational work was left for after the daily.
The limits of Scrum
Of course, it couldn’t be all rosy. Scrum is amazing in some contexts:
- Digital projects with a level of uncertainty
- With a Team (= developers) of 15 people maximum (if the team is bigger, it should be divided into smaller squads)
- The team members should be dedicated to the project (working at least 50% of their time on it)
- The overall project must be divided into blocs (the stories) with regular releases and deployments
- Even in other areas of the company (marketing, HR, …), as long as the team isn’t in charge of long actions constrained by external dependencies
but impossible in others:
- If the project cannot be divided into small pieces
- If the team cannot get regular user feedback
- If developers are spread among several projects
- If the project is constrained by external dependencies
Source: http://scrumreferencecard.com/scrum-reference-card/.
Testing other Agile methodologies: extreme programming (XP)
We never used eXtreme Programming in my startup, but I experienced it with one of my clients. The principle of XP is to divide the Team into pairs: one developer does the coding, and the other one reviews the code along the way. And the tandems rotate at the beginning of each sprint.
It may seem a waste of time to have only one developer out of two actually coding – many think so. It’s true. But this methodology has a lot of advantages:
- It helps produce a code of higher quality and stronger, thus ultimately it saves money.
- It reduces the need for maintenance.
- It develops the competencies of the whole team, and developers love it.
- It fosters collaboration and friendliness among team members as they know each other better.
Over the last few years, I’ve had the opportunity to work and implement Scrum in several teams and companies. In the end, the most difficult in Scrum or other Agile methods is not to understand them, but to put them in place and to keep the rigor over time. But when you do so, it becomes an amazing playground!
Want To Improve Your Agile Retrospectives?
Download our free Retrospective Outcomes Canvas
Get our free retro canvas