Scrum and Kanban development frameworks

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:

  1. 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).
  2. What was agreed this exactly will be done – no rooms for changes during the one Sprint.
  3. No multitasking, doing one task in agreed time period of time. Focus is about saying no to 1000 things.
  4. Communication, Communication, Communication.
  5. Doing retrospectives  backwards and re-evaluating what was done at the end of each Sprint cycle.
  6. 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:

  1. 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.
  2. 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.
  3. 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).
  4. I am not sure how this is suitable for small teams (for example, 3 people).
  5. 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).
  6. There is a Programming, Motherfucker movement that expose this problem more exactly.

Best practice is to take the best from both approaches!

programming-motherfucker

You may also like