Home » Agile » Agile is Not for Everyone

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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

and many more ....

 

One comment

  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

Your email address will not be published. Required fields are marked *

*


Want to take your Java Skills to the next level?
Grab our programming books for FREE!
  • Save time by leveraging our field-tested solutions to common problems.
  • The books cover a wide range of topics, from JPA and JUnit, to JMeter and Android.
  • Each book comes as a standalone guide (with source code provided), so that you use it as reference.
Last Step ...

Where should we send the free eBooks?

Good Work!
To download the books, please verify your email address by following the instructions found on the email we just sent you.