Just returned from the very interesting lecture (by Dušan Omerčević from Zemanta and Andrej Zrimšek from NiceLabel) about Scrum and Kanban development frameworks here in Ljubljana, Slovenia and I am right now thinking about what I heard there and comparing with our approach, what we are doing in out development process.
What I like is this:
- Developers protection from new feature requests while they are in one Sprint cycle. We have this problems all the time (adding new features and breaking the release date agreement).
- What was agreed this exactly will be done – no rooms for changes during the one Sprint.
- No multitasking, doing one task in agreed time period of time. Focus is about saying no to 1000 things.
- Communication, Communication, Communication.
- Doing retrospectives backwards and re-evaluating what was done at the end of each Sprint cycle.
- If we set a rule that we will do only 5 bigger tasks in certain amount of time and if top manager come with new task he must choose which one of previous 5 tasks he will remove to make the place for this new task. Really cool, and make them think.
What I don’t like:
- I felt during the lecture that lecturers talk really slow, like they don’t care at all about the time and I was worried about their productivity in real company environment.
- At the end of the lecture, we have put our questions on the board and they chose 5 questions from 15 and set 45 minutes frameset to go through these 5 questions.
- Even it is very useful framework it also looks to me little bit like bureaucracy if not used in a right way (in a way that real programming hours will decrease in organization and also the lines of produced code).
- I am not sure how this is suitable for small teams (for example, 3 people).
- It is in the humane nature to try to earn highest amount of money for smallest amount of work so I am afraid that people will be happy to have 3-days weekend (if Monday is dedicated for all day meeting and discussion).
- There is a Programming, Motherfucker movement that expose this problem more exactly.
Best practice is to take the best from both approaches!
