What Is a Culture of Innovation, and How Do You Get It?

Organizations can’t limit themselves to operational excellence without expecting disruption.

They have two options: disrupt or be disrupted.

Yet innovation is not what most people think — it isn’t about “inventing the next new thing” or R&D. It’s about continuous experimentation. Today even older, large organizations are learning how act like start-ups. Agile and Lean are key ingredients in making this happen in the short, medium, and long term.

PRESENTER:  Joel Semeniuk is a founder and chief innovation officer/incubation director at Imaginet Resources Corp., a Canada-based Microsoft Gold Partner and the number-one small- to medium-sized employer in Canada. Joel also served as the executive vice president of Innovation and Agile Project Management at Telerik. Joel has a degree in computer science and is also a corporate Microsoft regional director. Previously he was a Microsoft Most Valued Professional in the area of Application Lifecycle Management and Software Architecture.

Read more


How to Change an Organizational Culture: SRI, the creator of Siri, the iPhone virtual assistant

Most efforts to change an organizational culture fail. Efforts to create an innovative organizational culture are typically even less successful. Yet some succeed. One extraordinary example is SRI International (SRI), the creator of Siri, the iPhone virtual assistant.

In 1998, SRI was practically bankrupt, with a toxic, distrustful culture. Over the next 16 years, SRI turned into a highly profitable, collaborative serial innovator with a string of multimillion dollar innovations, including Siri. In this webinar, Curt Carlson, who was the CEO of SRI during this period, explained how the company did it.

Read more


How to Change an Organizational Culture: Moving Way Beyond “What Sort of Works”

Agile was implemented company-wide at Geonetric after experiencing early success with Agile adoption in their software teams.

“We saw software releases hitting targets,” Eric said, “meeting both scope and deadline requirements. Our software development was accelerating with each sprint, almost doubling in speed over the course of a year.” Eric felt challenged by the boundaries of traditional management thinking. “As a team, we recognized the traditional management model was broken.”

After a lot of soul-searching, Geonetric took the huge leap — and capital investment — to rethink everything and apply Agile across the entire organization to the furthest extent they could imagine.

In this presentation, Eric will demonstrate how to:

  • Flatten the org chart
  • Ditch traditional departments
  • Open up in radical transparency
  • Create a peer-accountable culture

Read more


Running an Agile Release Planning Meeting, with Dean Leffingwell and Jennifer Fawcett

Release planning is the “pacemaker” of enterprise agility and the Agile Release Train (ART) which aligns the Agile program to a common mission.  Based on nearly a decade of experience, Dean Leffingwell and Scaled Agile have developed a process which has worked with small trains of 40 people to larger trains of 180.

This webinar explains what it takes to run a successful Agile release planning meeting from a scaled point of view (100’s of teams).  Hear real stories and feel what it’s like to be a Release Train Engineer!

What you’ll learn:

  • Overview of Agile Release Planning
  • How to prepare, content preparation, executive, product, and architectural briefings
  • Release Planning Days 1 & 2, ceremonies and timelines
  • Beyond the basics, logistics, and evolution

Read more


Case Study into Leveraging Scaled Agile Framework™ in Mixed Waterfall and Agile Environments

While the adoption of Agile practices has become more and more prevalent in the industry, it’s clear that many large organizations are often unable to go “all in.” Even as we attempt to isolate initial use of Lean and Agile methods in a “pilot” environment, external forces often exist that prevent a “pure” implementation.  Waterfall and Agile/Lean can co-exist.

This Agilista PM webinar will dive into 3 real life situations with mixed Agile/Waterfall environments to show you:

  •   How Agile projects can align their plans to a Waterfall project when they are not in sync?
  •   How Waterfall projects can operate within a fixed cadence?
  •   How to deal with potential issues that may arise in these mixed environments?
  •   How to know when things are not working and when to make some changes?

Read more


Filling in the Scaled Agile Framework (SAFe)

Frameworks are great, and the Scaled Agile Framwork (by Dean Leffingwell) provides a great context for Agile at scale.  One still needs to fill in frameworks with proven, established ideas. This webinar presents some of the basic principles of Lean that have guided the creation of proven methods that have worked at several large organizations (300-4000 person development organizations).  It continues by presenting 4 case studies that illustrate these principles in action:

1.    The value of cross-functional teams and how Lean-Flow can help you create them
2.    Coordinating multiple teams with a common backlog
3.    Creating a hybrid method based on Lean-Flow to solve integration problems
4.    Handling multiple business stakeholders and multiple teams – the need for the business product owner

The methods described in this webinar can help organizations that have successfully spun up teams only to find them languishing at the enterprise level.  It can also provide guidance for large organizations about to transition to Agile.

Read more


Agile Open Southern California Conference 2011 (Sep 15-16)

THEME:  People, Principles and Performance

WHEN:  Thursday and Friday, September 15 & 16
WHERE:  University of California, Irvine

What is Agile Open California?

You don’t want to miss this! Imagine an event where experienced Agile practitioners and newcomers alike come together for two days to discuss, examine and otherwise brainstorm the most timely and relevant topics in Agile development today.

Agile Open California is a coalition of agile practitioners and advocates intent on providing an opportunity for learning, networking and growth to the Agile community in California and to others who are interested.

What Will I Get?

  • A 2-day conference pass – up to 24 sessions to choose from each day
  • Continental breakfast and lunch both days
  • A networking reception on Monday evening
  • Free Agile Alliance 1-year Membership – a $100 value! With your registration and attendance, you can receive a free one-year membership in the Agile Alliance, which is a $100 dollar value. Just check the option when you purchase your ticket!

Read more


CASE STUDY – British Telecom’s Transition to Agile


It is becoming clear, not least from the pages of this publication, that agile development methods are being adopted or at least considered by a growing number of software development teams & organisations. Whether you are already an active practitioner agile development,or considering its adoption on your project, you will be aware of the business benefits that can be derived through faster and more effective software delivery not to mention the motivational impact it can have on development teams.Alternatively, maybe you work for a large organisation that has yet to make any serious inroads into agile development, and are left wondering how agility could be made to work on a large scale.

If you’re in the latter camp, or even if you are not actively considering agile development as such but are struggling to deliver large and / or complex programs using traditional approaches and wishing there was a better way, then you are probably where British Telecom (BT) found itself in 2004. That was before the arrival at the company of a new CIO who systematically set about replacing the company’s long-standing waterfall-based delivery processes with one that embodied the key principles of agile delivery.

This article presents an overview of the approach taken by BT, illustrating how agile development principles can be applied successfully at the enterprise level. Needless to say, the approach taken by BT is not for the faint hearted – it has included a high degree of risk, and certainly a lot of pain. Now well into its second year however, although the transformation is far from complete, it is already paying dividends.


BT employs some 8,000 IT professionals in a variety of roles including project & delivery management, architecture & design, software engineering, integration & testing, operational support and service management. Much of its internally-focused development work has traditionally been channeled through a number of business-focused delivery projects or programs, ranging from quite small, simple developments to large-scale and complex business solutions, the latter tending to be the norm.

The predominant delivery approach, certainly for the larger delivery programs, was very much waterfall-based. The use of agile development practice, notably DSDM and Scrum, was limited to a small number of fairly small, self-contained development teams. BT was in fact one of the founding members of the DSDM Consortium and took an active part in shaping the method in its early days.

Despite successfully delivering a number of large, complex solutions into a dynamic, competitive yet highly regulated business environment, many significant transformation programs were struggling to deliver any notable results in an acceptable time-frame. As part of a CMMI-inspired improvement strategy, efforts had been made to formalize acknowledged best practice processes into a standard delivery methodology. In 2004, this standard methodology was in the process of being rolled out when the new CIO made it clear that an entirely new agile approach was needed.

Drawbacks of the waterfall

Reinforcement of current waterfall-based practices was not really the answer however. Many of the delivery problems experienced at BT, and no doubt other large organisations, stem from the nature of the waterfall lifecycle itself. Some examples of these problems are given here. For a more complete demolition of waterfall practices, refer to Craig Larman’s excellent work [1].

Poor requirements capture

Capturing requirements certainly isn’t a bad thing. On typical large programs however,

  • Individual business stakeholders are anxious to incorporate all of their known requirements into the first / next release
  • “Gold users” generate hundreds, if not thousands of detailed requirements that often bear little relationship to the business problems that needs to be addressed
  • Most if not all requirements are given a high priority
  • The requirements themselves, at best, represent today’s view, which will certainly have changed by the time the requirements are actually implemented
  • Disconnected design
  • Given the sheer number of requirements, the design community finds itself spending most if its time trying to figure out what they mean. Meanwhile,
  • The requirements analysts move on to other projects, taking with them important tacit knowledge
  • Some stakeholders become concerned that their requirements are not being adequately addressed, and therefore refuse to sign off the designs
  • Other stakeholders unearth more requirements or raise change requests, diverting scarce design expertise onto impact analyzes

Development squeeze

With the design stage having slipped, development teams find themselves under intense pressure to deliver components into the integration environment by the originally agreed date. In fact, they often take the decision, reluctantly, to start development against an unstable design, rather than do nothing or divert resources to other programs. Inevitably, system testing is cut short so that original timescales are met and the program is seen to be on target.

The integration headache

The integration team has a set number of weeks during which it needs to integrate what it expects to be fully functional and relatively bug-free code. Because of the instability of the component code, and the lack of any effective regression test capability, effort is instead diverted to trying to resolve elementary bugs in the delivered code, liaising with a development team that is now engaged in the next major release. Actual integration therefore runs into months, creating a knock-on effect on other programs requiring the services of the Integration team, not to mention frustrations within the business community who had been busy preparing themselves for an on-time delivery.

The deployment nightmare

It is now at least 6, or even 12 – 18 months since the business originally identified the need for this particular solution. Compromises and oversights made during the requirements and design phases, followed by de-scoping during development has resulted in a solution that bears little relationship with what was originally envisaged. Besides, the world has actually moved on in the meantime. The business then finds that the solution is not fit-for-purpose and refuses to adopt it. Worse, they adopt it and soon find that it is slow, error-prone and lacks key features, and eventually revert to the old system. The end result – more shelf-ware!

Early in each delivery cycle, the program sets out clear targets for what it expects to achieve for the business during that cycle. These targets invariably include a strong emphasis on the end-customer experience, such as overall response times, transaction success rates, and so on. At the end of the cycle, the program is assessed against these targets, and the outcome of this assessment will influence the timing of bonus payments for the program team members. Programs failing to deliver business value over a series of cycles face being closed down altogether.

This of course places a certain amount of pressure on the (internal) customer to be clear about the business priorities and the features that would provide the greatest return on investment. It also requires that the customer is ready and able to deploy the solutions into the business and realize the intended benefits. In practice, programs often take two or more 90-day cycles to progress a particular solution to a point where it is fit for deployment. Even so, there is an opportunity at the end of each cycle to assess what has been delivered so far, and to provide feedback based on what has already been developed.

Agile Development

Although not intended to be a “silver bullet”, Agile Development should help resolve these problems. For example,

  • Focusing only on what’s really important to the business will help overcome the tendency to want to document all requirements up-front. Techniques such as User Stories [2] often proves helpful here.
  • Involving your customer as part of your team certainly helps ensure that the solution is developed in line with expectations, and doesn’t incur too many surprises once completed
  • Developing in short iterative cycles again helps to break the problem down into more manageable chunks, and allows feedback to be gleaned early and often. The Scrum [3] method, for instance, advocates 30-day cycles.
  • Applying a ‘test-first’ and continuous integration development approach, two of the core practices of XP [4], not only helps to further break down the complexity of the problem but also avoids the ‘integration headache’ described above

The Challenges of Enterprise Agile

This is all very well when you have a development team of some 10 or 20 people, or if you are implementing agile development on perhaps one of your larger (say, 100 people) projects and have ample mentoring resources at your disposal. Even then, if you’re adopting Agile for the first time, you have the challenge of changing people’s mindsets, aligning the new practices with a supportive customer, while also remembering to successfully deliver the actual project.

For most large organisations, architectural considerations also need to be addressed. Also, no doubt a high proportion of the code base is probably implemented in the form of third-party Commercial Off-The Shelf (COTS) components. On top of this, you then have the added complexities of off-shore development, widely distributed in-house resource, an IT department that is probably not highly regarded within the business, plus a whole pile of legacy code for which tests probably don’t exist in any shape or form let alone automated.

Finally, your program has significant business commitments to make, and little scope to take on the added risk of adopting new practices. So where do you start?

Scaling to the Enterprise – The BT Approach

At BT, the drive towards agile delivery started with an uncompromising determination to introduce shorter delivery cycles across the entire delivery program portfolio, establish a ruthless focus on delivering real business and end-customer value, and to nurture a strong collaborative ethos between the IT and Business communities.

90-day cycles

With more or less immediate effect, all delivery programs were required to adopt a standard 90-day delivery cycle. That is, having picked up one or more distinct business problems on day 1, a working solution is expected to be available, fully-tested, for deployment by the end of the remaining 90 calendar days. For BT, this represented a seismic shift from the 12+ month delivery cycles that were previously commonplace.

Each 90-day cycle is kick-started by an intensive 3-day “hot house” in which cross-functional teams explore one or more business problems in some detail, with the main stakeholder(s) usually being at hand to resolve any queries. Out of each hot house, the intention is that one or more working prototypes are produced which, if accepted by the stakeholder, forms the basis of the development activity for the remainder of the cycle.

For the remainder of each cycle, the intention is that wherever practical, programs pursue agile development practices such as more fine-grained iterative development (e.g. 2 – 4 weeks),

Step 2 – Focus on Delivering Business Value

Early in each delivery cycle, the program sets out clear targets for what it expects to achieve for the business during that cycle. These targets invariably include a strong emphasis on the end-customer experience, such as overall response times, transaction success rates, and so on. At the end of the cycle, the program is assessed against these targets, and the outcome of this assessment will influence the timing of bonus payments for the program team members. Programs failing to deliver business value over a series of cycles face being closed down altogether.

This of course places a certain amount of pressure on the (internal) customer to be clear about the business priorities and the features that would provide the greatest return on investment. It also requires that the customer is ready and able to deploy the solutions into the business and realize the intended benefits. In practice, programs often take two or more 90-day cycles to progress a particular solution to a point where it is fit for deployment. Even so, there is an opportunity at the end of each cycle to assess what has been delivered so far, and to provide feedback based on what has already been developed.

Step 3 – Instill a Collaborative approach

Truly successful programs require a strong partnership approach between the business customer and the development community. Within BT,close collaboration is established at the outset of each project through attendance at the hot houses. The onus is then on the program teams to ensure this collaboration continues throughout the delivery cycle through design walk-through sessions, prototype reviews, and so on.

In practice, the end-user representatives you want to have at your hot house are also the ones who are hardest to release from operational duties. With several programs running numerous hot houses during the course of a year, this problem can quickly become compounded and often makes it extremely difficult to achieve true collaboration on a day-to-day basis. However,collective ownership of the eventual solution needs to become the accepted norm, and any practical steps to enhance collaboration should be taken.
Early Reflections

Despite some turmoil at the start, and some painful failures among some of the earlier hot houses & delivery cycles, the new practices have now become accepted as the norm across BT. Now well into the second year of its shift from waterfall to agile delivery practices, few people would be willing to revert to pre-Agile practices. In fact, most programs are now seeking ways of refining their delivery processes further by adopting truly iterative & test-driven development practices within each delivery cycle.

However, some observations would be worth noting.

  • Firstly, when you’re embarking on an agile delivery strategy at the enterprise level, it is imperative to quickly establish a ‘critical mass’ of people who not only grasp the ideas behind it but are also comfortable with its application. To establish that critical mass, you will probably need to turn to outside help. A number of consultancies now specialize in the adoption of agile practices within large organisations. BT chose to use two different companies, each of which brought different strengths and perspectives. Further to this, it is also essential to establish a strong central team to provide ad-hoc support, nurture the new techniques, and to actively support the new practices.
  • Certain agile practices, such as test-driven development, are harder to adopt when most of your development is based on legacy code and / or externally-sourced components. Similarly, continuous integration becomes extremely complex when some of you main components are shared across multiple programs. Some of BT’s programs are now pursuing test-first and continuous integration techniques, but this takes time and investment and is only being done on a selective basis.
  • For Agile Development to work at the enterprise level, you still need to pay due attention to your systems architecture. “Big Design Up-Front” (BDUF) may not appeal to the agile purist, but re-factoring of an enterprise architecture simply isn’t practical.
  • Not all delivery activity fits neatly into the agile development model. Given a choice however, the natural tendency is to pursue most activities using the traditional approaches – you can always find some excuse why “the new approach” isn’t appropriate on your project. If you go down this road, agile delivery will at best become a niche activity. At BT, a strong mandate ensured that all programs put the new practices to the test whether this seemed logical or not. This helped to break through the “pain barrier” and to ensure that the new practices were given a real chance of taking hold.
  • To be truly effective, the agile approach needs to reach right across the business, not just the IT organisation. You might expect that the business would be excited at the prospect of having regular deliveries of valuable functionality. However, the business also needs to move away from traditional waterfall practices and change how it engages with the IT organisation. It also has to place its trust in the IT organisation (something that certainly takes time) that it will deliver as promised. It then needs to ensure that it is geared up to exploit the deliveries to gain maximum business benefit.
  • Finally, remember the old adage – “There’s no gain without pain!” Applying the principles described here on large projects or programs in typical large organisations requires courage, determination, and no small degree of risk. Also, such a radical strategy requires absolute commitment from the very top.


Re-orienting a large IT organisation from pursuing well-established waterfall-based delivery approach to being a truly agile delivery unit takes patience and time, as well as a lot of commitment. In BT,where the initial steps towards enterprise agile delivery were taken late 2004,there has been a noticeable and decisive shift away from waterfall-based thinking. It has also transformed, quite radically, the traditional function of the IT department as a supplier of IT services to one where IT is now seen as integral to all major business initiatives. Above all else, it has created an attitude, bordering on obsession, of delivering real value to the business through IT.

Despite the early successes however, it is clear within BT that there is still a long way to go before it can consider itself to be truly agile. For any large organisation, the journey from waterfall to agile can be very long and challenging. As with other proponents of Agile Development however, few at BT would want to turn back to the old ways.


  1. “Agile & Iterative Development” by Craig Larman, Addison-Wesley (2004) ISBN: 0-13-111155-8
  2. “Agile Software Development with Scrum” by Ken Schwaber & Mike Beedle, Prentice Hall (2002) ISBN: 0-13-067634-9
  3. “User Stories Applied for Agile Software Development” by Mike Cohn, Addison Wesley (2004) ISBN: 0321205685
  4. “Extreme Programming Explained” by Kent Beck & Cynthia Andres, Addison Wesley (2004) ISBN: 0321278658
  5. “Lean Software Development – An Agile Toolkit” by Mary Poppendieck & Tom Poppendieck, Addison Wesley (2003) ISBN: 0321150783
  6. Agile Manifesto – http://www.agilemanifesto.org

Author: Ian Evans, British Telecom.  This article was originally published in Methods & Tools of Methods & Tools.  Slides of the case study can be downloaded here.

* * * * * * * * * * * *

Like what you see? Get hot news on the Agile-Lean community, upcoming webinars, case studies and tools delivered right to your inbox weekly to help you be as Agile-Lean as possible. No spam or junk mail. You can unsubscribe at any time.




SUCCESS STORY – What really happens during Agile Adoption projects

The Agilista PM interviews a seasoned Software Development Coach, Bob Maksimchuk,  who shares his experiences from a Software Development project with a goal of becoming CMMI level 3.  We focus on how Agile practices were adopted in a traditional Waterfall and Command-n-Control environment.

The company wanted Bob to help them start using Agile for 3 key reasons:

  1. Deliver releases on-time,
  2. on-budget,
  3. and most of all: Attract and compete for NEW business.

In this 60 minute interview, Bob shares…

Read more


VIDEO – What People Are Really Doing in Practice with Agile

I found a great discussion on InfoQ that summarizes the results of 4 years of industry surveys concerning the adoption and effectiveness of agile techniques. Very often the reality is significantly different than the rhetoric presented in mailing lists, in articles, and even in books. Many myths or ideas around Agile are explored, and some are proven false and some confirmed to be true based on survey results.

SPEAKER – Scott Ambler works with IBM as Practice Leader Agile Development within IBM Software Group. He has worked in the IT industry since the mid 1980s and with object technology since the early 1990s. He has written several books and whitepapers on OO software development, software process, Agile Model Driven Development, Agile Database Techniques, the Agile UP, and the Enterprise Unified Process (TM).

Click here to LISTEN to Webinar Recording