I’m blessed to live and work with the smartest people I know. I’ve been at it for many years. In fact, I’m quite certain some of them are among the smartest people on the planet. I cherish the knowledge and support they freely share yet I frequently wonder why they tolerate me in their midst. I’ve experienced Imposter Syndrome from an early age, and I’m still driven to tears when I think about it. Why do I deserve to be in the midst of the greatness I’ve surrounded myself with? It’s worse when I get credit, as I feel like I’ll surely be figured out as the fraud now that everyone’s looking.
I’ll just leave this here as I suspect there are many others around me who have this affliction. If nothing else, I’m right there with you—for real.
I’ve worked on many software projects over many years. A few of them went on to become billion dollar businesses and some of them never shipped. Some of them shipped after a great deal of pain and suffering. I learned a few things about software development processes that work and don’t.
Scrum doesn’t work.
I’m sure the Certified Scrum Masters will be quick to point out that I must have done Scrum incorrectly or somehow did not follow through with the methodology, and I’ll say that’s exactly why it doesn’t work: A whole industry of people who walk around to talk your ear off about Scrum and why it’s the best thing since the silicon wafer.
Here’s what I know to work:
- Generate a strong product vision.
- Hire the most talented software engineers.
- Make sure they understand #1 and let them build it.
Scrum aims to provide a safety net in case you fail to do any or all those 3 steps. Here’s the problem: you will not be successful unless you succeed at all 3 steps.
Scrum states that we can change the goals and vision based on lessons learned during the iteration. In practice, this leads to leaders with no vested interest in achieving audacious goals. “Oh, it didn’t work. Let’s try something else.” How are we going to get Teleportation with that attitude?
Scrum assumes that you can calculate your team’s velocity based on historical data and therefore predict your ability to deliver. This assumes that any slug that grows arms can write so many lines of code in an “ideal day.” It marginalizes talented software developers who don’t need to be forced to determine how many “story points” there are in their work. How many story points do you think transporting a kilogram of carbon across an ethernet cable would be worth? How many story points to do it wireless?
Scrum lets you review the work completed during an iteration and choose to continue pursuing missed goals or decide to pull something else off the backlog. Sounds great, right? In practice, this just hides incompetence and frustrates strong engineers. The lame engineers will come with lame backlog items and burn down to zero every time. The strong engineers will aim for the moon, and sometimes fail, and get shafted because they did not achieve the stated goals for the iteration. They’ll eventually leave.
I’d like to hear your thoughts on this, as I’ve seen Scrum spread throughout Silicon Valley like a locust plague. If you’ve adopted Scrum in your team, I’d like to hear about it:
- Was the product any good?
- Was it worse/better before you started Scrum?
- Did you ship on time?
- Was your team happy doing it?
I recently started working on Firefox. To be more specific, I help run the Gecko Layout Team for the Mozilla Corporation. My team is responsible for everything you can “see” in Firefox. As you can imagine, the team is very busy.
I really enjoy working on software used by hundreds of millions of people. Before I started working on Firefox full-time, I managed Software Engineering for the Adobe Flash Player. Before that, I worked on a bunch of other software used by lots of people. After 13 years at Adobe and Macromedia, it was time for me to make a change.
I started looking for an opportunity that would let me continue working for a global audience and allow growth through new challenges. At Adobe, I had the opportunity to work with all the browser vendors to make sure that the Flash Player worked on their products. I really enjoyed working with the Mozilla people, so I reached out to let them know about my plans. They’re hiring lots of new staff and needed help on Engineering Leadership to scale the organization. After a very rigorous interview process, I started work on September 12, 2011.
In the short time I’ve been at Mozilla, it’s already clear that this place is run by Engineers. I love it! It feels a lot like Macromedia did when I started there in 1998. My first day on the job was at the San Jose Convention Center where the Mozilla employees had their All-Hands meeting. There was far more energy and enthusiasm at the Mozilla All-Hands than at the last event I saw at the Convention Center (which had 10x as many attendees!) Everyone at Mozilla is definitely on a mission and charged up…
- It’s not enough to not be evil.
- It’s not enough to be good at what you do.
- You have to Do Good.