I just watched an hour long video of a lecture given at Google by Ken Schwaber, one of the co-founders of Scrum given in 2006. At first I was daunted by the length but Ken is an entertaining speaker and I felt that many of the points he makes are worth hearing.
Here is the video:
Ken starts from the very beginning on the Scrum framework, where the name came from, and then addresses how Scrum either works, or doesn’t given management, the team and the organizational effectiveness or culture.
Here are my notes from the video:
1) Scrum is a method developed from the experiences of those in cross-functional tight deadline competitive environments and was developed through collaboration based on a collection of best practices.
2) During Scrum employees should not be interrupted and should get any resources they need because they were working on something critical for the company.
3) The key aspects of scrum:
- Everything is a time-box so that things don’t go on forever.
- Everything is done with cross-functional teams that are responsible for managing themselves. The best people who can figure out how to do the work are the people who are doing the work themselves.
- It’s a team that has to have something done at the end of the time-box and can potentially be shipped.
4) SCRUM is used to manage product development. SCRUM is not a methodology. If you have a question on what to do you see if it fits in the framework. There are not many rules but you can find detailed strategies that others have discovered works for them. It is like chess; how you play it is up to your own intelligence, skill set, etc. You will know right away if the project is a non-starter.
5) SCRUM frees us from the belief that someone has to tell you what to do in every situation.
6) You want transparency during Scrum. Know exactly where you are at the end of every time-box. Even idiots can do SCRUM they just produce crap. You know if you have a bad team right up front.
7) The Scrum Process:
- Start with a prioritized list of stuff that needs to be done. Most important or highest risk etc. This list is used for starting iterations.
- A cross functional team of people gets together with the person representing the customer. This team says how much they think they can do in a sprint. (his favorite – 30 days) where done means that the product is ready to be used for that product.
- Then the team goes off and has a whole period with minimal interruptions.
- At the end of the period the team shows the customer what they have done.
- Each team member must exercise their profession competently.
- The customer must accept the finished work.
- The process starts again.
- The process allows you to hone in on your target.
- A few rules – feedback loop – deals with adapting to complex changing environments.
- Can’t have feedback without a finished product – can’t have PowerPoint’s of what we plan on
- Every day the team gets together and makes transparent what they are doing. Synchronizes the team on a daily basis.
- It has some rotten things – like finding out the person that you are counting on will not do what they are supposed to do.
8) Burn down – amount of work + estimated + ability of team to transform it into product that is ready to ship = Burndown. A Burndown graph can predict when the product will be ready.
9) You can tell after a couple of months where the release is heading:
- The trend can tell you early on if there is a big problem as the trend line will let you know if you are on target.
- It gets all of the news visible whether it is good or bad. Intelligent people will want to do the best thing for the organization. It is a test of the character of the organization on whether they can successfully implement scrum. Do they have the capacity to handle the news and do something about it?
- What happens when bad news about the trajectory goes to management? They ask you to increase your velocity.
- The assumption is that you can always work harder or you are “not on-board”. We have time honored conditions for increase velocity – drop quality/cut corners. Not do unit tests and automated tests. We can work long hours. Scrum should have a sustainable pace. Downtime allows an employee to work on the problem while they are not working. Longer days increase defects. Longer hours and cutting quality produces more crap.
10) Common problem with every organization is the lack of support for Core or Infrastructure Software. On a Burndown chart the developer can develop quickly but the velocity of the core software is very slow. Core software has three characteristics: 1) it is fragile – change one thing and it breaks other things 2) it doesn’t have good automated test harnesses around it so you don’t know if code changes will break things until it does 3) Only a few suckers left in the company that knows how it works and how to maintain it – everyone else fled. This lowers the velocity of changing the infrastructure. New stuff is constrained by the core functionality.
11) The deterioration of quality in software development:
- If you cut quality than over about five years the velocity will decrease anyway because the code base that you are working from has deteriorated.
- Book recommendation: The Innovator’s Dilemma
- Management thinks that they are magic – just ask and it will get done faster. People will automatically cut quality if they are forced to make a choice between this and delivering late.
- Another option is to cut (scope) functionality. This is management’s other option. Overall, 65% of delivered functionality is never used, . Management will be forced to look at what they can deliver that has the most impact given the velocity rather than just giving the team a laundry list.
- SCRUM is about managing big changes – incrementally, iteratively, through self-managing team and transparency.
12) The Scrum Master (the prick), this person’s job is to make sure that you don’t cut quality. They have no authority. If we have defined a certain level of quality then they have to make sure the quality is there. If the quality isn’t there than you cannot demonstrate it. They are the least loved person in the world because they stand right at the nexus of product management believing that any amount of stuff can be done and our willingness to cut quality to help them support that belief. The burnout rate is usually like, 13-14 months. We get them from hopeless professional areas like QA. People from QA are used to doing incredible things with no authority, no respect, and no hope of success. So that is where we take these people. (He is joking here but also serious about QA people making good Scrum Masters).