I was reading a guest post by Kent Beck on Eric Ries’ blog Startup Lessons Learned today where Kent answers the question “What is Lean about the Lean Startup?”. There was a great comment by someone who identified “intellectual waste” as one of the most damaging to a startup’s health. After agreeing with him, we added some additional comments about how you can avoid this kind of waste by applying Agile & Lean methods.
It got me thinking about Scrum vs. Lean. As I’ve stated in previous posts, I was an early adopter of Scrum and I have delivered many products using the fundamentals of Scrum. I think that Scrum is most effective as a replacement for teams who are using classic waterfall methods to develop products in a mature market. Instead of planning up front and going dark for months while you develop and test, you simply divide the work in month-size chunks which allows for the team to be more agile and the customer/stakeholder to get confidence in the team. It seems like common sense, but I’m still surprised by how many teams still use waterfall.
In order to be successful in a new market, you need to test new ideas and features as quick as possible with the goal of getting feedback from your early adopters. I’m very much a proponent of the Ready-Fire-Aim tactic in early stages. Don’t waste to much time at the whiteboard or in a planning session. Do something, measure it, and adapt. Unless you are extremely lucky, you will fail quickly and often, resulting in code getting thrown away. In Scrum, where the team is driven towards sprint goals, throwing away code can feel very defeating and wasteful. If you are subscribing to the Lean Startup principles, throwing away code isn’t always bad. It means you learned something about your product/market fit, which is always a good thing.
If you are in a start-up and using Scrum, I suggest you read up on some of the leaner methodologies like XP and Kanban. I believe they are a better fit and can help to align the entire company to the same goal of product/market fit. There’s also a great post called Scrumban by Corey Ladas that describes how to make the transition from Scrum to Lean.
I’ve been practicing some form of Agile Software Development throughout my entire career, beginning with Spiral in the 90’s, Scrum and XP throughout most of the 2000’s, and Lean Software Development over the last two years. One thing all of these practices have in common is the basic concept of doing short iterations through a backlog of work vs. planning up front and delivering over a longer release cycle (Waterfall).
The reason Agile methods are typically preferred over Waterfall is because it allows the team to deliver the backlog items that have the highest business value early and often. We’ve all heard the anecdotes about Waterfall where the product was delivered 18 months late and it wasn’t even what the business needed anymore. Considering that I am still an avid practitioner of Agile methods, I do believe that unless you are delivering a mission critical piece of software, you must use some form of Agile. In these times, we just don’t have the time or the money to wait months (or years) for a new software release. Your market will eventually be gobbled up by a competitor who is smaller and more nimble.
Because you are constantly reprioritizing and building for the current iteration, you build up technical debtthat needs to be repaid in future iterations. As you continue to iterate, you need to be disciplined enough to pay off some debt of before adding more. This is all well and good, but what happens after the team stops iterating and the resources move onto a new project? Everything will be humming along well for a while until the production system crashes. The team takes a look and realizes that the XML file they were using for simple data lookups grew to 250MB. So the team spends some time refactoring the XML file into a database table and the system is up and running again. About a month later, the system crashes again due to another issue. You get the idea: Much like financial debt, technical debt builds up interest over time until you finally go bankrupt if it is unmanaged.
So how do you make sure this doesn’t happen? Here are some things you should do with every agile project to avoid it:
Technical debt is an often necessary means to achieve goals with less staff, budget, and a shrinking market window. If you are going to “finance your roadmap” with technical debt, just make sure you manage it like any other debt or you would face some unhappy customers and stakeholders.
As I was catching up on my blog reading today, I came across a great post by Joel Spolsky called Duct Tape Programmers about how he values developers who get things done simply, rather than being academic and overcomplicating it. I immediately passed it along to my engineering team and got mixed comments. The “smart and gets things done” developers thought it was great, while the most academic developer challenged me on it, especially on unit testing and multi-threading. I went on and read the posts in the discussion group, and I was amazed at how many Joel On Software readers were mad at him for the same reasons.
As a former engineer and someone who has managed their fair share of engineers, Joel’s “smart and gets things done” blog post has always resonated with me. In fact, I think it might have been the post that kicked off my addiction to my Google Reader years ago. I’ve always admired Joel’s pragmatic approach to everything from programming, to management, to product evangelism, and even building out his office (ok, maybe not so pragmatic there).
Lots of engineers are smart, and lots get things done, but often to the wrong goal. I believe great software engineers definitely need these traits, but they also need to have the talent to make complex things simple. Whether it is a few lines of source code, an entire subsystem they have designed, or even an entire architecture, the greatest engineers keep it simple. Often times, this means that they have to sacrifice the latest design pattern and data access framework because they make their code too complex. Sometimes, this means that they might have to actually use a “legacy” ASPX page instead of ASP.NET MVC because the development team can see how the UI controls work without needing to master a new Javascript library.
Can it be taught? Maybe. There are two problems with teaching this:
While it is definitely not easy, there is one discipline that I have taught that can make the most academic engineer embrace simplicity: The Tracer Bullet. The goal with The Tracer Bullet is to get the code working as quickly as possible from start to finish. As soon as it works, the engineer is free to refactor it for code reuse, security, etc. but they must make sure the code still works. It is a kind of TDD at a system level. It is not an easy discipline to instill, and as a leader you will need to ride them a little, but it works. I’ve seen even the most academic engineers get addicted to a working system. And like most academics, when the system works, they often lose their passion to make it perfect. In the end, you often end up with working, simple code that does exactly (and only) what you needed it to do at that point in time.
Try it out and let me know what you think.
