The first session I attended was Jez Humble’s Applying the Lean Startup Model to the Enterprise. This session introduced the Lean Startup Model and discussed how the concepts could be applied to larger more established organizations, specifically how to organize development and operations.

About the talk

If you are not familiar with lean startup, don’t worry there is going to be plenty showing up about that topic in Beyond Requirements in the upcoming weeks. In the meantime, I though Jez provided a good brief introduction in his talk:

• Create hypothesis
• Deliver minimum viable product
• Get feedback
• (repeat, pivoting if necessary)

The main premise of the talk is that enterprises tend to separate the constituencies involved in delivering the systems that support the enterprise’s ultimate product or service. Jez referred to these constituencies as Business, Engineering, and Operations.

This arrangement leads to the various barriers of collaboration that lead to inefficiencies and waste. In this talk Jez focused on the relationship between engineering and operations where engineering delivers software to operations, which then releases it to customers. He described how this split leads to more complex systems, effectively proving Conway’s Law which to paraphrase is: “Any piece of software reflects the organizational structure that produced it.” In this scenario

Some techniques have appeared to attempt to address these solutions, such as devops and continuous delivery, which gets the enterprise part of the way to the solution. Jez suggests a more complete approach is to treat these internal systems (Jez referred to them as services) as products and combine the engineering and operations teams in product teams focused on a specific system or systems. Amazon is one company that follows this approach and is described by its Walter Vogels, the Amazon CTO, “You build it, You run it.”

Once you have put that team together, the team can apply ideas from lean in general and lean startup in particular to improve their processes and ensure they are delivering the right things. For example, because the team has a broader range of cross functional skills, it is better to optimize on cycle time, rather than for utilization. Optimizing on cycle time means that some people with certain skill sets may not always be fully utilized, but it allows time and capacity for continuous improvements.

Some other interesting points from the talk that were not necessarily a surprise to me, but provided a nice way of thinking of it:

• The PMO exists to manage the portfolio – what services/products should continue/not continue.
• In a Lean Startup approach, user stories were not considered done until they led to validated learning i.e. we learned they were useful (more on that in later posts)
• Enterprise Governance is about risk management – focus on performance and conformance. I find this one particularly meaningful, and unfortunately my experience has been that most enterprise governance efforts focus too much on the conformance aspect of things as opposed to provide shared learning on how to improve performance.

Application to Business Analysis

The main points I took away from this presentation:

The project model (distinct efforts with a potentially different group of people working on a system at different times) is probably not the best long term model for maintaining software applications. A consistent, cross functional team that as a whole understands the business needs served by the system and the underlying technology may work better to minimize the work done every time a change is needed, especially in the case where the system needs to change frequently. Projects are still a good mechanism to introduce changes to a process or organization, or where the system is fairly static.

The concept of devops was an often repeated theme at Agile 2011. From my view point it seems to be where agile was a few years ago: a group of skilled people in their line of work (in this case system admins primarily) who are tired of being part of the problem and want to do things better. As with all movements in its early stages it has its share of detractors, some trying to resist change, others skeptical that a term was created to make some people some money.

There are teams that are already combining development and operations, in fact one of the teams I work with is following this exact model. Primarily because it has not grown to the size yet where the powers that be think it is wise to split up the responsibilities. Hopefully this team can maintain the idea of keeping engineering and operations together. I’ve worked in both structures. The cross functional team works better.

This presentation was focused on the development and deployment side of things. If you look at the presentation slides, there is still a thick red line between the business and the delivery team (which was pointed out by Mary Poppendieck who attended the talk). I think there are certainly ways to get rid of the red line between business and engineering, something I plan to explore with future posts.

Attending sessions such as this one, even though they are not focused that much on business analysis practices and techniques are still extremely helpful for business analysis practitioners to keep up with what is going on outside the realm of working with the customer.