The death of agile?

• The skills and talents of individual programmers are the main determinant of software quality. No amount of management, methodology, or high-level architecture astronautism can compensate for a poor quality team.
• The motivation and empowerment of programmers has a direct and strong relationship to the quality of  the software.
• Hard deadlines, especially micro-deadlines will result in poor quality software that will take longer to deliver.
• The consequences of poor design decisions multiply rapidly.
• It will usually take multiple attempts to arrive at a viable design.
• You  should make it easy to throw away code and start again.
• Latency kills. Short feedback loops to measurable outcomes create good software.
• Estimates are guess-timates; they are mostly useless. There is a geometric relationship between the length of an estimate and its inaccuracy.
• Software does not scale. Software teams do not scale. Architecture should be as much about enabling small teams to work on small components as the technical requirements of the software.
  Coconut Headphones: Why Agile Has Failed

The Rest of the Story

Why we moved from Scrum to Kanban

When I joined my current team, we were a full on Scrum shop: three roles (product owner, scrum master, team), three ceremonies (sprint planning, spring review, retrospective), three artifacts (etc), the whole shebang.  And, it mostly worked, in that things got done, software got shipped.

Sprint Planning Hell

Squeezed Testing

Stories Over-running

Problems with Traditional Scrum

It assumes that everybody can do everything

It assumes that developing stories is a single task

Why Kanban Works For Us

Our First Kanban Board

WIP Limits

Advantages of Kanban

Visualisation

Continuous vs Batch

To me, Scrum often felt like a ‘batch process’ model of software development – you do these things, heave them over the wall (into production) and then do the next things.  Everything had to fit the two-week sprint cycle.  With Kanban, I feel like we’re now using a continuous-flow process – small stories scurry across the board quickly, and can be shipped when ready; larger stories take longer.  I think it’s no accident that this is a good fit with the ‘continuous delivery’ model of software delivery.

No software engineering manager at a tech company should spend less than 30% of his or her time coding. Whether managing a team, a division, or all of engineering, when managers spend less than 30% of their time coding, they encounter a significant degradation in their ability to execute their responsibilities.

My claim stands in stark contrast to what I see as the expected path for software engineers who become team leaders. At each promotion, the engineer is expected to spend drastically less time coding, with a particularly steep drop-off when they go from a “lead” to a “manager” title. At that point, they’re expected to maintain passing familiarity with their codebase. A director’s coding is done, if at all, as a hobby.

This happened to me about a year ago as more of my time became absorbed in other things, such as recruiting, managing, and strategizing; I found then that I had crossed a threshold where my effectiveness as a technology leader suffered out of proportion to the amount of coding time lost. I wrote a short post on my blog that presented my thoughts following that experience, but without much concrete detail. Here, I’d like to expand that into a more developed thesis.

Why You Should Keep Coding

Many people believe that managers should step back and concentrate entirely on strategy and management. It makes sense that managers are expected to spend the majority of their time on these things. But as an industry, we pay too high a price for our managers when we allow or demand that they barely spend time coding. Once a person stops coding for a significant portion of time, critical connections to the concerns of developers atrophy. When that happens, decision-making, planning, and leadership suffer, undermining the entire basis for promoting engineers to management positions.

Estimates

One of the most important skills in an engineer’s toolkit is estimation. Strategic planning is quite simply not possible without the ability to accurately estimate. And yet we engineers are, as a class, notoriously bad at it. So bad, in fact, that we are advised to just double whatever number we come up with when asked to estimate something. In general, it’s easy to fool oneself into thinking that things will go optimally, but if we use the concept of “estimate traction,” code appears to have a particularly slippery surface. Because there are so many ways to implement features, when you lose familiarity with the details, your estimates become even more unreliable.

Technical Debt

Another thing that engineering managers need first-hand exposure to is the impact of technical debt. These days, that term has been popularized enough that when you have to debate the priority of a new feature versus. refactoring, you have a good chance of having that debate with people familiar with the concept. Engineering managers need to be more than familiar with the concept — they are the ones directly responsible for making the judgment call as to when technical debt needs to be paid down. A manager who codes regularly will have much better information on when and how to make that decision.

Continuity of Understanding

I haven’t chosen the number 30% arbitrarily. I chose it based on my experience because it is a simple heuristic for enough time to keep up with the changes that happen in a codebase under active development. With less time, it’s easy to lose the thread of development; and once that thread is dropped, I will need to ramp up all over again to retrieve it, thereby incurring an extra time penalty.

Parity with Responsibility

As a leader, you definitely should not be making all the decisions for your team, or approving all the decisions, but you need the context and the knowledge to facilitate all decisions. In the end, you are responsible for the outcome, and your ability to sensibly make choices should match that responsibility.

Your Team Respects You For Loving Code

Let’s be clear: To be successful as a manager, you must facilitate your team members’ efforts, foster their development, and ensure they are fulfilled by their work. I’ve been writing about how to diagnose and repair issues with poor managers on my blog in a series called Debugging the Boss. But to truly excel at managing software engineers, you had better love code. Because your team does, and they will respect you all the more if you lead by example.

Obstacles to Reaching 30%

Despite of my best efforts, I have run into many obstacles trying to maintain my coding time at 30%. These include the following.

Actual Responsibilities: At a startup, there is always more work to do than there is time to do it, and even as a company scales and matures, being as effective as possible is always an exercise in managing competing priorities. An engineering manager has many responsibilities, which should take up 70% of their time. Here are a few:

• Leadership and Team Tending: This responsibility is the first to appear in an engineering manager’s career. You are no longer just responsible for your work, you are responsible for enabling your team to produce their best work. It takes time to mentor your team, resolve disputes, and think about how to optimize their environment for happiness and productivity.
• Strategy: As the level of responsibility grows, an engineering manager is required to spend more time contributing to strategic planning at various levels. Initially, this will be limited to tech strategy, but later, both product development and competitive strategy will play a large part.
• Recruiting: Managers, directors, VPs, and CTOs need to build their teams, sometimes quite rapidly. While a good recruiting staff is a help, there is no substitute for a strong leader who actively seeks out new connections and sells every good engineer they meet on how great it is to work on their team.
• Customers: As engineering managers gain responsibility, they will often become more external-facing. This means they’re brought in “pitch meetings” with high-value prospects and called on for firefighting when important customers are unhappy.
• PR: Senior tech managers devote time to public speaking engagements, writing blog posts, and (of course) articles in prestigious tech journals. No matter how much help you have with these tasks, it takes time to write, edit, rehearse, travel, and present.

Avoidable Time Losses: The responsibilities I just discussed are what an engineering manager should be spending time on. These next areas are pitfalls I’ve experienced that have been my undoing when trying to maintain a bare minimum of 20% of my time spent coding, and which still stand between me and the 30% I am fighting to return to.

• Not Saying No Enough: Achieving great things means working hard; however, growth has to be sustainable, and one of the most crucial responsibilities of an engineering manager is to say “no” when their team is over-committed or on the verge of becoming so. When you don’t say no, other people begin to dictate your schedule and time commitments.
• Meetings: An entire cottage industry exists to give advice on how to meet effectively, and justifiably so. I have wasted more time in meetings than any other single activity in my career. This is especially debilitating when you have fallen behind in hiring, and are attending meetings that really should be run by team leaders.

Failing Strategies

In my quest to regain my coding time, I have tried a number of things that have not worked.

• Sleep Less: While surprisingly alluring for me, sacrificing sleep doesn’t work. Your brain stops working and you become unpleasant to be around and much less effective.
• Read Headers Only: I thought this was promising, but in practice, reading only the headers of C++ code commits gets you very little of the benefit you need for management.
• Overspecialization: Knowledge of only one project in your overall codebase is appropriate for a team lead, but not a director or above — you need familiarity with everything you are responsible for.
• Delegating Too Much Too Early: It’s easy to make more work for yourself by delegating recklessly when your reports actually need careful mentoring.

Successful Strategies

In spite of numerous dead-ends, I have managed to uncover some successful strategies:

• Time Blocking: The percentage of time on my calendar that is not allocated weeks in advance is minuscule. It seems obvious in hindsight, but I needed to allocate blocks of time specifically for coding. In practice, these blocks are frequently rebooked, but having even 8 hours blocked out per week makes an enormous difference.
• Delegating: Delegating is tricky, especially when you have very strong opinions about how tasks should be done and the ability to do them if you had the time. There are many reasons why managers resist delegating, but every reason has to be viewed as a problem to be solved, rather than an insurmountable barrier. Nothing frees up your time for coding like handing off running a meeting to someone you trust.
• Office Hours: Something I’m planning on instituting in the near future is office hours. This technique should help a lot with the random interruptions by consolidating them into discrete time windows, during which I can work on the many tasks I have that do not require committed, long-term focus.

Final Tips

Here are a few points of practical advice for managers finding themselves approaching, but not getting across, the 30% threshold:

• Learn how to read code. It’s a different skill than writing it.
• Commit to a meeting structure and hold your organization to it. Do not attend a single meeting that does not have a defined agenda.
• Get a real machine to work on. That MacBook Air you love for meeting hopping? Not it.
• Know how to access a dev environment and test a change fast.
• Understand if you’re the kind of person who can use five 20-minute blocks. If you need an hour, then put it on your calendar.
• Remember, 20–30% is a heuristic I’ve come up with for myself. Your mileage may vary. So measure yourself (Estimate how long it would take you to try out a hot fix; Can you list the most indebted areas of your codebase? Pick a random code review and see if you understand the conversation and the choices. If you don’t, you need to dig in more).
• Categorize your work by when you can work on it and what you need to accomplish it, rather than by topic. (Advocates of Getting Things Done (GTD) will recognize this as the essential basis of their productivity technique.)
• Finally, I’ve lately become fond of getting paper homework. As backwards as it seems, printing out a spec, a list of features to prioritize, or even a block of code is often a nice balance to spending large amounts of time looking at a screen.

I hope these tips are useful. If you have other techniques that have worked for you, please leave them in the comments area.