Enterprise adoption of Agile? What should you have been told/taught?
This is the Age of Enterprise Adoption of Agile. More and more of my email includes sentences like: “Currently, most of our software development follows the
traditional waterfall approach, but we are quickly shifting over to
more accelerated agile approaches like Scrum.”
In many of these places, adoption results in people saying things like “at least my job doesn’t suck as much as it used to”. (That’s an exact or near-exact quote.) Like James Shore, I find that both sad and infuriating. So naturally I’m off to Fix It All, ASAP.
First step: research
It seems to me that what gets lost in enterprise-wide adoption is (1) a clear picture of what project life will be like when everything’s working as it should be, (2) anything like a gut feel for the values that help teams make the right decisions under pressure, and (3) an emphasis on nitty-gritty technical or semi-technical skills (as opposed to quasi-formalised social skills like standups). But I could be wrong.
So let me ask a question to those of you who’ve been involved in an enterprise-wide or otherwise top-down shift to Agile. What do you wish someone had told you at the beginning of the adoption? (Suppose you could go back in time to then: what would you tell yourself?)
Me being me, I hope your message is about actions you could have taken (”you should practice X”, “you should take care to go slow at first“, “drop by Sophie’s desk every day and tell her what’s up”), but you’re the expert on what you needed to hear.
Either reply as a comment to this post or via email to marick@exampler.com. I’ll keep all mail confidential.
If I get enough information, I’ll post a summary.
If this research has already been done, let me know. Not so interested in doing reresearch.
April 1st, 2009 at 10:58 am
I wish I that someone told me about the effect that traditional portfolio management would have on team adoption of quality skills such as automated unit and acceptance testing. Why, because everything is scheduled to the n-th degree based on old assumptions about the accuracy of estimates, and thus anything that can potentially affect one project’s schedule then affects many, which in turn sets of a shit-storm in which the sound of the thunder is, “We can’t do that - it will affect our delivery schedule!”
Root cause - precise, but highly inaccurate portfolio management. If work is only done when it’s done, teams don’t freak over anything that has a learning curve. Let them learn, watch their skills and velocity improve, and then watch the increased flow through the portfolio.
April 1st, 2009 at 12:16 pm
Our biggest mistake was taking Agile (XP), verbatim, without much consideration as to how the practices outlined there would impact the organization. We made a lot of mistakes, both technical and social, by turning rules of thumb into absolute declarations. I wish we had hired a coach or brought on at least one person who knew what they were doing. We missed something essential by just reading the literature and going it alone.
It wasn’t until much later that we really understood the spirit of the manifesto. I like to think we recovered, but much damage had been done.
April 1st, 2009 at 3:00 pm
Everything that I need to be told, I think I was. I just didn’t realize I knew it yet. The phrase “start with the values” really didn’t sink, nor “the goal is to deliver good software often” have the profound depth it should have. Not at first.
April 1st, 2009 at 5:42 pm
Having been on 3 xp projects early on and since involved in multiple non-agile-transitioning-agile environments, I’d like to make a prediction:
That thing you wish you had known at the beginning… IT WOULDN’T HAVE HELPED!
April 1st, 2009 at 7:27 pm
An agile coach at the Scrum Gathering told a group of us over dinner that he always spends his first day on a new client site talking about the values in the manifesto, but doesn’t label them, never mentions the word agile or any other Agile term, practice or even principle. Gets them talking about the values that inform their current practices, then moves them to speculating on what a new set of practices based on the Agile values might look like. After this, they are primed and hungry to open the new box of goodies (to mix several metaphors). Brilliant. I kinda sorta wish this values-driven introduction on everyone, myself included.
April 1st, 2009 at 7:36 pm
Ah, just remembered, the coach I mentioned above was Raffi Simonian, from AZ.
April 1st, 2009 at 7:59 pm
I would say that please don’t take agile practices as prescribed steps that needs to be followed but as starting point. Delivering working software is more important than following process.
April 2nd, 2009 at 7:34 am
[…] Enterprise adoption of Agile? What should you have been told/taught? (Brian Marick) […]
April 2nd, 2009 at 12:12 pm
Get senior management to buy in completely, and get all managers (including PM’s) to understand their new role.
April 3rd, 2009 at 2:58 am
This space (specifically large corporate IT enterprises wanting to gain some agility) is one I predominantly work in as a mentor and coach; I’ll limit this post to just 3 key items:
1) Large corporates often operate around matrix organisational structures with stove-piped competency groups. In this environment, resources may be “seconded” into a software development project from these competencies, however:
- the individuals primary reporting line (performance assessments etc) remains with the competency.
- there is often little ability to choose who you get: you get who happens to be “on the bench” at the time.
That poses a challenge in building a team who plays well together. To make a reasonable move toward agility (and in particular embracing the Agile manifesto values/ principles), the primary incentives for staff need to be the success of the project and the cross-functional development team (specialising generalists). In my experience, this often tends to be at odds with the competency fiefdoms. Generally, one project manager (even one project team) doesn’t have much ability to impact this: and in my experience its a major stumbling issue for many teams in large organisations. I’ve had limited success as an outside consultant in breaking the power and control of overbearing competency groups.
2) Its hard to become more agile unless you can iterate in short time boxes; in turn, this requires infrastructure and tooling that enables rapid build and deployment. As a mentor and coach, I’ve spent too much time working on the social aspects, the values, principles and philosophies surrounding agile practices, only to be stopped dead-in-the-water by no ability to quickly integrate code, build and deploy. In at least one case this took a significant period of time to resolve, and required additional funding that hadn’t been allowed for. Our 3 month “pilot” project lost 2 months to getting a build environment established.
3) Many of the tools and techniques successful agile teams use aren’t corporately approved things: getting new tools installed on “managed” corporate infrastructure often becomes an exercise in stealth and/ or bravery. Note also there still appears to be a large amount of skepticism in the corporate world around open-source tools. So, be prepared to research what tooling is approved for use, and make do with what you’ve got to work with, or run the gauntlet.
More frustratingly, “approval” or “exemption” is often required for teams to behave in new ways. I either try to find those curious individuals within large corporations who know how to “work the system” to get exemptions, or do what I think needs to be done, and ask for forgiveness later …
Based on my experience, I’ve come to the conclusion that mass-organisational change in large corporates isn’t an approach that is likely to succeed. I favor either a) creating an agile development “service” within an organisation or b) focusing on the success of a single project, and not worrying about long-term values change.
(Brian, PM me if you’d like me to expand on these).
April 6th, 2009 at 3:01 pm
I wish someone had told me that agile makes developers AND the customers happy. The customer can be a regular paying customer, a program manager or business analyst, etc. Sometimes the two sides get into an adversarial relationship. It’s basically a power struggle for time and features and whatever. This leads to poor productivity and lack of harmony in the team (due to all the time wasted and negativity and politics going on). Sometimes I hear that the management wants agile but the developers don’t or that the developers want agile but the BAs don’t. The point is that if we can get everyone on board with how agile solves THEIR particular problems, I think agile adoptions would be more often and go more smoothly.
April 13th, 2009 at 9:45 am
I have found that even where item 1 exists (”a clear picture of what project life will be like when everything’s working as it should be”), people tend to struggle with how to get from where they are now to that point of everything working as it should be.
In fact, I’ve seldom found explaining what an agile workplace might look like to be a challenge. The challenge is convincing people it’s realistic/attainable, and helping them keep motivated in taking active steps towards reaching that point (and, for that matter, figuring out which steps to take).
April 14th, 2009 at 3:09 pm
That your management sponsors will want some sort of data showing what you are doing is an improvement. They might be pretty flexible on what that data is, but they will want to see something regularly. “Just trust me” will not last more than a month or two.