Experiences & Insights in Adopting Agile Development Methodology in Corporations

Recently Andrea Tringo posted in Sun Alumni mailing list asking questions in every executive’s mind who wants to adopt agile development methodology (like XP) but do not know how to proceed safely.

Andrea asked:

I know a lot of tech companies are enthusiastically adopting Agile, as many of us embrace(d) Six Sigma, among other practices. Other than regular stand-up meetings, I haven’t been in group that works this way. I am interested in your opinions as (developers, managers, or other professionals) about:

1. Any forms of Agile (Scrum, Crystal, etc.) you are or were practicing and how you feel it makes the working environment, positive and/or negative. For example, have you experienced a transition to Agile, say, after an acquisition or change in management? Do team members have different responses to the increased face-to-face interaction?

2. What resources for learning basic concepts of Agile would you suggest for an individual? I am not currently working in a group that’s pursuing this; I would like to find some online courses on my own, without involving an employer.

Let’s look at the experiences and insights from agile practitioners below:

Carl Pregozen, another Sun alumni, answered not only his questions but provided rare insight into adopting agile development practices; questions you always wanted to ask but never knew whom to ask about agile methodology and how to adopt it to your organization. I am fully quoting his response below (with permission):

Over the past seven years, I’ve taken a few organizations “agile.” In one case, the transition served as a morale booster — it got people’s minds off of an indeterminate future (dot com meltdown timeframe) and onto making the process work. In another case, it was a way to synthesize many different SDLCs across a company into one basic approach (taking pieces from each group, so as to make the resulting SDLC organically derived). I’ve worked with MIL-71 (a waterfall development methodology with documents on how to write documents), NASA development process standards, and agile approaches: XP, Scrum, FDD, and DSDM.

I’d have to say, I’m a true believer with respect to agile methods, but not a religious zealot about any particular one. In fact, with the youth of agile approaches as documented methodologies I have found they have holes. One of the tenets of “agile” is that you have to make the method fit your organization. There needs to be some agility in the application of the method itself. Thus, I believe every instantiation of any agile approach is distinct. I usually develop the methodology at an organization by starting from some named base methodology (say XP) and customizing it based on the culture and issues at hand. I usually don’t call it by name, so that the host of objections to xyz methodology aren’t introduced prejudicially.

Specifically to your questions:
How agile methods make the working environment feel… In some cases I have encountered some resistance. In all cases, results trump skepticism, but it can take a bit of finesse to get people to participate before they are committed. The most tenuous time is that phase when the team is just starting out. The whole team is being led to interact in a way that is new to all of them; people feel vulnerable or even stupid. I’ve always seen teams develop confidence after working through the initial few days.

Responses to increased face-to-face interaction… I’ve never seen a negative response to this. Some people do try and avoid it; they require a bit of coaxing by the team. (The team has to be groomed to take ownership of this situation, rather than having a single “process lord.”) Over all, people become a team when they integrate their activities, and agile methods promote this. For people I would classify as loaners, with agile methods, I’ve seen them develop preferences for working with some people more than others — perhaps people who better match their style. This is the kind of thing (I believe) a methodology has to be sensitive to and accommodate.

Resources… I always start people with Kent Beck’s XP Explained (bn) (amazon). If you can find a copy of the first edition, I actually like it better as an initiation than the second edition. Once you’ve read that, look at a different method than XP - perhaps DSDM (You can look at atern online for free at DSDM.org, but you have to register.) Then you’ll get a feel for how “stories” in XP are just features or high-level requirements in other methodologies. You’ll draw many similar parallels on your own. Once you’ve gone through those two sources, I’m sure you’ll have identified many other sources and interest areas on your own. (One thing about DSDM - it’s more popular in Europe than US.)

All that said, here are just a few common elements of agile methods that I would not ever leave out:

Short Iterations: The whole premise of agile methods comes from the notion that stakeholders need to see frequent, tangible results. They don’t often know exactly what they want — or, it can change once they touch a prototype and “feel” how it works. Incremental delivery builds credibility, causes prioritization and requirements management, helps ensure value to the customer (highest value features first), and is a source for financial savings (unneeded features don’t get developed). Additionally, delivery dates are not fluid. Scope may change, but schedule has to remain fixed. I try and steer teams to durations of one or two weeks (so a bit of a departure from Scrum, which likes 30-day “sprints.”)

Daily Integration (daily build): This is really risk management. A large set of activities and procedures have to be set up (and automated) in order to have daily builds. Enforcing the daily build ensures that a team never strays too far from having a working product. Muscling the build is less apt to cause a missed deadline. (Missed deadlines are not part of the vocabulary of agile methods.) This also requires the team to work together in a way that is not just about writing code. An automated test suite should be part of the integration/build process as well.

Group Ownership of Code: No one owns a particular module or class. Anyone can update or improve any part of the application.

Group Ownership of Process: Issues in process effectiveness are owned by and mitigated by the group. While the team is building applications, they are also building the process they use to build applications. It is important for the success of methodology that the participants take an active role in monitoring and maintaining the effectiveness of the methodology itself. One behavior that is not acceptable is for the team to point at the process as a reason for coming up short. (They’d have to point at themselves.)

Unit Testing: Has to be part of application development, whether test-first or code-first, the test has to be there so that dependence on tribal knowledge is minimized and maintenance of a growing application remains scalable.

Stakeholder Prioritization: Stakeholders (regard as your customers) determine what features get developed in what order.

Obsessive Project Management: This includes the daily stand-up meeting; there should be some point in the day when everyone can be in the same place at the same time to air any issue. Some people think agile methods are loose. In fact, with short iterations, the project management in agile methods has to be tighter than other approaches. (Think quarters versus semesters in college.)

Object Orientation: If the application is software, use OO and enforce encapsulation, polymorphism, inheritance. It raises quality (reduces defects) and makes the code more maintainable and easier to extend. (All worthwhile code gets maintained and extended.)

One other thing… I have found that it is way easier to implement agile methods on a new product or application. Bringing in an agile approach for the ongoing maintenance (or enhancement) of a legacy application is much more difficult (though still worthwhile, in my opinion). Why difficult? Because unit tests may not exist for the majority of existing code, the application build may not be automated, fiefdoms (code owners) have already been established, etc. Many culture and behavior patterns have to change, and many infrastructure “tasks” have to be accomplished that are not perceived by stakeholders as high-value ways to spend time. You have to do some “selling.”

Implementing agile methods is one of the most invigorating things I’ve ever done. The cultural issues are intriguing and fun to address. The results are inspiring.

I encourage you to explore… It’s a great place to go.

JF Unson, another Sun alumni, provided valuable insights and experiences for large corporations (13, 000+ employees) and more:

This is my primary job where I’m working currently - we’re trying to get the
entire company agile,. It’s a been tough 2.5 years - considering I’m one of
5 agile coaches in the entire company of 13000+ people! It’s hard to
find folks who have agile experience and can coach teams well! The company
started with 4 pilot project teams doing scrum - we’re now upwards of 150+
teams worldwide. We have about 600+ teams more to go! The good thing
is, the community is growing, and the DNA is starting to flourish within the
company. Not all good, mind you - like any framework, you can have abusive
implementations of agile.

Funny you should ask - but I started introducing Scrum practices to my team
back in 1998 at Sun - without them realizing it! And the good thing was
- it worked for our team - we were successful in delivering our product
consistently and with a lot of regularity until - alas - the project got
killed (mostly due to politics at that time).

The thing to remember about agile is that it espouses cross-functional,
highly collaborative teams that deliver user value over short periods of
time (iterations/sprints that are 1 to 4 weeks in length, consistently).
The team always works on the highest priorities first. Agile forces the
business to force rank the items they want. No more “all these are P1 -
must haves” - because effectively there is no priority when you present PRDs
this way.

During these iterations, the team constantly inspects and adapts their
process and the products they’re producing, always finding ways to improve
themselves and the product based on data/feedback. Thus, the process you
begin with as a team should look different 6 months down the line. The
underlying principles of prioritization, time-boxing (sprint cycles), etc.
are all there, but the implementation details may have been tweaked a bit.

The way to learn agile is to really do it w/ your team, if possible - or
find a team willing to do it. It only takes one doubtful person to pull
down the team when the team is trying to adopt agile practices.

There are lots of good books out there, as well as discussion lists on Yahoo
and Google groups. If you’re in the Bay Area still, there is BayXP that
meets once a month (find them on Yahoo groups).

There are also classes - you can check https://www.scrumalliance.org for
classes in your area. Ping me if you want to find out more about a
particular instructor - I’m fairly well connected w/in the trainer community
since we avail of their services.

And please be aware - when you first start doing things like Scrum, there
will be a lot of angst and chaos for a while. It’s a radical change - one
of the things about agile, especially Scrum, is that it makes things very
visible - and that includes current organizational shortcomings and
dysfunction. As a result, people are forced to deal w/ these issues -
otherwise they will keep on appearing during your iterations. Agile teams
fail when they don’t address these issues.

Håkan, a Sun alumni, narrates his own experiences and insight after working with Agile/XP/Scrum for over 3 years:

I have now been working with agile/xp/scrum for approx 3 years (I’ve been
using different xp disciplines a bit longer than that).

Recently I introduced scrum in a organization that is very waterfall
focused. I believe the introduction of an agile process into such an
organization needs to be done small parts at the time, one team at the time
and lead by someone who can mentor both the team and management into the
agile practice. At least - this seems to work. If the team experiences with
the agile practice is positive then the word will spread fast.

My experience is that team members like the control they get on their own
situation, they know what they will be working with for the next sprint.
They know what the other people in their team are working with. They gain
control on the expectations on themselves when they on the sprint planning
sessions get to say what can be included or not into the sprint. The team is
also usually very committed to actually meeting these expectations that they
set up on themselves (one must be careful here, and make sure to introduce a
focus factor (or velocity) into the team time estimations (developers are by
nature very optimistic).

Part of the success may well be introducing parts of XP at the same time as
well though - pair programming, continuous integration and test-driven
development are very strong concepts that developers very quickly learn to
appreciate.

If the team is cross-functional this is even better, currently we have
requirements engineers and testers, technical writers, and developers
working in the same team with very good result.

So, from my experience the newly formed agile team really like the stand-up
meetings, sprint planning sessions and the continuous improvement process in
the form of lessons learned sessions at the end of each sprint. Quality goes
up and team spirit rises. Team responsibility focused on each member in the
team and collective code ownership - it works!

The only minor problems that I have been having is with management, they
expect their traditional gant charts. It can be very confusing for
management to overview a project without a gant chart (even if they agree
with the fact that the gant chart seldom is correct in any aspect). What
seems to make the trick is to divide the product backlog into sprints as
early on as is possible (for me, in my current project that was after the
third sprint - event that may have been a bit early). This provides
management with a overview of what will be done after which point in time.

Also, what is appealing to management is the fact that each backlog
item/user story delivered after each sprint is to be delivered with
production quality - this promise can sometimes be a bit hard to keep, but
it is worth every penny to do it.

Also, if management is involved in stakeholder prioritization they gain
control and understanding on what is actually happening at the same time as
they learn to respect the sprint (and not throw in extra work at the middle
of the sprint). I’ve had very positive response from management in this
area.

How to learn agile ? I believe the best way is to learn by practice,
preferably by working in an agile team. If you are introducing scrum into
your own team then consider having an external scrum mentor help you
kick-start the process. Also, you should read the “Scrum and XP from the
trenches” book. It is the best scrum book I’ve read, filled with hands on
recommendations that works really well - and it is freely available for
download at https://www.infoq.com/minibooks/scrum-xp-from-the-trenches

I have also recently for the first time started using a specific ALM
(Application Lifecycle Process) tool for managing the scrum process in terms
of user stories, sprints and sprint planning, defects and acceptance tests.
The main reason for buying a specific tool for this is a requirement on
traceability that we have since the expected lifetime of the product is very
long. Other than that I have not really seen any reason for using a specific

What is your experience in adopting agile methodology?