How BMC is Scaling Agile Development

How BMC is Scaling Agile Development Lessons Learned in Twelve Exhilarating Agile Months at BMC Israel Gat Vice President, Distributed Systems Management BMC Software

Major Themes
Introduction
PATROL Classic, BMC Performance Manager and Christensen
Four secret sauces we started with
Lessons Learned
Don’t agile the Agile
It is not a license to murder
Whatever you do, always stay releasable
One never has enough product managers
End-to-end
Scaling
The role of executive sponsorship
Are you ready for Agile?
Enterprise Agility (time permitting)

Snapshot, January 2005
Staring at the whites of Christensen’s eyes
The Innovator’s Dilemma was not an academic exercise for us in February 2005
… . rather, it was a reality we stared at .…
… . had to find the means to address ….
… . and chose Scrum as the vehicle for so doing .…
Realization that time was our number one enemy
Had to create momentum faster than one could say “momentum”
Transform the mood
As all too often happens during Innovator’s Dilemma situations, too many good people were too worried whether the world loves them

Snapshot, December 2005
Agile Adoption at BMC January 2005 to December 2005 Progress
Infrastructure Management Adoption
BMC Performance Mgr Infrastructure
BMC Performance Mgr Solutions
Classic PATROL Solutions
PATROL Reporting
BMC Recovery Mgmt
Other Organizational Adoptions
Exceptions Reporting and Escalation
BMC Impact Integration Dev Kit
Professional Services
Partner Certification Project (IT)
Dashboards; Identity Management; Service Management

Four Secret Sauces We Started With
Visibility, commitment, and intentionality
Agile first; the rest follows
Total immersion rather than limited trial
Management philosophy
Team confidence is built by a management team that instilled trust in them
Willingness to take risks
Giving up on top-down control of detailed feature scope
.… empowering the teams to fill the details as you go ....
.… trusting that we will hit the themes at the end .…
.… even though we can't predict how all of the notes will end up ….
Accepting we did not have all facets of Agile figured out in advance
Had the confidence we will figure them out as we go along
Top notch Agile consulting
You really need a big brother; Dean Leffingwell was mine
I doubt we would have mastered Agile at the scale and scope we applied it but for Dean and the Rally Software Development crew

Don’t Agile the Agile
Be fully cognizant you are introducing a disruptive methodology
Your own teams
Ripples beyond your organization/function
Could easily constitute a sources of friction between the Agile team and the rest of the corporation
Give the experiment enough time to bear fruit
Allow the teams to struggle up the learning curve, and establish a baseline of predictability and success
Shield the teams while struggling
Any stumbles in the first few steps, and an emergent effort with Agile can be easily squashed in a large organization.

Whatever You Do, Always Stay Releasable
It is the acid test whether you are really doing Agile or de-facto reverting to quasi-waterfall
You might be going through the motions of Agile until your feet hurt from the daily stand-up meetings and other Agile practices, but you will lose the key advantages of Agile if you do not stay releasable on an on-going basis
Productivity
Quality
Predictability

It is not a License to Murder
Rules of physics (and solid software engineering practices) apply
Integration in the overall software engineering fabric
Beware the dilettantes
“ But of course I know Agile… we just practice it a little differently ”
“ Don’t worry about this feature not being in the release – it is OK in Agile to de-commit functionality”

One Never has Enough Product Managers

Transition to End-to-End Agile Organization Agile R&D Teams R&D Teams Waterfall Optimized Organization Agile Organization Executive Management BU Mgt Sales Mgt Support Mgt Mkt Mgt Operational Team Executive Team

End-to-end Participation Direct Field Participation Release Planning I1 I3 I2 I4 I6 I5 I7 I8 Market Planning Market/Solution Release Plan Product Roadmap Product Release Plan Product Release Plan Iteration Demos / Requirements Backlog 3-4 months I1 I3 I2 I4 I6 I5 I7 I8 2 weeks Release Mgt

Scaling
The Scrum team is the fractal organizational construct
Requirements and QA architects span teams within a group
Product management spans larger groups
Process maturity is critical
The daily Scrum of Scrums keeps the various teams “real time” aligned
Process checkpoints serve as the glue for longer time spans
Iteration level
Release level
Note the points about intentionality and no half-heartedness made earlier in the course of this presentation
Basically we immersed all of the organization in Agile, rather than experimentation with a team or two

The Role of Executive Leadership
Be ready to take some casualties of people who:
Don’t want to give up control/criticality (usually the heroic types)
Don’t want to change
Can’t change fast enough
Manage empowerment and risk-taking in tandem as the foundation on which successful Agile projects evolve
Teams embarking on Agile need to cope with simultaneous changes in:
Skills Systems
Staff Practices
Structure Management philosophy
Value system
They can’t do so unless they are appropriately empowered
Empowerment and risk-taking are inextricably linked

Are You Ready for Agile?
Wholehearted Empowerment
Think once, think twice, think thrice, whether you are really, really, really, ready to empower in the full sense of the word
Half-hearted measures would not cut it
Empowerment is like an acid test – for better or worse it will give you your defining moments
It does not happen without the courage to give up the Waterfall illusion of control
Don’t take your boss out to lunch…
… take him/her to the daily standup meeting

In the Final Analysis
“ When we started with agile, I was concerned it might be a less disciplined method for development. In reality, it’s more disciplined, and provides more accountability”
[Paul Beavers; Senior Director, R&D]
“ If we used waterfall on BPM, we would still be in development. We would likely be cutting features right and left to try to bring the date back in. Changes requested along the way by the solutions teams would have been pushed back on rather than embraced. ”
[Walter Bodwell; R&D Director]
“ For me the success of the release was closely managed from the day 1 in the Release planning meeting when the senior management told those product teams with low confidence level in their plans to not forcefully fit requirements into the fixed schedule.”
[John Im; R&D Manager]
“ The team has to continuously improve the Agile process, or the temptation to become rigid and staged will creep back into the processes.”
[Mike Lunt; R&D Manager]
“ There has never been a thought towards returning to Waterfall – we only think about how to be more agile – how to do this better. No one wants to go back!”
[Becky Strauss; R&D Director]

Thank You!
[email_address]

Appendix: Enterprise Agility

Enterprise Agility at BMC Agile Component Team Agile Teams of Teams Agile Enterprise Scale (perpetual) Measurement A B C D Requirements runway Intentional Architecture Enterprise Tooling Iterate Iterate (2 wks) Design Test Build Release (3 mo) Harden and Ship Req Plan Iterate Iterate Iterate Agile Release Train Organizational Change Organizational Change Agile Release Train Requirements runway

How BMC is Scaling Agile Development

by IsraelGat on Feb 02, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 9

Statistics

How BMC is Scaling Agile Development — Presentation Transcript