After about a year of working with an ‘agile by committee’ development methodology that was going along quite well, a couple of things happened at the startup I work with.
(1) We found a CEO who is one of those rare people blessed with considerable technical, business, and managerial ability.
(2) We acquired the IP and developers of a very exciting technology that could leverage our existing technology to make a killer app. That technology was being developed for an enterprise product, and their process was much more waterfall because they had to completely understand and respond to customer feature requests that were very detailed and tied to a lot of money.
After about a month of thrashing around, the CEO declared that we would all be using Scrum. There was some hysteria and some drama from the other team as they flat out declared that moving in such small iterations (1 month) would not allow them to think their problems through. Another CEO would have thrown in the towel, but ours had seen Scrum work, at scale, across multiple teams, all doing invention based work. So he held his ground. I for one was skeptical about Scrum as well, mainly because I thought our process was just fine. However, I thought about our process some more, and found the following flaws:
- we weren’t moving from well defined requirements, they were being made up on the fly.
- we weren’t having the right discussions with the right people in the room. High level discussions were being had while developers who really didn’t care about details they considered ‘lipstick’ were in the room. Low level discussions were being had while program managers, who didn’t have the technical chops to keep pace with the conversation, kept interrupting and throwing everyone off.
- Our iterations, which were 2 weeks long, were too short to show visible progress.
So, long story short, this is what I’m liking about Scrum:
- A month of development with a demo at the end is a really nice rhythm to follow. 2 weeks was too short. Anything longer than a month is too hard to plan for.
- Product Owners own the vision and the final output of the product.
- Dev teams own the implementation of the product.
- Product Owners are not allowed to inform, change, or participate in product development after the sprint planning meeting — the “Chickens and Pigs” rule. This separates concerns quite nicely. Product owners care about the final product, developers care about the day to day details of making that final product, and the iteration deliverables are what everyone agrees on.
- The Sprint Planning meeting requires that there is a Product Backlog in place that is actually understood by everyone on the team. This is a forcing function on Product Management to get their shit together and hammer out concise, complete requirements.
- Estimating tasks for the next month forces devs to think through initial implementation much more deeply than if they were following a waterfall methodology. This leads to more accurate estimates.
- By the same token, they don’t have to know everything up front. The process allows for tasks to be added by the development team if the agreed upon deliverables require more work.
- The Product Owner cannot change the iteration deliverables once the iteration has started. This provides the stability that allows a dev team to make rapid forward progress without thrashing.
- Tracking progress and updating progress is extremely low tech — a board with stickies on it is easy to look at and easy to update.
- The board is an information radiator. If the iteration is going badly, it is immediately obvious from the board. Same if it is going well.
A week into adopting the scrum process, we were sitting in a room with a product owner and 4 devs, trying to hammer out a solution. This is actually a violation of (4) above…and it showed. The product owner didn’t have the technical depth to add value to the discussion, yet she felt the need to comment frequently, and her comments, which were not very relevant to the technical details of the discussion, kept derailing everyone else. After the initial meeting we realized our mistake and had a dev only meeting, and resolved in 10 minutes what was taking us over an hour. She wasn’t too happy about the fact that we met without her, but we were doing the right thing, and the rate of progress showed it.
Scrum is the right separation of concerns. I know from writing code that when I separate my concerns just right, the design and coding go much better. I’m looking forward to seeing if Scrum has the same effect on our development organization.