Moving beyond the Scrum

I used to be a firm supporter of Scrum process. I was deeply convinced that Scrum's approach makes total sense and is the right one. My impressionable attitude has changed with time. Now I see that "pure" Scrum is a quite rigid process which not always fits the best our specific type of work. What is exactly on my mind?


Scrum is stopping us from higher productivity


Sprint length is derived based on project's life expectancy. Having at lest 4-6 sprints within the project is an absolute minimum. Usually we are choosing from two options: one or two weeks for sprint. Unfortunately there are some issues with both options:

• One week sprint gives us only 4 days of development so one day is "wasted" on Scrum related activities. 20% of our time, it's quite a lot.
  
• With two week sprints there is still one day devoted for demo, planning session, retrospective etc. but ratio here is 9 to 1. It's a significant improvement but in the same time we have to deal with new issues which are more evident for two weeks sprint.
• Unchangeable sprint plan - sometimes it happens that somewhere in the mid-sprint all stories are done or blocked by some external dependency with which we can't do anything. Because we can't add new stories in the middle of sprint and we can't proceed with blocked stories we are forced to fill our time with "other stuff".
  
• Another absolutely normal thing is that some new, very important and extra urgent things need to be done ASAP. We can moan that things like that shouldn't happen but in reality they happen so we have to be prepared for it! Scrum's answer to situation like this is "we will take care of that in next sprint as current one is already in progress" or "we can stop this sprint, run planning session again and incorporate this very urgent story into sprint plan". Both options are not good enough, replacing one story with another of similar size in the mid-sprint doesn't hurt the team and in the same time can address important requirement. Scrum is not very flexible here.
  

Even though there are some issues with Scrum I don't think that we should look for some revolutionary changes. This process works, we just need to tweak it in order to make it more suitable for our projects. Here are a few ideas to consider:

• Do we need a sprint planning sessions? For sure we need prioritized product backlog to know which stories we should work on in the first place. On planning session we will either overestimate (stories which are not done by the end of sprint will be moved to the following one) or underestimate (and then we need to add some stories in the middle of sprint), priorities may change (stories swapping) therefore plan is very likely to change. Maybe it's better to simply use product backlog as a queue and finish as many stories as we can during the sprint?
  
• Retrospective meetings - they are very beneficial when project starts but when it's closing to the deadline they are getting less and less valuable. Maybe it should be team's decision if it makes sense to have such a meeting? If something is going wrong and it's obvious to everyone why should we wait till the end of sprint with retrospective?
• Demo - usually we want to have implemented functionality available to the client as soon as possible so maybe instead of delivering new stories after one big demo we can have number of small demos and this way be more responsive?
  

Probably the most important thing which I have learned from Scrum is that we should keep looking for things which can be improved and experiment with the process. So if answer to some of above questions is positive then maybe it's time to move towards more lean processes? Scrum-ban? Kanban?


Last words ...


I have been using Scrum with different deviations for about 3 years now and I still think that Scrum has a lot to offer. The thing is that it doesn't have to fit perfectly for all types of projects. I think I can say that I'm still a firm supporter but not so impressionable any more.

It seems that more and more teams is already moving along this path:

• From Scrum to Kanban
• Moving to Kanban, Did Scrum Fail?
• 5 Practices Better to Change in Your Scrum Implementation
• The Current Direction of Agile
  

Are you Agile?

This simple question can lead to really heated debate. It's so, because the idea about what the Agile Software Development is can vary significantly among the people. To answer question "Are you Agile?" you have to first define the minimum criteria for being Agile, here is a list of potential candidates: self-organizing teams, incremental development in short iterations, high responsiveness to changing requirements, continuous adjustments, everyday contact with stakeholders, pair programing, TDD, (automated) testing and so on ...

The list may actually be much longer. Those are all desired practices but surly you don't have follow all of them to be Agile right? I figured that the best way to sort out this puzzle will be to check the basis - The Manifesto for Agile Software Development and Principles behind the Agile Manifesto.

What is not there:

• nothing about pair programing, TDD and testing although "Agile processes promote sustainable development" so you don't have write tests and still you can say that you are Agile ;)
  
• surprisingly, short iterations are not a must but remember to "deliver working software frequently"

What is on the list:

• "highest priority is to satisfy the customer" - this is our main goal, in the end ... they pay for our time.
• "business people and developers must work together daily throughout the project" and "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation" - which means that you should avoid, whenever possible, writing documents, emails, using Skype or MSN. Talk to team-mates and stakeholders, ask questions and be proactive ... if you can't talk face-to-face then try to call someone rather then writing an email ... it might be much harder as it requires more effort but it also gives the best results.
• "working software is the primary measure of progress" - I like this rule as it clearly states what really matters ... our job is to deliver working software, not just a random number of classes or lines of code ... job is done when your software works as expected by stackholder and is available for others.
• "simplicity -- the art of maximizing the amount of work not done" and "continuous attention to technical excellence" - this prevents people from releasing shitty software and saying that Agile is about delivering something fast and then improving it later. Agile Development can't be an excuse for poor design and low quality.
• "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" - this principle is absolutely essential, if you follow a rigid process it's obvious that you are not Agile. Agile is about striving for optimal effectiveness therefore you have to be flexible, you have look for ways to improve the process you follow.

So are you Agile?

I my opinion there are two rules which have to be followed to answer "Yes":

• deliver frequently - it guarantees frequent feedback and gives confidence that you are still on track with time and requirements.
• adjust the process to be more effective - you have to constantly try new things, experiment how to make you work more enjoyable and effective.

What criteria do you use to call a process Agile?

Scrum - why extending sprint (iteration) length is usually not a good idea

I have to admit -- I'm a big fan of short iterations and I have plenty of reasons for it! But what does short mean? In most cases 2 week iteration is a good start. You should consider shorter iterations only if rule of having at least four, five iterations within a project can be broken, hence any project shorter then 8-10 weeks is a potential candidate. On the other hand, big, 6 months and more, projects should consider 3 week iterations ... but only ... I repeat ONLY ... when you are sure that scrum and in general agile software development process works for you and you are happy with the results.

How can you know that scrum works for your team?

One thing has to be clear -- you don't have to use pure scrum to make it work for you. Sometimes applying only some aspects of agile software development is the best approach and it doesn't make it any less agile. Fundamental thing about being agile is improving the process, so get rid of things that doesn't work, experiment with new ideas and learn!
It's often the case that people feel that there is something wrong but they can't really say what exactly therefore I highly recommend watching this presentation: "10 Ways to Screw Up with Scrum and XP". Also you can find more materials on Henrik Kniberg's blog. Check if you find your problems on this list, check if you follow fundamental scrum rules.

Why short iterations are better?

I stated before that I have plenty of arguments ... so here is a list:

1. The most important one - short iterations allow you to find problems early, always look for problems and remember about the rule: visible problem = killable problem. If your team is aware of the problem then there is a good chance that they can cope with it. Treat problems like a opportunity for improvement.
2. With short iterations new ideas and improvements can be applied quicker. After each iteration you should have a retrospective meeting to identify problems and figure out how to improve the process for next iteration. Short iterations mean that you can improve more frequently.
3. About certain problems you can learn only after full iteration ... for instance common problem is that people don't work as a team ... each person has it's own task and at the beginning of a iteration all stories are in progress. Sounds good as it means that whole team is working and is moving forward but actually it's not good as you can't really say how many user stories will stay in progress to the end of iteration. In worst case all stories are 90% done by the end of iteration which means that from a client perspective this iteration didn't add any new functionality, any releasable code, any new value.
4. Estimations and velocity - at the beginning of a project how can you provide reliable estimations? How do you know how long it will take to deliver whole system? At the beginning you don't know much about team's performance, you don't know how cooperation between the team and a client will be looking like. So probably you can't provide any reliable estimations ... you can only guess. But first few initial iteration should give you good idea about team's velocity which should result in much more reliable estimations ... now you can figure out what should be done in next two, five or ten months. Sounds like a useful thing?

Are you convinced? I hope you are ... if not ... then challenge me and post your arguments! Maybe you can persuade me that I'm wrong :)