+ All Categories
Home > Business > Software Agility - Necessary...but not Sufficient

Software Agility - Necessary...but not Sufficient

Date post: 08-May-2015
Category:
Upload: tathagat-varma
View: 1,735 times
Download: 0 times
Share this document with a friend
Description:
My presentation at Agile Tours 2012 at Bangalore. In this presentation, I have taken a hard look at how the basic agile adoption appears to be rather ineffective in the face of today's problems that are much more complex, dynamic and uncertain. I outline hat I consider as inadequacies of agility as we understand today. I also discuss Lean Startup framework as a better way to address some of these shortcomings. Feedback welcome...
27
Software Agility NecessaryBUT NOT SUFFICIENT! Tathagat Varma http://managewell.net Sep 29, 2012, Bangalore
Transcript
Page 1: Software Agility - Necessary...but not Sufficient

Software Agility – Necessary…BUT NOT

SUFFICIENT! Tathagat Varma

http://managewell.net

Sep 29, 2012, Bangalore

Page 2: Software Agility - Necessary...but not Sufficient

my professional belief system

ò Goal: The goal of software is to deliver real value to the business and the users it serves. Software just by itself is, thus, not a value.

ò Means: Methodologies are simply a means to organize work and assign resources to deliver better software, not an end by themselves.

ò Judgment: “When the terrain disagrees with map, trust the terrain” - Swiss army manual

Page 3: Software Agility - Necessary...but not Sufficient

What is (my definition of) Agility?

ò  Accomplishing end-objectives through a series of mid-course corrections

ò  Accomplishing = the focus is on results and not on intent, desire or behavior

ò  End-objectives = agility by itself is just a means to accomplish end-objectives, which include value delivered, time to market, cost and quality constraints, etc.

ò  Mid-course corrections = embracing mid-course change and adapting to them in real-time keeping the focus on end-objectives

“A”

“B”

Time

Pro

gres

s

Page 4: Software Agility - Necessary...but not Sufficient

The [Old?] Agile Manifesto Circa 2001

Page 5: Software Agility - Necessary...but not Sufficient

Does you Agile Manifesto look like this?

http://www.halfarsedagilemanifesto.org/

Page 6: Software Agility - Necessary...but not Sufficient

Or, like this?

CENSORED!

CENSORED!

CENSORED!

CENSORED!

CENSORED!

Page 7: Software Agility - Necessary...but not Sufficient

And these values?

CENSORED!

CENSORED!

CENSORED!

CENSORED!

CENSORED!

CENSORED!

CENSORED!

Page 8: Software Agility - Necessary...but not Sufficient

Does the ‘tool’ matter???

A photographer went to a socialite party in New York. As he entered the front door, the host said ‘I love your pictures – they’re wonderful; you must have a fantastic camera.’

He said nothing until dinner was finished, then: ‘That was a wonderful dinner; you must have a terrific stove.’

– Sam Haskins

Page 9: Software Agility - Necessary...but not Sufficient

Applying ‘Inspect and Adapt’ to The Agile Manifesto

ò  “…In looking back, [Kent] Beck finds that while each segment of the Manifesto was a giant leap forward in 2001, the language no longer reflects the challenge of launching successful innovation in the marketplace of 2011.”

ò  Beck’s Beyond Agile Manifesto -

ò  Team Vision and Discipline over Individuals and Interactions (over Processes and Tools)

ò  Validated Learning over Working Software (over Comprehensive Documentation)

ò  Customer Discovery over Customer Collaboration (over Contract Negotiation)

ò  Initiating Change over Responding to Change (over Following a Plan)

http://www.forbes.com/sites/stevedenning/2011/05/04/innovation-applying-inspect-adapt-to-the-agile-manifesto/

Page 10: Software Agility - Necessary...but not Sufficient

Team Vision and Discipline over Individuals and Interactions

ò  In 2001, it was a big step forward in software development to realize that the people and how they interacted with each other mattered more than following some process. So the Manifesto declared that “individuals and interactions” were valued more than “processes and tools”.

ò  Beck has found however that in developing software in new business lines, “individuals and interactions” are not enough. Each individual in a team in a startup needs to think, not about how good a job he or she can do, but rather, how good a job are we doing?

ò  Individuals interacting have a tendency to optimize their own performance. Beck believes that team vision and discipline goes beyond that to discover how are we going to make the most progress together.

Page 11: Software Agility - Necessary...but not Sufficient

Validated Learning over Working Software

ò  Beck says that in a environment of a startup (or a new line of business), nine times out of ten, it’s not that you don’t know how to write the software. The central problem is almost always: how do you find customers who are going to pay for what you are building? Working software can be part of the way to answer that question but it isn’t necessarily the best way to answer it. The real challenge is to create an opportunity for learning by the organization as to what might satisfy or even delight customers so that they will pay for it.

ò  As a result, Beck concludes that in 2011, in the world of startups (or establishing new lines of business), validated learning is to be valued ahead of both working software and comprehensive documentation

Page 12: Software Agility - Necessary...but not Sufficient

Customer Discovery over Customer Collaboration

ò  It was a big step forward in 2001 to realize that in the rapidly changing and unpredictable world of software development, collaborating with customers was better than trying to nail down all the details of software development at the beginning.

ò  But in a startup, or in a new line of business, collaboration with customers isn’t possible, because by definition, you don’t have any customers. In effect, you have to find out who your customer is.

ò  Thus in a startup or a new line of business, customer discovery has precedence over both customer collaboration or contract negotiation.

Page 13: Software Agility - Necessary...but not Sufficient

Initiating Change over Responding to Change

ò  Traditional management tended to believe that the way to do software was to make a plan and then follow the plan. In 2001, recognizing that things change too much to be following a plan was a big step forward. Reality diverges from the plan. Reality is much less flexible than the plan. Reality bends a lot less than the plan bends. So the Manifesto recognized that responding to change was more important than following a plan.

ò  But in a startup or a new line of business, nothing is changing. Nothing is moving. You have to establish momentum first. Development in a startup requires initiating change, not just responding to it.

Page 14: Software Agility - Necessary...but not Sufficient

So, what is Innovation?

ò  Innovation is the development of new customer value through solutions that meet new needs, unarticulated needs, or old customer and market needs in new ways.

ò  Innovation differs from invention in that innovation refers to the use of a better and, as a result, novel idea or method, whereas invention refers more directly to the creation of the idea or method itself.

ò  Innovation differs from improvement in that innovation refers to the notion of doing something different rather than doing the same thing better.

http://en.wikipedia.org/wiki/Innovation

http://en.wikipedia.org/wiki/Innovation

Page 15: Software Agility - Necessary...but not Sufficient

How are Innovation Projects different?

ò  Innovation projects tend to start with loosely defined, sometimes even ambiguous objectives that become clearer as the project proceeds. The processes used are more experimental and exploratory and seldom follow strict linear guidelines.

ò  Teams need to be more diverse and have a higher level of trust as they explore new territory where failure is a possibility.

ò  With failure as a built-in possibility, innovation teams are more actively involved with risk management and need to learn to fail fast and fail smart in order to move on to more attractive options.

ò  Also, innovation projects generally need to be sold to project sponsors and funding committees, a responsibility usually not required from normal project teams.

http://www.innovationtools.com/weblog/innovationblog-detail.asp?articleid=303

Page 16: Software Agility - Necessary...but not Sufficient

Innovation Continuum

Low Risk � High Risk �

Low Rewards �

High Rewards � Operations�

Projects�

��

Disruptive Innovation�

Sustaining Innovation�

Page 17: Software Agility - Necessary...but not Sufficient

Kaizen vs. Kaikaku

Page 18: Software Agility - Necessary...but not Sufficient

Kaikaku and Kaizen relationship

http://www.centrodecompetitividad.com/img/kaizen.jpg

Page 19: Software Agility - Necessary...but not Sufficient

What is wrong with traditional notion of agility?

ò  Focus on sprints as a means to deliver user stories

ò  What do you do when user stories are not known?

ò  What do you do when user story is a best-effort hypothesis?

ò  Velocity as a measure connotes ‘certainty’ within a range

ò  What does it mean if you complete 100% user stories?

ò  What does velocity mean in relation to value delivered?

ò  Team productivity gains don’t scale up at business level

ò  Claims of team-level performance improvements in the wild ranges of 5x-11,000x !!!

ò  However, mature businesses in most industries only grow single-digit y-o-y !!!

ò  Agility metrics focus on efficiency and not on effectiveness

ò  Efficiency is ‘lower-order agility’ and means nothing to the business or the customers

ò  There is no focus on ‘higher-order agility’ that the business need

Page 20: Software Agility - Necessary...but not Sufficient

What might be a (slightly) better approach?

ò  Sprints are a means to test a hypothesis

ò  Strategy, Product Backlog, User Stories and even design is a hypothesis

ò  Sprint goal is to validate a hypothesis and provide a ‘validated learning’

ò  Each sprint delivers a real business value

ò  Velocity is the business value delivered to the end-user in each sprint

ò  Under/over achievement of sprint goal signals a need to revisit the hypothesis

Page 21: Software Agility - Necessary...but not Sufficient

The Lean Startup ò  Lean Startup is about learning

what your customers really want. It’s about testing your vision continuously, adapting and adjusting before it’s too late.

ò  A Startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.

ò  Innovation is a bottoms-up, decentralized, and unpredictable thing, but that doesn’t mean it can’t be managed.

Page 22: Software Agility - Necessary...but not Sufficient

Validated Learning

ò  Validated Learning is not after-the-fact rationalization of a good story designed to hide failure.

ò  It is a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow.

ò  Validated Learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects.

ò  It is more concrete, more accurate, and faster than market forecasting or classical business planning.

ò  It is the principal antidote to the lethal problem of achieving failure: successfully executing a plan that leads nowhere.

Page 23: Software Agility - Necessary...but not Sufficient

Innovation Accounting

ò  Innovation Accounting enables startups to prove objectively that they are learning how to grow a sustainable business. It involves three learning milestones:

ò  Establish the baseline: A Minimum Viable Product (MVP) helps start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Loop feedback loop with minimum effort and least amount of development time.

ò  Tune the Engine: Every product development, marketing, or other initiative that a startup undertakes should be targeted at improving one of the drivers of growth model.

ò  Pivot or Persevere: are we making sufficient progress to believe that our original strategic hypothesis is correct, or do we need to make a major change? That change is called a pivot: a structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth.

Page 24: Software Agility - Necessary...but not Sufficient

Build-Measure-

Learn Loop

Page 25: Software Agility - Necessary...but not Sufficient

What are we learning?

ò Problems are constantly mutating

ò Agile Manifesto too needs an upgrade!

ò Software agility is necessary…but not sufficient

ò New methods are needed for innovation-led new product development

ò Lean Startup is one such method to deliver kaizen on kaikaku scale

Page 26: Software Agility - Necessary...but not Sufficient

References

ò  http://www.microsoft.com/windowsembedded/en-us/evaluate/history-of-windows-embedded-compact-7.aspx

ò  http://en.wikipedia.org/wiki/Drupal

ò  http://money.cnn.com/galleries/2011/technology/1109/gallery.apple_financial_empire/7.html

ò  http://xprogramming.com/articles/beyond-agile-new-principles/

ò  http://www.justin.tv/startuplessonslearned/b/262656520

ò  http://www.forbes.com/sites/stevedenning/2011/05/04/innovation-applying-inspect-adapt-to-the-agile-manifesto/

ò  http://blogs.forrester.com/mike_gualtieri/11-10-12-agile_software_is_a_cop_out_heres_whats_next

ò  http://practicalagility.blogspot.in/2012/04/agile-in-its-second-decade.html

Page 27: Software Agility - Necessary...but not Sufficient

Thanks!

Blog: http://managewell.net

Email: [email protected]

Slides: http://slideshare.net/managewell

Twitter: http://twitter.com/TathagatVarma

My Articles: http://managewell.net/?page_id=2


Recommended