You are currently browsing the category archive for the ‘Updates’ category.

I presented the attached PowerPoint at the last Lean & Kanban Socal meetup describing our success using Kanban for both our release process and for software engineering.  Unfortunately images have been removed since I do not own rights to them, but there’s still some good information there along with a timeline describing our rollout.

We’ve had pretty amazing success with Kanban so far so this is more a success story than anything, but we still had some interesting lessons learned that were worth sharing.

I’ll be presenting a case study on my experience rolling out Kanban at CityGrid Media (both for release management and for software development) on the 14th. If anyone is able to make it please come by and say hello!

More details at http://bit.ly/cb9go0.

The first Lean Software & Systems Meetup (SoCal) will be on July 12th at the CityGrid Media offices where I work.   There should be some great discussion on Kanban and other engineering/technical process.  Hope to see you there!

I came across a good article on building technology teams at http://leanstartups.com/putting-together-strong-technical-team.html.  In particular, I thought the foundational principles that the author listed were great:

Strong talent in a small team can be far more effective that average talent in a larger one.
Well directed and motivated expert teams execute effectively. They tend to need more tender loving care because they can be precious about their output, but this is a small price to pay for the results that can be delivered. You will expect to pay that expert talent more, but you can offset that by recruiting fewer people.

Try to operate like the team is a small start-up
The by-product of creating this environment is that the team feel they can operate outside of the “red tape” that besets many larger organizations and start to get creative and innovative. Typical examples are removing all the “lock downs” that most corporate organizations enforce on company provided hardware. This doesn’t mean that it’s a free-for-all – the environments should be well thought through and consistent. Also allow the team to work on a flexi-time basis.

Have a strong leadership team that is transparent
If the team know their leadership have their support and trust them then they are less likely to want to fail and will go beyond the cause to get things done and done right. A leadership team that shows they have direction and can speak to the team about it, can be open an honest about how things stand will have the respect and therefore the backing of the team – this loyalty is an extremely valuable commodity.

Cultivate the environment where everyone matters
Empowering the team and ensuring that everyone feels more than comfortable to give an opinion to anyone in the group at any level. This creates an environment where people get passionate about their work and team.

Shield the team from corporate noise
Avoid team members getting caught up in meetings etc. that take away their time from doing the work they love. This is a value add that they will respect you for.

Communicate!
Create effective communication strategies – canvass the team about what sort of information would be useful. Have at least one team meeting a week and consider having a “beer Friday” once a month – take the team outside of the work environment and let them talk. It’s amazing what you’ll find out!

Check out the article for more tips, including specific advice for hiring various roles.

Ash Maurya posted a very in-depth case study over at Eric Ries’ blog a few days ago, and I highly recommend reading it.  Interestingly, this case study is from a company that has existed for seven years (not a startup) so the lessons here apply to a broader audience.

Continuous Deployment is Continuous Flow applied to software. The goal of both is to eliminate waste. The biggest waste in manufacturing is created from having to transport products from one place to another. The biggest waste in software is created from waiting for software as it moves from one state to another: Waiting to code, waiting to test, waiting to deploy. Reducing or eliminating these waits leads to faster iterations which is the key to success.

You can find more case studies at the Lean Startup Wiki over at http://leanstartup.pbworks.com/Case-Studies.

I came across a great article over at the ACM blog regarding how Agile Facebook is and the kind of value they are seeing from using these kinds of processes even though they are well out of startup mode.   A lot of people think that Lean-derived techniques such as continuous deployment, Scrum, and Agile are really only for small, startup-type companies, but just as Lean manufacturing isn’t just for small workshops, Lean software development can deliver astounding results to any company – especially large ones that have become complacent and allowed a lot of non-value producing process to creep into their methodology.

Excerpt:

Perhaps the most interesting and revealing aspect of Robert’s talk was the discussion of Facebook’s somewhat unique development process.  At the surface it appears to have the contradictory goals of: minimizing down time, scaling fast, and extremely quick code updates.  First, Facebook developers are encouraged to push code often and quickly.  Pushes are never delayed and applied directly to parts of the infrastructure.  The idea is to quickly find issues and their impacts on the rest of system and surely fixing any bugs that would result from these frequent small changes.

Second, there is limited QA (quality assurance) teams at Facebook but lots of peer review of code.  Since the Facebook engineering team is relatively small, all team members are in frequent communications.  The team uses various staging and deployment tools as well as strategies such as A/B testing, and gradual targeted geographic launches.  This has resulted in a site that has experienced, according to Robert, less than 3 hours of down time in the past three years.

In Eric Ries’ latest post over at Startup Lessons Learned, he addresses many of the most common objections he’s heard regarding continuous deployment.  According to Eric, most of the objections boil down to the following two points:

      1. That mission critical customers won’t accept new releases on a continuous basis.
      2. That continuous deployment leads to lower quality software than software built in large batches.

I think he addresses both of these points extremely well and goes further in illustrating the improvements that continuous deployment brings to an organization:

  1. Faster (and better) feedback. 
  2. More automation. 
  3. Monitoring of real-world metrics.
  4. Better handling of intermittent bugs. 
  5. Smaller batches

Be sure not to miss out on the great discussions in the comments thread as well.   One comment Eric made that really stood out to me was his mention that the dichotomy between “fewer, more stable releases” and “faster, less stable releases” is a false one and that what continuous deployment truly brings to an organization is faster and more stable releases.  

This reminded me of a lot of objections I’ve heard regarding Lean in that doing the right thing up front (building infrastructure, identifying and planning around your constraints, etc.) will give you better quality but slower development; in fact the truth (as borne out both in manufacturing and software development) that doing the right thing up front may cost more initially but you’ll end up letting people work faster while also increasing quality and customer value over the life of the project.

2009 was a very good year for me, and I hope it was for all of you.  Now that it’s mostly over, I feel like much of what I accomplished (and the way I’ve responded to change) this year was all was oriented around setting myself up for great things next year:

  • Although I was laid off from my publishing producer role as part of the big restructuring and refocus at EA, I was quickly able to join a new company that is in the midst of a Lean/Agile revolution as a Release Manager.  The role reports directly to the CTO and has a strong mandate to deliver results to an established company looking to reinvent itself in order to compete against highly agile startups moving into their market.  It’s a challenging post, and I think the idea of “Go Big or Go Home” really applies here.   The best part is I’ll be able to share my lessons learned on this blog.
  • I’m back in Los Angeles now, and I have to say that now that I’m back from the Valley I’m realizing how much I missed this place.  The tech industry is a bit smaller here, but you really get to know people at all the companies here and it feels much more like a community.  I’m hoping to leverage some of my connections here into some quality interviews and guest writer posts here on this blog.
  • I’ve gotten to know some of my Lean guru friends better, as well as met some new ones.  Their insight and influence will be a major part of the way this blog takes shape over the next year.

Looking ahead to 2010 I’m excited to see how everything that has set itself up in 2009 plays out.   Definitely look for more posts on this blog now that I’m doing real configuration management again at a Lean company!

All the best for 2010,
Jason

One of the constraints that makes moving towards continuous deployment difficult for some teams is the downtime required with web app deployments.   Managed Chaos just posted an article on how to update web applications without destroying in-progress user sessions.   In this specific example he illustrates how to do this using a Tomcat cluster, but the fundamental principles apply to any tiered web application architecture.

Databases are, of course, a bit trickier since you’ve potentially got lots of dependency problems; luckily, the Exortech blog recently addressed this issue as well.

The more I’ve been thinking about continuous deployment the more I feel like it’s really going to be a game changer for companies that adopt it.  The barrier for entry is relatively low (and can be well understood before embarking on a project to adopt the process) and the reward of being able to reduce batch sizes on merges and (more importantly) give your product owners the ability to quickly get features in front of customers is key for any business.