Agile. A newer perspective

I think agile has traditionally been used in engineering environments for software development. You see it in hiring requirements for engineers, product managers and leadership.  I think agile makes sense in the larger context - the business context. Imagine making your business model Agile and your business itself agile to disrupt industries?

Let's look at the disruptive industries with some examples that I think are interesting to look at:

1) Apple - they brought us itunes, ipod, iphones and the macs. They were failing a few years ago before Steve Jobs took over. They became agile in their business, to look for new industries to disrupt. They launched the iphone in June 2007, and have relaunched releases roughly every 1-2 years. It has become the largest revenue generator for apple. I am pretty confident, they have looked at their business and made it agile to be flexible to take over market share.

2) Sony,phillips,toshiba - the walkman, portable cassettes - displaced by the CD, displaced by the DVD and now replaced with an ipod and most recently with streaming itunes  and spotify or pandora.  The amount of time has compressed over the recent years for disruptive industries to make older technologies obsolete.

3) Tesla - electric vehicles - the model S launched in via a press conference in 2009 and started production in 2012. This is a brand new platform for electric vehicles, which if we think about it, is a conservative industry thats slow moving and created a new market in roughly 4-5 years. I think that's incredible given the type of industry they are in.

I think industries and companies that are not agile in their business will lose in the long term. Over time, the cycle of being disruptive will compress.

thoughts ?

Agile is easy on paper - how to address the intangibles

I recently gave a talk at the rally agile cafe conference about Agile and SCRUM practices and I was really intrigued by  how common the evolution of agile is across industries. There were several examples of Agile implementations with rally and we crossed industries from consumer electronics, to fortune 100 companies like John Deer ( where they use Agile to build robot controlled tractors with GPS systems) and enterprise software. What struck me was the same difficulties arise when you traverse the agile maturity curve - what I mean is the following

1) Culture - All the books talk agile in a fairly straightforward way - but what happens in reality is that culture comes into play about how you really want to absorb agile. The VP of Eng of the consumer electronics company was acknowledging that its not just good enough to put in the tools and practice in place. I feel that you really need to graduate to the "culture of agile". The "culture" of agile means, putting in the right practices around what it means to implement agile, how you communicate to your customers on releases, what the impact this has on your products.  In order to do this right, the business has to transform in how it works so that the right expectations are managed. Unless one doesnt really think about that, then you dont really implement agile in the right way. It means, Agile has to be embraced at the exec level and fundamentally understood.

2) Ecosystem - Agile has to exist in an ecosystem of the right toolset so that you have the right level of visibility to other organizations and their ability to manage. Visibility to me means better predictability, staying one step ahead. Really respecting the statistics you get out of the toolset(I have used Rally and Scrumworks the past). For instance, velocity charts, and understanding the gradient of the work product and seeing whether you will really make it. The ability to figure out how many bugs you think you can fix in a release and making some hard choices on where to push back and which features are key.  The other part of the Ecosystem is how the impact of particular feature has on customers  and how your product owners evaluate risk of features and their scope. This impacts sales and possibly product services organizations that need to work with the product.


I firmly believe that a successful Agile shop takes into account all of these factors in order to provide a more predictable plan of attack and a better way to manage product and customer expectations.

thoughts ?

Scrum - play by rules

A recent post by Ken Schwaber, on his blog made me think on the real pressures and culture of some of the workplaces I have encountered recently where that say they implement SCRUM and they claim their implementation fits their culture and company. Upon closer examination, there are short cuts, there are aspects where teams seem to adjust the process. To me it seems these teams are scared to go all in with the process, since the process of SCRUM is very well defined, the rules are known and its a question of getting better with time as you use the methodology. Perhaps they think they are better than SCRUM in some way by making these adjustments ? or perhaps just lazy?

I am not questioning that it takes time to absorb the concepts, make use of them, learn from your mistakes and get better. Everything gets better with practice and I don't believe SCRUM will fail you, its safe, if executed correctly.

Have a safe SCRUM - it won't fail you. 

Importance of team structure and risk evaluation

I was talking to a couple of software professionals recently and they employ the use of SCRUM and what I found interesting was that they all said, "we use N scrum teams" and "we have been using it for a while now ( over 1 year or more) " but it seemed to me that achieving the right level of communication was still missing and the deadlines were somewhat missed. I asked them , how do structure the team and how do you evaluate risk ? They all said, we have teams that are focused on particular competencies like network, or applications or platform ... they all use accurate stores to define the problem to be solved ( which is ok )... but they all had cross communication issues, which in effect caused a "silo" situation among the teams.

In my opinion, I think one really needs to look at the teams structure and ensure that the right representatives are part of the team, for instance, if you have a feature that requires operations, and you are deploying to a website, then its natural and a must, to have the operations folks be part of say the application team standup. I strongly believe that the team should be structured as a feature team which needs to include all participants impacted by that feature throughout the planning and execution phases. This increases transparency and understanding early on so that when it becomes time to deploy or ship, you are in a better place and less riskier place to succeed. The team structure and risk are really separate concepts, but I think merging them together makes sense and adds to the overall reduction in shipping risk.

In addition, as the stories are getting figured out, its important to understand the "feature risk" and the probability of impact and understanding the scrum risk curve.

Scrum risk curves, would involve understand the feature in a few sentences and its risk, the probability of success or failure, the exposure and time lost.  This is a concept originally introduced in 2004, by John Brothers in The Agile Times in 2004: the risk burndown chart.

Figure 1: Risk Census

Our simple risk census here describes each risk, provides an estimate of how likely the risk is to occur, the impact to the schedule if the risk did occur, and then the expected exposure to the risk which is the probability multiplied by the size of the loss. I recommend creating a risk census during the first sprint planning meeting and then updating it quickly during subsequent planning meetings as new risks are identified or as the probabilities or sizes of known risks change.
The risk burndown chart is then created by plotting the sum of the risk exposure values from the census. My recommendation is to sum only the top ten risks even if the team has identified more. Do this even if the top ten change over the course of the project. A risk burndown chart will look just like a normal burndown, except that it plots risk exposure over iterations.