I’ve been to a lot of conferences and trade shows in my career. Over the years, some of them have faded into oblivion, some of them blur together and hold no distinction in my mind whatsoever, and then – there are the few, the rare events that really stand out. I wasn’t planning to write a blog post about last week’s Mile High Agile Conference in Denver. But, I was truly inspired and wanted to share a bit about why it ranked among the one of the top conferences I’ve ever attended – a regional conference that (in my book) outranks many large-scale, national shows.
Mile High Agile’s website says that this one-day conference was created to further Agile Denver’s mission of creating and sustaining the world’s best agile community. I would assert that it exceed this goal by a long shot – creating opportunities for a national community of agilists to connect, share and learn. Mile High Agile was buzzing about Agile – engaging hallway conversations, great speakers discussing advanced topics, teams of experienced people wanting to take Agile to the next level, along with a very active Twitter stream around the show.
The number and caliber of companies attending and sponsoring Mile High Agile are big signs that Agile has gone mainstream. While the Agile movement may have started slowly with teams of developers starting to use Agile on their own, the example they set and the success they’ve achieved has Agile spreading like wildfire. At the show, I overheard team members from Fortune 100 companies ask advanced questions about best practices for scaling Agile enterprise-wide and extending Agile practices to strategic roadmap levels.
I was also struck by the fact that Mile High Agile 2011 was not only Agile Denver’s first annual conference, but it was a 100% volunteer-run event. The caliber of the conference shows the dedication of Agile Denver to both the local Agile community and the broader Agile community in general. The theme of Mile High Agile 2011 was “Elevating Agility,” and for me – the show did exactly that – extending and elevating Agile thinking, learning and community. Thank you Agile Denver – I’m already looking forward to next year’s event.
Zach Nies is a CTO at Rally Software and a proud member of the Boulder/Denver Agile community for the last ten years.
I’m excited! Next week is shaping up to be something of an epic little timebox for me: 3 keynotes in 3 different cities in 3 days. I love it! Sustainable pace? Well, maybe not every week. But next week has me fired up. I’ve got a definition of Done Done Done that has me flying high.
Here is what’s on the agenda for my 3-day extravaganza:
April 5th finds me in Chicago, an old haunt of mine.
I’ll be part of one of my favorite events with Rally and its partners: “Agile Comes to You”. The keynote? “12 Agile Adoption Failure Modes.” I’ll be talking about negative patterns for Agile adoptions. Yes, I know there are more than 12 ways to ensure an Agile adoption fails. But I only have 30 minutes to speak :-) Heading back to Chicago, I look forward to making new friends and meeting up with old friends, especially one of our panelists, Brendan Flynn of PointRoll. I’m eager to find out what Chi-town is up to with the move of Agile onto “main street” (or is that the Magnificent Mile?) Want to join us? Sign-up here, come say hello at the Chicago Marriott Downtown, and share some of your experiences and queries.
April 6th I hop over the border to one of my favorite Canadian cities, Toronto, Ontario.
Here again, I’ll have the honor of bringing my keynote perspectives on how Agile adoptions fail. I’m eager to learn with attendees what they have seen in this great city and the surrounding technology area about their Agile adoptions. And, I look forward to our discussions on how we can truly succeed in adopting Agile for great, sustainable business value. If you are in Toronto on the 6th, join us in this “Agile Comes to You” event at the Toronto Grand Hotel and Suites by signing up here.
April 7th I return home to Denver, the “Mile High City.”
And yes there is another event in store. I’m very honored to have been invited to be the keynote speaker at the inaugural “Mile High Agile” event. This is going to be a particularly special event for me. My colleagues Rachel Weston and Zach Nies will be co-presenting on “Using Agile Principles to Solve Tough Problems in Your Business.” Rally as a Platinum Sponsor is investing in our great Agile community in the Denver area. The air may be thin up here but the interest in Agile is deep and passionate. We are extremely fortunate to have a group of wonderful, hard-working organizers from the Agile Denver group: Brad Swanson, Somnath Ghosh, Walter den Haan, Tom Smallwood, Eric Cussen, Jim Turosak, Jan Beaver, and Jon Archer. Brad has worked with me to engage in one of my favorite topics for the keynote, “Elevating the Agile Community of Thinkers.” This talk affords me the opportunity to continue to share my passion about community as thinkers and thinkers as community in our Agile world. To all my friends along the Front Range here in Colorado, I look forward to seeing you at The Plaza at the Denver Merchandise Mart.
Coming full circle, my “3 strange days” will move through Agile failure modes to the great community of thinkers we gather in our Agile growth and success. As Captain Picard would say, “Warp One! Engage!
Jean Tabaka is a crash skier, college hoops shredologist, author and Agile Fellow at Rally Software Development. You can follow Jean on Twitter at @jeantabaka
The Denver Agile Success Tour continued with four open space sessions. For about 20% of the room, this was the first open space session they have ever participated in. Groups broke into discussions on leadership, testing, scaling and tooling and then did a read-out to share their conclusions with the larger audience. (For my other live posts from the Denver event, see 5 Stories of Agile Success and What’s On Your Mind?)
#1 Open Space – Executives and Agile Adoption, led by Israel Gat
This group included new as well mature Agile folks and teams of 9 to 280 people – Given that spread, there was an overwhelming agreement that “our executives do not understand it” and “I, the executive, wants the whole iron triangle fixed – time, budget and scope.” For executives who do not understand agile, it is very hard for people to communicate “What is in it for the executive?”
Conclusion – Socializing Agile is as important as doing Agile well. Your adoption will regress if your executives are not sold. Without time spent with executives, there is a bitter slide back down coming for the team. A slide like this is really hard to recover from.
Recommendation – At the point of scaling your agile adoption, contract up-front with your executive on the results, but only pick only one dimension. (Productivity, Time-to-Market or Quality)
#2 Open Space – Testing, Quality and Leadership, led by Zach Nies and Peggy Reed from Avaya
Topic time spent on willingness of test teams to move to Agile and what does pulling testing forward mean? Can I be Agile if I do not test inside the iteration? At Avaya, they do a lot of testing outside the iteration due a large matrix of configurations.
Conclusion – Make sure testing team is at iteration planning and release planning. Always honor your time box and retrospect on your testing coverage.
Recommendation – Focus on making story sizes smaller to bring testing into the iteration.
#3 Open Space – Scaling and Large Scale Adoption, led by Evan Campbell
Topics focused on collecting metrics while the guerrilla insurgency is working and before they get “busted” doing Agile. The result of not collecting metrics means getting stuck in an “Agile Ghetto.” Top-down adoption approaches are becoming more common, but came back to Rally’s Enterprise Adoption model called Flow-Pull-Innovate that is based on Lean.
Conclusion – It is inevitable that you are going to have to evangelize the Agile adoption. Start building the case from day 1.
Recommendation - Focus on the change management process for large scale adoption. Practices are a key focus for small teams, but not the key focus of large scale adoption.
#4 Open Space – Tooling Agile, led by Karen Kagiyama and Amy Wiley
Tools enable best practices, and integrations are inevitable because one tool cannot support all types and nuances of development teams and technology needs. Continuous integration, build management and test coverage metrics and reports correlate into the context of iteration, release, and program of teams are critical for know “where are we right now?”
Conclusion – The ultimate goal is a single dashboard to support the insights and planning.
I’m live here at the Denver Agile Success Tour on yet another warm, blue sky day downtown by the Convention Center. I will blog what I pick up as the key takeaways from our speakers and after the event we’ll get them to chime in with their own thoughts.
A Modus of our Time – The industry has “One foot in cold water and one foot in hot water”
Tons of enthusiasm about Agile given years of outsourcing, while also having lots of hard data showing how time-to-market, productivity and quality are improved with Agile.
But, still falling short by not pulling in the customer. We assume we know the customer problem and work hard to develop the solution. The speed and reach of software is immense.
Ray Bagley – Director of Development of 3D Modeling solutions at Spatial
Spatial – 20 year old products with 4 million lines of code. Developers spread across 3 offices (Colorado, UK, Pune). Top-down adoption started with a new VP two years ago.
“Product Owner is not Product Manager” – Read all the books on Agile. Early on divided up the product managers to support multiple scrum teams, but tons of pathology happened. The Product Managers stopped looking outward! Then, a collision of two product managers on one product. Finally, the senior and highly skilled development team felt like they lost all their decision making and influence.
Iteration 2 – Created Meta Scrums that met every two development iterations and life got much better. Added more product owners. Life is much better thanks to Rally and Enthiosys content - I wish we had found that material two years ago!
“There is a difference between a real customer and a virtual customer on two different products” – “Real customers engage on day 1, not with a beta!” The case of these two products was night and day – night (solved the wrong problem after 8 months) and day (driving revenue from the first release).
“Humble lessons learn the hard way!”
Lloyd Star – VP Development at Beatport – Digital download network like iTunes but specifically for DJ’s. Several internal teams and two offshore teams in India with stakeholders in Denver, Berlin and London.
20 months into adoption – “Many great changes, but far from complete with our adoption.”
There have been four clear “states” of our Agile adoption so far. (Cool state transition diagram of these states – If you read this blog often, you know how much I love state transition diagrams for Agile adoption. It is really about taking incremental moves to change the engines while the airplane is in air!)
State 1 – Iterations and weak backlog. Just jumped in, but we did not whip our quality issues and 3 week release process.
State 2 – Discovered the Product Owner role and the value of meetings when way up (CEO and CTO are both DJ’s and act as customers). “We understood the need for well elaborated stories and acceptance criteria.”
State 3 – Got the stakeholder more involved and made the backlog more clear and stopped over-elaborating far off stories. “The best part is the collaboration and negotiation went way up!” The art of software was starting to appear and drive trust across the company.
First two states were focused on the software team, but now states 3 and 4 are focused on the larger team and company.
State 4 – Integrating vision and release planning to drive enterprise architecture. Moved Research into Development and got IT/Operations team in synchronization with the development release cycles. Huge increase in throughput of new working code to market.
See what State 5 of the transition is but have not started this. All focused on enterprise architecture in state 4 to manage all these moving pieces and keeping them aligned with the business. Don’t confuse the Agile development process with the architectural process.
Clear call to actions:
Keep your release small and focused
Hired a very experienced Agile product owner
Have your architecture “live with your team”
Planning takes time, but it critical for alignment
Peggy Reed – Director of Performance Solutions at Avaya – 30 years of experience in software started in 1979 in writing Motorola code
Beautiful Software – Readability, Simplicity, Functional Locality, Single Function, System Minimality, Appropriate Form, Cooperative
NOT DOES IT WORK! – Is it pleasant, comfortable, seductive? It has to be something a customer wants to use!
Beautiful teams make beautiful software – Needs shared vision, deep understanding, harmony in the Scrum, empathy of the customer perspective.
Beautiful teams must – Keep the base stable through Agile development of frequent public builds that integrate across the whole. Have to always be testing with an equal balance. Completion is a measured by ALL parts of the team. Sometimes this is hard for existing teams to break the old habits.
Beautiful software teams talk a ton about their failures. What we wished we had done. Talk about dependencies on each other. Talk about feature-itis and which features really drive revenue. Talk about teamwork and team awareness. No longer software development by solos and prayer.
Value of us comes from creating beautiful teams that create beautiful software in a creative way – a way that can not be outsourced or automated!
Peter Fisher – MIS Product Manager at eCollege – Working on Scrum for the last two years Pearson eCollege online learning with teams in Denver and Sri Lanka
Were a very large waterfall team with huge business requirements document – Informal adoption started in 2007 and formal training started in mid 2008. Four releases since mid-2008 versus 1 and no more “bug builds.” Have been able to build the quality in from day 1.
Now developers are focused on building what they need to meet the tests and not their own vision. Key to this was delivering to the integration server continuously. As a result, the “come backs” of release went way down. Only released to staging and production once.
This dramatically increased the speed of the team and clear visibility has allowed us to react at each two week iteration with strict prioritization. As a result, were not delivering the wrong or unwanted features. Throughput is going up.
Israel Gat – on his adoption experience at BMC Software
Four simple principles make the secret sauce of enterprise scale adoption at BMC. It is all about mindset and not the practices.
In year 1 from zero to 350 scrumers in Rally at BMC. He now showed the Cutter Consortium / QSMA slide of BMC Productivity Index of 27 versus an average of 6 to 16 in other software types.
“How many of your teams come to work on Monday determined to produce poor quality software?” Agile teams do not have this mindset.
Principle 1 – Leadership and social contract with the team.
Principle 2 – Know How – I used Rally with a 50/50 spend on professional services and coaching while the other 50% was used for Rally’s application – this combination was critical to go as fast as we did.
Principle 3 – Flexibility - You have to take the adoption incrementally and iteratively.
Principle 4 – Patience - You can not Agile the Agile – you are changing the software, the process and the organizational structure.
Late last year, we held an event in Austin where four customers spoke about their experiences with Agile development.
One of the big discussions that we had centered around how to successfully roll-out Agile across a team or organization. In the posts that follow, authored by several speakers from the event, you’ll find some different takes on Agile roll-outs. I’ve also posted video segments from the event.
We launched that pilot event into a nationwide tour in 2009, of which the first stops are Denver Mar 18, Los Angeles Mar 26 and New York City Apr 2. Depending on your city, speakers are AOL, Avaya, Beatport, BMC, Condé Nast Digital, eCollege, Gorilla Nation, MPower IT, NBC Universal, Qualcomm, Real Capital Markets and Spatial.
It’s free, but you do need to register on our web site.
(UPDATE : new event dates are being added regularly and can be found here)
How did you roll-out Agile development – team-by-team, all-in, another way? And what did you learn from the experience?
There has been an ongoing debate in the Agile/Scrum world on how to implement and roll-out Agile. Some advocate a deliberate, department by department or project team by project team approach, while others are fans of an “all in” rollout.
The roll-out of Agile at BMC Software was fast paced. With help from the Rally Services organization, we grew from zero to 350 Scrum users in one year. Today, four years after we started rolling Agile, BMC has about 1,000 Agile users in various business units.
As fast as that the roll-out was, it was definitely gradual by design. As a matter of fact, the momentum the Agile roll-out generated made some of the more passionate potential Agilists unhappy with me when I told them “Don’t start Agile yet; your time will come.” Some actually told me they were experimenting with “pseudo Agile” (whatever that might mean) in preparation for a full-fledged Agile training, coaching and implementation regimen. I actually suspect that an “all in” Agile rollout might have carried the day in Spring 2005 if the business unit employees were allowed to choose. “There has never been a thought towards returning to Waterfall – we only think about is how to be more Agile – how to do this better. No one wants to go back!” was the overarching mood throughout the product management, development and quality assurance organizations.
Despite the popularity of an “all in” rollout, I decided to implement Scrum team by team. This decision was based on the following reasoning:
The nature of software. My fundamental view of software is that is craftsmanship. If you accept this premise, apprenticeship is probably the best paradigm for learning how to do quality software. I had a few Rally “masters” available to me - consultants like Jean Tabaka, Ryan Martens, Dean Leffingwell and Hubert Smits. I looked to these masters to develop the Agile experts at BMC Software. These experts, in good time, propagated the art of Agile to other BMC teams.
The nature of the software process. In my humble opinion, software evolves in a continuous manner, one feedback loop after another. Hence, I expected the Agile process model itself to evolve. However, I did not know in what way(s) it would. As I learned along the way, each of the three product lines in the business units developed their own variant of Agile.
Development of institutional knowledge. I did not want each team to reinvent the wheel. I was betting on being able to leverage the shared learning across teams. This learning and knowledge sharing required some things to go in a sequential manner.
Phased unlearning. Numerous deeply rooted Waterfall practices had to be unlearned. I deemed massive parallel unlearning too risky.
Distributed Agile. In addition to US-based development labs in Austin, TX, Houston, TX and Sunnyvale, CA, the business unit had development labs in Tel Aviv, Israel, Tel Hai, Israel and Pune, India. I did not believe I knew enough in late 2004 and early 2005 to effectively rollout full-fledge distributed Agile. In 2006, however, I read Jeff Sutherland’s paper on Fully Distributed Scrum. This convinced me that I needed to expand Scrum across the pond(s) along the lines Jeff proposed. For more information on distributed Agile teams, review Jeff’s slides from his talk at Agile 2008.
Cultural uncertainty. For an ”all in”approach to succeed, the approach to Agile needed to be fully integrated with BMC’s core culture. Since I had only been at BMC for a few months when I began the Agile implementation, I did not feel confident that I knew the BMC culture well enough then. Hence, I preferred to roll gradually.
Sometime in the Fall of 2008 I received a review copy of Jean Tabaka’s Leaning IT: Applying the Principle of Pull to Scale Agile Teams. It was immensely gratifying for me to discover the Agile roll-out paths Jean identified as dead-ends. My retrospective hunch is BMC would have hit one or more of these dead-ends had we been too aggressive in deploying Agile in early 2005. Jean and Ryan also did a Secrets of Agile Adoptionwebinar on this topic that readers may find of interest when considering which approach to take.
Clearly I am a proponent of a team-by-team implementation approach. However, the “all in” implementation demonstrated by Erik Huddleston at Inovis is intriguing to me. Knowing Erik very well, I have absolutely no doubt he made the right decision for the set of circumstances, constraints and business imperatives that prevailed at Inovis in 2007. I am anxious to learn of his considerations for a “all in” rollout. I am very much hoping that between Erik,me and various readers of the blog we will develop a framework, along with a set of considerations for assessing when to go team by team andwhen to take an “all in” approach.
About the Author: Ryan Martensis an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by emailor RSS.
RallyDev.com
