First pass
This commit is contained in:
parent
09b0af122a
commit
9ae2c4e0da
|
@ -0,0 +1,75 @@
|
|||
#+title: My Experience with Scrum
|
||||
#+description:
|
||||
#+keywords: blog static
|
||||
#+author: Yann Esposito
|
||||
#+email: yann@esposito.host
|
||||
#+date: [2021-08-30 Mon]
|
||||
#+lang: en
|
||||
#+options: auto-id:t
|
||||
#+startup: showeverything
|
||||
|
||||
#+begin_notes
|
||||
My experience with Scrum in a small startup.
|
||||
#+end_notes
|
||||
|
||||
I was a new recrue in a small startup.
|
||||
I started just about 6 month ago, and we did have a CTO, and 4 CEOs.
|
||||
Part of the team were remote, (the CTO and another member).
|
||||
|
||||
The amount of work was huge and at the same time, I was really motivated
|
||||
coming from a big corp full of mega-boring technology and lacking of
|
||||
talent.
|
||||
|
||||
Here I will regain a lot of freedom regarding my developer environment.
|
||||
A real computer to work with, use the latest techno using the latest trend.
|
||||
But, having 4 CEOs many clients, a lot of concurrency regardings tasks to manage.
|
||||
It was quite stressful and difficult to plan.
|
||||
|
||||
They told us about hiring someone whose responsibility would be to plan the
|
||||
work, because it is a full-time work in itself.
|
||||
They guy looked cool, it told us about how he envisionned the work.
|
||||
It was "mostly" SCRUM, not full scrum. Mainly he will always be the scrum
|
||||
master, he will be responsible of planning, priotirizing and organizing tasks.
|
||||
This was indeed a lot of work.
|
||||
We welcomed him as we our hope was to be able to work on longer tasks than
|
||||
just quick 1-day tasks.
|
||||
|
||||
Now the reality:
|
||||
|
||||
- Every Monday morning was last for planning.
|
||||
- Every Friday afternoon was lost for retrospective
|
||||
- Every half morning was lost in daily standup (instead of 10min it latest
|
||||
generally about 30min to 1h30)
|
||||
- Every week, the 4h work on planning was changed entirely due to new
|
||||
market priorities, so every week we often made an exceptional new task
|
||||
planning for about 2 to 4h.
|
||||
|
||||
To that you needed to add a few meetings, discussion about priorities, team
|
||||
spirit, etc...
|
||||
|
||||
So looking at this you could imagine that I have a totally negative
|
||||
impression on SCRUM faced to the reality of people.
|
||||
Which is mostly true.
|
||||
But scum-like tasks organisation can be great for a few things.
|
||||
|
||||
|
||||
If you really have a clear plan with everyone involved and most
|
||||
difficulties have been though about in advance. This is a killer way to
|
||||
go from "planned" to "reality".
|
||||
|
||||
What is wrong with scrum;
|
||||
|
||||
1. Daily standups suck, this is mostly lost time
|
||||
2. Planning every week/2-week is terrible for medium to long term tasks
|
||||
(see a reference between important vs urgent).
|
||||
|
||||
The main reason full SCRUM is terrible is because it narrow your mind to a
|
||||
sprint-long time to do any tasks. It mixes urgency with importance.
|
||||
And generally, really important tasks to make are left behind, most of the
|
||||
time being put on urgent tasks.
|
||||
Which for most product is terrible.
|
||||
|
||||
Quite often it is better to eat the cake, keep a lot of fixes, urgent
|
||||
tasks on the side to take the time to work on the important stuff.
|
||||
The one that is hard to build, the one that will make the real difference
|
||||
in the market.
|
Loading…
Reference in New Issue