About Johanna Rothman

Johanna consults, speaks, and writes about managing product development. She helps managers and leaders do reasonable things that work. You can read more of her writings at jrothman.com.

Agile is Not for Everyone

Someone asked me again about self-assessments for their agile transition. That got me thinking about this problem of transitioning to agile. I don’t believe agile is for everyone in every circumstance.

Some people claim agile has “crossed the chasm.” Certainly, many people are aware of agile. Many people understand that a cross-functional team works in increments, delivering features asking for feedback. That’s at the team level.

You’ve seen my general picture of a general agile team looks like, and just in case you don’t remember, here it is again.

Johanna's General Agile Picture

Johanna’s General Agile Picture


 
So when I say ‘Agile is Not for Everyone’ what do I mean?

The problem is agile is not just for teams. Once a team installs agile, the team bumps up against systemic management issues. Management has to be willing to change. Program management has to be willing to change. HR has to be willing to change. Finance has to be willing to change. That’s huge. We’re talking about changing an organization’s culture.

You don’t have to change the culture on Day One. But you do have to change eventually. And starting with the team is a good start. If the team can’t get to continuous integration and small-enough stories to move to two-week iterations, maybe agile is not for them. And when I say two-week iterations, I mean releaseable at the end of two weeks.

Anyone can transition to agile. It takes work and determination. Here are the issues I see that prevent people from transitioning to agile:

  1. Agile requires that you start managing the project portfolio. Oh, maybe not at the very beginning, but certainly eventually. You cannot multitask on projects and be successful. Are you willing to say that yes, you will commit to some projects for now, and not commit to some projects for now? And, you will keep practicing so your teams are not overloaded? And, you will not move people like chess pieces?
  2. If you want to go to more teams, it’s not as simple as multiplying what you do on one team to several. That will give you bloat. I have several posts about program management already and you can expect more to come.
  3. Agile requires an open culture. Are you willing to give and receive feedback at all levels?
  4. Agile invites team recognition and rewards. Are you willing to at least discuss how to move to team evaluation, recognition, and rewards? Are you willing to discuss how to have career ladders that don’t automatically move people to traditional management? Are you willing to rethink what management is and how much you need? Are you willing to think about how to move what you might now call “management” into normal people’s work?
  5. Agile requires transparency. Are you willing to be transparent about who makes which decisions? Are you willing to be transparent about the boundaries of management decisions?
  6. Agile does not easily play with once-a-year budgeting. It invites incremental funding. But Finance doesn’t know about incremental funding. Finance still has a difficult time with capitalizing software as we create it. Finance prefers milestones. How do we help Finance with capitalization? For software-as-a-service, it’s an easier problem–you decide when you have released enough to capitalize. For non SaaS products, it’s a lot harder. Are you willing to try? Is Finance willing to try?

Can you see now that agile is not just a lifecycle, but a huge cultural shift for the organization? For a project team, it’s one lifecycle among many, but for the organization, it’s much more than that.

If you can’t maintain a transition to agile, you should not be ashamed or worried. You are not alone. What you can do is read Manage It! Your Guide to Modern, Pragmatic Project Management, and re-read the lifecycle chapter and appendix again. You have many choices for lifecycles. And, with what you know about timeboxes, slicing features into small stories, ranking stories, creating cross-functional teams, integrating testing into the iteration, you would have an awesome RUP or staged delivery lifecycle.

I’m not saying agile is for the elite. Far from it. I’m saying agile is for people who want to and can manage the cultural change that it requires. And, if you try to do many of the technical and project management practices we suggest in agile, you will be better off.

But is agile the objective? Or are projects that deliver products your customers want your objective?

Agile is one vehicle. It’s not the only vehicle. Choose the vehicle that fits your culture.

I’m all for being more effective. For me, that’s the thing that counts. If you need an agile assessment, you’re barking up the wrong tree. You need to see if you are more effective this year than you were last year.
 

Reference: Agile is Not for Everyone from our JCG partner Johanna Rothman at the Managing Product Development blog.

Related Whitepaper:

The Retrospective Handbook

A FREE guide for agile teams.

Are you running retrospectives regularly? Perhaps you run retrospectives once a week, or fortnightly. Do you feel like you could be getting more out of your retrospectives and fuelling continuous improvement in your teams? You may already find retrospectives valuable, but suspect there are ways of making them better.

Get it Now!  

One Response to "Agile is Not for Everyone"

  1. where did you read agile is about rewards in agile? or transparency? It is certainly about working with flexible scope/budget, tighter deadlines, more deliverables. but I think people are extrapolating what agile really is, despite all these features are desirable in an utopic humanist IT company

Leave a Reply


+ six = 9



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books