Rally in Raleigh; Success in becoming a Whole Cupcake? - Sep 7

Source: Agile Development Blog: Scaling Software Agility - Ryan Martens

Did you know that some people pronounce Rally and Raleigh the same?  It is also a tongue twister to say them together.  These are two of the more esoteric things I have learned in the eighteen months following our acquisition of 6th Sense Analytics.

Five Fingers for a great Q2 and great North Caroline BBQ

This is in the forefront of my mind following a recent trip to Rally’s Raleigh-Durham, North Carolina office. After Agile 2010 in Orlando, Jean Tabaka and I visited our largest remote office in their new digs.  We were there to help share in their Q2 Celebration event.   It was a real pleasure to see that office filling out and becoming whole.  (more on the cupcake thing below)

Becoming whole is so critical for a remote office and for an Agile team.

When I was working at BEA, I was part of an amazing machine that really knew how to acquire companies.  BEA learned from Cisco about how to do this right and how to balance autonomy and culture to create a healthy soul for an office away from the corporate headquarters.  Typically, BEA moved one or two folks to the remote facility to become active managers and help provide local leadership. These embedded people helped make the transition smoother by transferring norms, values and informal networks of the existing organization to the newly acquired team.  In fact, BEA would not move forward with an acquisition deal unless it had management bench strength who were willing to move and play that role.

We compensated without management bench strength.

In Rally’s case, we did not have that management bench strength to move folks from Boulder to Raleigh. As a result, we lived through what some folks on the team called “open wheel racing.”  We had a lot of rubbing and bumping.  We struggled as Boulder team and Raleigh team tried to figure out the balance between autonomy and culture. And we were tackling this cultural bumping while working collaboratively on the same product and sometimes in the same code-base.

We knew we had to address the lack of local leaders from corporate and so we started with 3 specific practices:

1. We stuck with eight-week agile release cycles. This frequent synchronization really helped keep the wheels on both cars.  To help jump start real collaboration for the releases, the Raleigh team flew out to Boulder for most of the release planning meetings in 2009.
2. Within the releases, we chose to develop a vast majority of the Raleigh code as a separate service running in separate application containers. This supported the Raleigh team having almost complete ownership of the functional value they delivered.
3. We added HD Video conferencing to support frequent meetings and open worm-holes to broaden communication channels beyond emails, IM, and phone calls.

Our next steps brought in additional agile team members.

Since the acquisition of 6th Sense in late 2008, we had a only a partial agile team in Raleigh.  To complete the team, we added a development team lead and a product owner in Boulder.   In 2009, the Raleigh team released Rally’s customized reporting service and time-tracking capabilities.  Todd Olson’s ability to lead the Raleigh team in collaborating with the existing team in Boulder was yet another critical piece in our path to integration.  Todd was the original founder of Six Sense and the spiritual leader from founding and past experience in ALM space with Together J and Borland.

Todd and his daughter enjoying one from the Cup Cake Shoppe in Raleigh

This summer, the office moved into a larger space to accommodate our hiring efforts in Raleigh.  So far this year, we have hired or moved six new people into Raleigh and we are not done.  Shameless plug – “In fact, we have 21 open positions at the company in Boulder, Raleigh, London and in the field.“  Part of the Raleigh growth was due to the AgileZen acquisition in April.   In January, we were feeling good enough about our lessons learned with the 6th Sense acquisition to make that move.  This time, instead of moving Rally people to where AgileZen lived, the AgileZen team moved to our Raleigh office.  We found out about their intention to move during the negotiation process and it was a huge green light in the transaction. (Think like BEA above – makes balancing autonomy and culture much easier when the management bench can not support the acquisition.)

Based on some of the joy, happiness well-being and cupcakes! (These were no ordinary cup cakes, they were from the Cup Cake Shoppe – made famous by President Obama during the Healthcare debate. We found out the owner is a great lady as she even chauffeured our own Susan Ruh to the new office!) Jean and I witnessed all this during our Q2 celebration visit, Rally Raleigh has certainly taken strides to build a cohesive agile team in a period of growth and integration.

But, there is still more to do

We recognize that there are always items in our organizational backlog.  As the Raleigh team continues to build the whole, we owe a bunch to the folks who were closest to the open-wheel racing process.  They kept their cool, did things to build empathy for the other team and kept focused on delivering value.  For Rally as a whole, we still have a lot to learn about running remote offices in a culture that is much more collaborative than what any of us witnessed in the last decade at BEA, Borland, Mercury, Quark, Rational, or Serena.

Please comment your ideas or experiences with remote offices and highly agile teams.

Ryan Martens is a tomato canner, school board member at Friend School Boulder, and CTO at Rally Software Development.

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development.

No Impact Man – A cool Gift - Sep 3

Source: Agile Development Blog: Scaling Software Agility - Ryan Martens

On Wednesday, I received a copy of Colin Beavan’s book called No Impact Man.   I owe a big thank you to Michael Mah of QSM Associates for the gift.  Michael and I have talked together at numerous Agile and Rally events over the past four years.  His work has been instrumental at proving the benefits of Agile by benchmarking Agile projects against their database of 7500 projects.  He has clearly seen me talk about my personal quest to get my family’s carbon and environmental footprint down, as well as our work at Rally on our corporate footprint.

My take away: As you share your personal or professional vision with others, it becomes easier for them to help you attain it. It is a wonderful reinforcing loop.  Thanks again Michael.

(Click on Book to see at Amazon)

This is a book about Colin and his family, who live in New York City, and how they lived for a year with a zero environmental footprint, not just a zero carbon footprint.  I have broken the cover on the Introduction and the first chapter.  It looks like a great and funny read.  Based on my Amazon search, there is even a movie/DVD on the book.

Here are some Chapter titles, to give you a bit of the feel:

• What you think when you find your Life in the Trash
• If Only Pizza Didn’t come on Paper Plates
• Conspicuous Nonconsumption

I look forward to finishing the book on my next plane trip, which is coming in two weeks to the Oracle Open World/Java One/Oracle Developer’s Conference.  I am speaking there on the “Linchpins for Scaling Software Agility.” This talk is on Wednesday morning in the San Francisco Hilton, right before Ted Farrell.  Please join us both as we explore the needs and tools for team hyper-productivity.

Five Reasons Why CIOs Should Consider Agile Development - Aug 24

Source: Agile Development Blog: Scaling Software Agility - Ryan Martens

Michael Hugos, principal at Center for Systems Innovation [c4si], writes, speaks and consults on strategies for IT and business agility and mentors development teams. He spent six years as CIO of a multibillion dollar distribution cooperative developing a suite of supply chain and business systems that transformed the company’s operations and revenue model. He won the CIO 100 Award and Premier 100 Award for his work. He’s author of several books and writes an online column for CIO magazine called “Doing Business in Real Time.” We recently met with Michael at the Agile 2010 conference, which resulted in “Agile is Ready for the Enterprise” and sparked the idea for this blog post.

Rally asks: What issues and trends are you seeing across technology departments, development teams and in discussions with CIOs?

Michael Hugos answers: The example set by companies such as Google, Facebook and Netflix shows how companies can use iterative development to continuously enhance products and grow market share. This is being noticed by business and technology leaders in other companies and they are asking if they can do the same thing to drive development in their own companies. People realize that IT is right down the middle of everything a company does, and that traditional software release cycles of once a year, or even once a quarter, are not able to keep up with the pace of change and innovation these days.

Just like the word “athlete,” the word “Agile” grabs your attention; it sounds great. But moving from desire to reality always tests peoples’ commitment. A lot of companies are struggling with the all-too-common reaction of, “That’s not the way we do things here…” Agile approaches are interesting and fascinating to companies, but then there is the tendency to immediately criticize new ideas – we’re all prone to it. As soon as someone suggests a new way of doing something, we all think of 10 reasons why that can’t be done or why it won’t work.

Rally: What is driving enterprise adoption of Agile?

MH: To begin with, agility is no longer just a good idea; it’s now backed by law – the law of probability. This law says if a company can’t keep up with rapid rates of change in the world then its probability of success is getting smaller and smaller every day. And since companies need IT infrastructure and applications to operate, just as our bodies need a nervous system and muscles to move, IT agility is critical for a company to achieve business agility.

In the last few years, software tools have enabled executives to measure and track progress on Agile projects and to see the performance of Agile teams in widely dispersed geographical locations. That makes Agile methods more feasible for large companies. A pervading feeling exists throughout business that just about everything else has been tried and IT groups are still not really keeping up with the backlog of user requests. Users are starting to go around IT and do their own things using SaaS, social media and mashups to put together systems. So why not give Agile a try?

Rally: How do Agile methodologies help large organizations foster, regain or accelerate the pace of innovation?

MH: Agile practices offer the best way to improve communication and collaboration between business and IT. Meaningful innovation always starts with communication and collaboration. Another thing that Agile practices enable is the ability to try out new ideas and explore opportunities quickly without investing a lot of money up front. With more traditional approaches, companies invest a lot of time and money planning up front before they start something new. This is expensive. And since most new ideas don’t pan out in the end, this traditional approach makes it difficult (if not impossible) for companies to try out enough new ideas in a year to find that small handful of ideas that do work out and deliver the profits they are looking for.

I like to say that in this high-change and unpredictable economic environment, companies need to: “Think big, start small and deliver quickly.” That’s the best way to keep up, adapt and respond to change, and find the opportunities they are looking for. Agility means letting go of slow, deliberate decision-making in favor of quick, repeatedly-tested decisions. That’s why Agile methods are so appropriate for energizing companies and helping them develop innovative products and services.

Rally: How do you make a case for Agile and address the fears of risk-averse CIOs, CTOs or CEOs?

MH: First, I remind executives of something that has become a fact in the last 10 years: business operations and technology are so tightly intertwined that there is no meaningful distinction left between the two; you can’t do business without technology. That might seem obvious to many but, executives who have been around for a while (like me) may still remember the days when IT was just a back office operation.

Once people acknowledge this reality then I point out that, over the last 10 years, Agile practices have been thoroughly field tested and have an impressive track record for delivering success. There are software tools now, like Rally and others, that address Agile project management and reporting, business and IT collaboration, software testing, and the continuous integration of new software with existing systems infrastructure. So going Agile is not just a leap of faith anymore.

Agile is actually a better way to manage risk versus using traditional waterfall approaches. With Agile practices, big projects are divided into lots of smaller projects that build on each other. This enables people to employ short feedback loops, learn quickly and change plans in light of new information. Two of the biggest causes for failure in business and failure in new development projects is that companies have no inexpensive way to investigate new opportunities, and they blindly follow predefined project plans without change – even as the world itself keeps changing.

The IT profession is at a turning point: one group of IT practitioners has learned that agility is the way to go, but more traditional practitioners still call it radical. Yet, the traditionalists continue to apply the same old ways of doing things that result in the same old horrendously expensive, multi-year projects that produce systems barely better than what was there before, if they even work at all. More and more business executives are coming to the conclusion that the effective support of business agility is the main reason for their company to have an internal IT group. Otherwise, there are options now to just outsource IT operations to cloud computing vendors and get new applications from SaaS providers and social media.

Rally: What does the future hold for Agile and Lean development practices?

MH: Probably the biggest change will be analogous to what happens when a company grows and transitions from an entrepreneurial startup to an established business. When this transition happens, there is a need to become more pragmatic and less idealistic. In the Agile world, this means that “Scrum-but” will actually be the best way for most companies to adopt Agile methods. Each company will customize versions of Agile that best fit their needs and it will be some combination of practices from Scrum, XP, Lean, Kanban, etc. Even waterfall practices have some benefits which should be incorporated where they make sense. Agile practices will not be set in concrete; they will continue to evolve over time as companies learn more and the world keeps changing.

Another big change for Agile is the realization that Agile development is not an end in itself. The value of IT agility is its ability to drive business agility. In the end, agility is more about business than about IT. Instead of co-locating business people with development teams, we will embed IT people in business operating units and co-locate development teams with business people.

I talk about this in my most recent book Business Agility: Sustainable Prosperity in a Relentlessly Competitive World. Agile companies will become real-time organizations that use IT to drive a process of continuous focusing on and responding to opportunities and threats. They will employ IT to drive three continuous feedback loops that make their real-time operations possible. The first feedback loop (I use the Yin-Yang symbol), provides awareness of a changing environment and identifies threats and opportunities. The second loop (I use a sunflower because of how it constantly adjusts itself to follow the sun across the sky), provides balance and continuously adjusts existing operations and processes to fit changing circumstances. And the third loop (I use the leaping panther), provides agility in the sense that it is how companies create new processes and products to seize new opportunities. The figure below illustrates this.

In Defense of the Half-Assed, part 1 - Aug 17

Source: Agile Development Blog: Scaling Software Agility - Ed Willis

This post will be split into two parts so that it, itself, will be half-assed with the suggestion of an additional half-ass to be delivered later :) And, in keeping with that spirit, the post mistakenly went live before it was ready for prime time. This time, I meant to push the ‘publish’ button…

Can you deploy Scrum to a test team?

Scrum is at its heart a product development process.  How can you leave the part of the organization – development – that actually makes product out of any Scrum deployment? Does it even make sense for other parts of the organization to be “doing Scrum” if development is somehow doing something else? Wouldn’t you be working towards what would be, at best, a half-assed deployment of Scrum?

Craig Larman and Bas Vodde in their wonderful book Practices for Scaling Lean & Agile Development certainly agree: “…a so-called test team Scrum is a contradiction in terms.” Ken Schwaber in The Enterprise and Scrum doesn’t seem to admit the possibility of deploying to functional groups – it’s projects he’s envisioning deploying to. For example, consider this advice for early goers of an enterprise-wide adoption of Scrum: “Establish preconditions that must be met before a project can use Scrum.”

The last 10 or so years of my career have been spent in big companies with very traditional structures: functional organizations with clear separation between development, test, usability, product management, etc; running projects that are very much plan-driven. Lots of agile practices that seem relatively straight-forward in other contexts aren’t in companies like this. Consider Schwaber’s notion of organizational deployment of Scrum again – this from the introduction of The Enterprise and Scrum: “This book is for those who want to use Scrum throughout their enterprise for product development.” It’s an awfully lucky convergence of thought and opportunity that would make such a deployment possible in large, traditionally organized companies. These sets of wholly distinct sub-organizations need to be both willing and able at essentially the same time. You might get a chance like that, but I wouldn’t hold your breath waiting for it.

You can start to see why that opportunity would be rare when you look at it from their perspective.  In taking a project-by-project focus in deploying Scrum to organizations like these – and assuming you’re holding firm to deploying every part of Scrum straight away – you’re essentially asking them to:

• Reconfigure their teams
• Change how they define and manage product scope
• Empower a single person to make scope decisions on each project
• Change how they plan their work
• Change how they approach their work in areas like development and testing
• And so on …

The point is that, even if limited to the context of a small set of pilot projects, they have to do all of this stuff first before they can realize the benefits of Scrum.

To me, this is exactly the same argument that we, as agilists, are very much accustomed to facing from development teams:  “We can do that feature but first we need to re-engineer the infrastructure to support it, which will take six months.”  We encourage teams making that argument to find ways to do just a bit of the refactoring to allow just a bit of the value to become realizable, rather than predicating all of the value on all of the refactoring.  Why can’t we make a similar argument in support of deploying Scrum to just a part of the organization?

What would Voltaire say?

One of my favorite lines – frequently quoted in optimization discussions but applicable equally well here – comes from Voltaire:  “Le mieux est l’ennemi du bien” (the best is the enemy of the good). “Best” is hard to define in any complex system like a large company but “good” seems a little more tractable. We should not let an inability to approach some notion of perfection prevent us from getting better.

A colleague was presented with this exact scenario a while back.  Representatives from a test group came to him asking if he would work with them to try Scrum.  He and I spent some time talking it over.

Things like product owner, product backlog and potentially shippable product increment looked like a tough fit for a test team, to be sure. But still, we thought of goals like “verify feature X” where the challenge to the team is to find a way to work together to get that done within the time-box of the Sprint. That might be a liberating shift in thinking after heavy doses of planning of the form: “We have a bazillion manual tests to execute. At 5 per hour, that’s bazillion/5 staff hours. With 20 FTE, that’s a bazillion/(20*5*40) weeks of testing.” Looking ahead to subsequent Sprints, we envisioned helping the test team bring some of their development partners into their Scrums – perhaps through broadening the notion of the verification goals to include “hardening” – finding and fixing bugs as a cross-functional team. And from there to the odd small feature, slowly working our way towards aligning the work of the test and development organizations in cross-functional Scrums. Even with such an odd scope of initial deployment, we could see potential benefits, including improved productivity through the iterate and reflect cycle, better planning and estimation and higher morale.  Not surprising, these are the same benefits we would suggest lay before any team looking to try Scrum.

Isn’t this the good that Voltaire would caution us against passing on?

Larman and Vodde have some great advice about how to go about ever more closely approaching the “potentially shippable product increment” goal of the Sprint through expanding the Definition of Done (DoD below):

“In general, these are the ways of expanding the DoD:

• Automate – for example, performance testing is automated
• Expand team cross-functionality – for example, a person with technical-writing skills joins the team”

That latter idea suggests a path to improvement that starts in development and then spreads over time to the remaining functions.  If we view Scrum deployment as being something we do in the context of projects and products, this is both natural and reasonable.  But, if we view deploying Scrum as something we do in the context of teams of people or if we view it simply as “transforming the world of work,” then why would we believe we have to start with any particular set of people?  Why not start with testing and grow our way towards development?

Would that be a half-assed approach to deploying Scrum?  Perhaps, but like Richard Dawkins’ half a wing or half an eye, maybe half an ass may prove a more useful incremental improvement than may be apparent at first glance.

So, can you deploy Scrum to a test team?

Sure, why not?

What do you think?

About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.

Our Agile Organization Materials at Agile2010 - Aug 13

Source: Agile Development Blog: Scaling Software Agility - Ryan Martens

This week both Jean and I delivered talks on the Agile organization at Agile 2010 in Orlando. Whether you were able to attend one, both or neither, this post shares the handouts and materials that we used in the talks.

If you attended, please provide comments on what you liked, were puzzled by and might change in the future.

Jean’s work was a three-hour tutorial on learning models for managing the Agile organization.   She ran three exercises and provided a bibliography of books/resources that we have used here at Rally:

Jean in action at Agile 2010

• True North Example

• True North Exercise

• Strategy A3 Template

• ORID Exercise

• Personal and Corporate Visioning Exercise

• Sample Quarterly Agenda

• Bibliography

In addition to Jean’s talk, I presented an experience report on our use of Plan-Do-Check-Act (PDCA) at Rally.  This report tells a story of our evolution of strategy execution from Gazelles/Scrum to Lean/Agile.

We hope these resources provide you with ideas for scaling your own Agile efforts beyond their current levels.  Again, please comment on the blog with what you got from the materials or the talks.  We want to hear from you on this topic.

Ryan Martens is a tomato grower, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.