Monday 16 June 2014

Small but not Lean or Agile

Several years ago I was working with a start-up company (we will call them Acme) in the technology space.  Start-up companies are known for being very Agile in their approach to the market, but that wasn't exactly the case with this start-up... The company was piloting a new on-line media technology that had significant potential to do very well in the market.  Similar technologies had just started to enter the market, but none with the same feature set as Acme.  Acme's founder (we will call him Fred) had worked very hard for a number of years to develop the technology and he had written most of the code himself.  Acme obtained preliminary intellectual property protection in the US.

Acme's founder Fred had a vision for his product entering the market.  He wanted to get a deal in place with a top tier Silicon Valley company or top Hollywood entertainment company.  Fred had several meetings that he hoped would lead to that one big deal that would make the company.  Unfortunately, none of these meetings ever materialised into the Holy Grail of a deal with a top company.

In the mean time many smaller opportunities to test Acme's product in the market came and went.  Now these opportunities wouldn't necessarily be make-or-break, but they would provide real world feedback, and potentially early revenue streams.  Ultimately Fred ran out of money before he could get Acme's product into the market.  The pursuit of a big deal that never materialised ultimately was the company's undoing.

Could there have been a different outcome using Agile and Lean Startup (http://theleanstartup.com/) principles?  I think so.  To start Fred could have attempted to test a Minimum Viable Product (MVP) in the market with a limited set of users to test Acme's concept.  This may have showed the potential of the product, or showed Fred where he needed to pivot and move in another direction.  This is a part of the core Build-Measure-Learn method that is core to the Lean Start-up approach.

Fred could have also started to realise revenue much more quickly than forever waiting for the one big deal that would make the company.  This was particularly important as Fred's company was bootstrapped and therefore had very limited funding.  Fred didn't have the cash to keep waiting for the elusive big deal while not deriving any revenue from the company.  When Fred realised (I am not sure this realisation came until he ran out of money) that the big companies he was pursuing weren't going to invest, he could have pivoted to seek smaller revenue streams from multiple early adopting customers.  Fred also had other opportunities like embedding Amazon products in his media technology, which would have potentially led to a stream of referral revenue from Amazon.

Fred spent a very long time working very hard on his product.  Adopting some Lean Start-up techniques could have potentially allowed his product and company to be successful.  Using a Build-Measure-Learn approach could have helped Fred to realise much needed revenue early, and to learn what worked in the market.  Having the flexibility to pivot when he saw the go big approach wasn't working could have made his company a success (in my opinion).  Also, finding an MVP that could earn revenue in the market could have provided much needed early cash flow.  All-in-all there were allot of potential benefits Fred could have realised using a Lean Start-up approach, instead of the "go big or go home" approach that he employed.

Until next time,
John.

Sunday 8 June 2014

To Lead is Agile

Attending the Scrum Alliance Regional Scrum Gathering in Shanghai (www.scrumgathering.cn) this week the opening Key Note by Harvey Wheaton from Scrum Alliance addressed the role of leaders in Agile. Historically there has been the perception that managers and leaders do not have a role in an Agile team. Harvey's opening addressed some ways that leaders can be Agile.  I felt this was a very good opening to the conference as this is a topic that I am very passionate about.  I had many conversations with conference attendees, speakers, and business partners during the two days of the conference about the importance of leaders in Agile.

In both my own experience and that of many peers and colleagues I am aware of many Agile initiatives that never got off the ground because of a lack of leadership buy-in.  Ideally Scrum teams self-organize, but this often leaves managers and leaders feeling that they are left out.  The managers then often become reactive and in response oppose the Agile project or completely shut it down.

A better model is to include leaders in Agile plans up front.  To make key leaders in the organisation fans and sponsors of the Agile program.  After all there needs to be someone to champion the cause of the Agile team with upper management, someone to express the significant business value of an Agile approach.  A 2008 QSM Associates Agile Impact Report indicates Agile leads to 25% increased productivity, 50% faster time to market, 83% stakeholder satisfaction, and 49% less cost.

Managers are also needed to help Agile team members to build a career path in the company, to track against budgets, to address legal contracts with vendors, and to help coordinate across large programs that include many Agile teams. Managers for example can help to foster Communities of Practice where developers, testers, UX Designers and others can collaborate across the organisation and help to elevate Agile practices. 

When Agile teams and leaders collaborate the results can be exceptional and beautiful.  Software and products that are delivered to market quickly.  Business results in terms of more revenue for the company or organisation, happy teams, and servant leaders who grow to provide vision and support for their teams.  In this model everyone wins.  The key point for the Agile team here is that management and business leaders should be the Agile Team's best friends, and not perceived as the the enemy of the Agile Team.

Until next time, have a great weekend from Shanghai,
John.

Monday 2 June 2014

Is it Okay to do Hybrid Agile?

In working with many companies, and talking with many of my colleagues (both Agilists, and non-Agile IT practitioners) the topic of Agile hybrids comes up frequently.  People ask whether it is okay to use Agile and waterfall side-by-side in the same organisation.  My answer to this comes in several parts.

First of all hybrids, while not ideal are a fact of life.  There are many companies that have transitioned their mobile projects for example to Agile, but legacy system projects are still done using a waterfall process.  Now, surely this is not ideal, it is much easier to adopt one methodology and stick with it consistently across an organisation.  However, not every organisation can adopt Agile in one fell swoop.  Instead it is sometimes necessary to move more slowly from traditional project management methods to Agile methods.

Second, there are some governance and regulatory requirements that companies are faced with, that in many cases require some traditional project methodology to be followed in the organisation.  This may be audit requirements for government, or process requirements in order to comply with the requirements of an industry standard.  This may also be a project lifecycle or method that is deeply ingrained in the company or organisation that will take time to change.  Whatever the case for the short term the organisation is forced to maintain some traditional project management process even while they transition to Agile.

Third, it is common for an organisation to see one of several scenarios internally that may cause them to deal with an Agile hybrid environment.  One scenario is where the company works with vendors who are using Agile methodology while the company is using traditional methods or vice-versa.  Another scenario is where different projects within the same program or group are using different methods (i.e. some are using Agile, and some are using waterfall or traditional methods).  A third scenario is where the organisation has chosen to define a process that is part traditional and part Agile (I don't suggest this unless it has really been well thought through, and there is a strong business driver not to fully change to an Agile approach).

Success Factors for working with a hybrid

So if you do find yourself dealing with an Agile hybrid in your organisation here are some things to keep in mind to make it successful.

1.  An Agile hybrid approach should be well though through, if it is haphazard and not well considered it is almost guaranteed to fail.  One example of an organisation that had thought through this well was a multi-national entertainment company I worked with.  Their PMO had defined a methodology that allowed for a constant project discovery and initiation phase, and then allowed each project to select either iterative (Agile) or traditional project execution (design - build - test).  The projects were then deployed and closed using traditional methodology.  Again while this is not ideal (Water-Scrum-Fall) it was well thought through, and to some degree was working for the organisation, though I believe they were still in the process of changing their project approach, and this was not the end-point.

2.  Identify what type of hybrid you are dealing with.  Is it a hybrid group or program, a hybrid due to an Agile vendor, or an intentionally hybrid internal process?  Your organisation should decide whether this hybrid is the end point, or if it is somewhere along the course of an Agile transformation journey.  Maybe you are only operating in this hybrid fashion until you can move your legacy teams to a Kanban based approach, or until it is politically viable to transition fully to Agile (yes ensuring a politically viable transition with minimal resistance is a valid reason to use a hybrid approach for a period of time before a full Agile transition can be completed).

3.  If you have operational projects that use a traditional methodology, or on-going project maintenance that uses an existing process consider using a Kanban approach.  A Kanban approach using continuous flow and Work in Process (WIP) limits can allow all of your projects to take an Agile / Lean approach while still using some of your existing processes that may be needed for regulatory compliance or other considerations.

What is really key is to decide whether a hybrid is an end in itself, or if is only a means to an end (i.e. becoming more / fully Agile).  I think there can be a valid case for using a hybrid for a period of time, but I believe that ideally it is best to use a hybrid approach as a vehicle to make your organisation more Agile.  A hybrid is best used when it is a tool that helps your organisation to move forward in its Agile journey.  I hope some of these considerations will help you as you think through using a hybrid approach in your organisation (or not).

Until next time,
John.