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.
Johanna’s General Agile Picture
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.
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:
- 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?
- 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.
- Agile requires an open culture. Are you willing to give and receive feedback at all levels?
- 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?
- 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?
- 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.
For me agile means: Change what needs to be changed in order to get the job done. So obviously with that definition how there can be other ‘vehicles’.
What are other vehicles according to your understanding of agile?
Excellent post Johanna. I’m thinking of something more insightful but nothing is coming to mind. I think you nailed it.
Pingback: In the News: 2012-12-03 | Klaus' Korner
Johanna,
I like the post. I wonder whether the uses of the words “requires” and “must” take it too far in the direction of advocating for the ideal rather than the practical. For instance, “Agile requires transparency.” Have you seen any organizations using agile that were successful but weren’t fully transparent? An organization doesn’t have to be ideal in order to be successful.
I know you love the practical.
Hugs,
Steve
Steve, I am happy for organizations to be on their way to agile. To me, that makes perfect sense. Cultural change takes time.
What gets me is when people in technical teams have to prove their agility or somehow assess their agility to prove to managers that their agile transition is working. I don’t know what to call this. Is the team successful? Yes. Is the organization successful? I don’t think so, because the transparency is not going both ways. At least, not yet.
Now, maybe the managers are willing to show some of their work in progress, at least in terms of the project portfolio. I understand that there is plenty of sensitive information that managers handle that may not be appropriate for everyone to see. But letting people know that they are managing it could go a long way towards extending the necessary trust and transparency agile requires.
Hugs back to you, my friend.
Jason, when you think of more, please do reply.
Jens, wow, that’s a wide open definition. I like it! I bet you are a do-it-now-ask-forgiveness-later person, too!
For me, there’s the “what does this project need to do to be successful” question for the immediate project. That might mean you select a lifecycle or practices that better fit your culture for now. And, maybe you use your influence skills to help people realize that agile is an option, but maybe flow is an option. Sometimes, seeing the work in progress is better than working in timeboxes. I wrote an article for projectmanagement.com on this, http://www.jrothman.com/2011/01/timebox-or-kanban-a-false-dichotomy/ . That’s three options. I bet there are more.
Pingback: Agile is Not for Everyone - PM Hut
Pingback: Five Blogs – 4 December 2012 « 5blogs
I am book-marking this one, I believe I will be referring to it in many different situations.
I have to raise a couple of objections to points you’ve made in your post
You are saying to be agile then you need to be working in iterations which is not correct, you can either be iterative or flow based, both are pull systems but the flow based just doesn’t have the imposed timebox in fact you’ve linked to another post of yours that expands on this in the comments.
Also you don’t have to change the entire organization if you read David Andersons book Kanban: Successful Evolutionary Change for Your Technology Business you’ll find examples of where the organization has and hasn’t had to change.
From my experience very, very few projects would actually benefit from not being run in an agile manner and focusing on delivering value and they didn’t all require the organization to change.
Thanks, David.
Nathan, I agree that you can start, especially with flow, and not change the entire organization at the beginning. You have to start somewhere. But let’s allow ourselves to imagine where we are after say, two years. Are we still working in flow? Have we moved to cross-functional teams whose requirements have gradually become smaller? I hope so.
I have seen organizations attempt flow where they “tried kanban and it didn’t work” because they refused to stop multitasking the one poor tester, even though the board showed the work piling up for test. The developers and management refused to believe what the board said.
I don’t believe agile is just iteration-based. I had hoped that my picture was sufficiently general that you could see that lean would work too. Oh well. I was not clear enough.
I agree that lean requires less cultural change up front than timeboxes appears to. But, if you want to reap the results of agile and lean, then expanding agile/lean past the project team does require cultural change. If you don’t change how you estimate projects, and when you ask people to estimate project cost or dates, and you stick with once-a-year project portfolio and budgeting, you have created a culture in which agile has a difficult time thriving. The forces against agile are greater than the forces for agile.
I don’t mind if we disagree. I would even be happy for organizations to prove me wrong. All I know is what I see in some of my clients. When I go in to clients who are on their fourth, fifth, sixth or more attempt to “install” agile, I have to wonder if agile is even right for them.
Thanks for commenting.
The journey is important in getting you to the destination, but it is more important to understand where the destination is.
Another great post, Johanna.
Thanks, Chet.
Pingback: Agile is Not for Everyone | Development Block
I prefer to frame “agility” as a quality. It is a relative assessment. It is not a binary assessment – not a 1 or or 0.
Use of the word “more” in the phrase “while there is value in the items on the right, we value the items on the left more” from the Agile Manifesto supports a relative assessment approach. The phrase “Agile requires” is not in the Agile Manifesto.
Agility is associated with the power of moving quickly and easily. It is associated with the ability to think and draw conclusions quickly. Often, improved agility correlates with improved reaction time. Synonyms include nimbleness and quickness. The German word “behedig” is translated as clever, dexterous, and skillful. Behedigkeit is translated as agility.
Often, agility is a quality that enables someone to accomplish the desirable. Typically, through training and deliberative practice, one’s agility can be improved.
Instead of phrases such as “Once a team installs agile…” I prefer discussions that reinforce the concept of agility as a quality and a relative assessment. When agile is associated with qualities such as clever, dexterous, and skillful, it is a quality that is desirable for nearly everyone.
Johanna,
Great article. I agree, it is a culture shift.
I would add to this list is that in Agile, team decides what to be done in next sprint compared to Waterfall or other methodologies where PM or Functional Manager (management) decides what to be done next by whom. This is a control issue. Many organizations are not geared to give up their control. Agile would be a big failure in such organizations.
Vivek, those organizations can learn to give up control. They need to learn to do so.
Mark, I’ve been thinking about how to respond to you. There is the nimbleness part of agility, yes. If a team uses an agile approach, they can respond quickly to change.
However, over time, what I see in teams, is there is a cultural shift in the team. Once the team has changed their mindset about responding quickly to change, they often become impatient with the rest of the organization’s inability to be agile. The (unagile) managers want to tell people what to do and not manage the project portfolio. That destroys the team’s ability to respond quickly to changes. The (unagile) HR department wants to insist on personal reward and recognition programs instead of considering team reward and recognition programs. This, despite the fact that we have evidence that individual rewards destroys the social contract. Finance insists we fund projects and programs once a year, sending people on the crazy budgeting trip. Then, the budget is out of date by mid-January.
The team sees the lack of congruence between its values and the organization’s values.
And, what’s worse, I have consulted to several organizations on their second, third, fourth or more attempt to transition to agile. Their corporate culture does not support the agile principles. It has nothing to do with the manifesto. It has nothing to do with being clever, dexterous, or skillful. These organizations are all of those things. It has everything to do with who has control of what. And that is a cultural issue.
You and I don’t have to agree. I’m glad you thought enough of my post to write your thoughts down. Thank you for that. You gave me a chance to further synthesize what I was thinking. You helped me a lot.
Hi Johanna,
Interesting article. Agile is common sense because based on empirical facts about people around building software I would say.
As Voltaire said “Common sense is not so common” hence why agile is not for everybody?
Regards,
Chris
Chris, you made me chuckle. Thanks!
How you conduct your business frames the culture of the company. Part of the culture is how we behave towards our customer and how we financially run the company.
The customer relationship is important to the success of development. If the customer has no interest in collaborating with the business then feedback is lost and it leaves the company guessing. Guessing leads product management forcing in too many features. Most companies don’t measure their ROI on a feature and thus have little or no knowledge of what is actually delighting their customer.
Your post describes very well the financial management impact on control structures that influence development organizations. Given large release planning cycles, financial systems react with big annual capex exercises to build out entire systems. To remain financially responsible they enforce controls on spending rates and project progress. If the project looks like its going off the rails then they pull back and in some cases cease funding.
The responsibility chain in most companies is fiscal and not value driven. Value being corporate values as well as customer value. Changing this is monumental.
I whole heartedly agree with the approach given in this blog. It provides and understanding of the business context and provides a step for us to take within corporate structures that are beyond our reach.
Interesting article. Thanks!
I truly believe that agile is a journey and that people are often on their way along it rather than saying agile is not for someone, they are simply not yet at a certain point on that journey. I concur that some organizations aren’t yet ready to fully adopt all of the principles of agile, but moving in the right direction is becoming more necessary as a business survival tool – or at least moving to more responsive, quicker reactions, etc.
I think that implying if you can’t hit certain milestones (2 week iterations with releasable software) may put some organizations that can do agile off because they can’t do it “right” right now…
Working with the federal government, it is a slow cultural change to agile and is primarily in the IT area, but it is expanding as the programs come up against blocks that are cleared through communication and transparency. And it hits setbacks in some situations as well, but it continues to grow.
Thanks again for your insight!
Josh
Josh, I have no problem with people being on a journey. I do think that at some point, you have to say, “Are we ever going to really be what other people call agile? If not, why not admit it? Why not say that what we are doing is a staged delivery lifecycle, or a very good implementation of design to schedule, or RUP?
You see, I think it’s critical that people understand that they look at the agile principles and values. See
If they don’t live up to the agile principles and values, it doesn’t make them bad people. It makes them people who, at least for now, as you said, can’t do that. If they can’t achieve working software often, they are not bad. They may be people on a journey, but they are not agile. So, don’t call themselves agile.
The longer people stay on the journey, and the longer they think they are agile, while still on the journey, the longer we do them a disservice.
The bigger the program, the more difficult it is. I have several posts coming up to help.
Pingback: Agile Program Management: How Will You Deliver? - PM Hut
Thanks for the article.
I would say that cultural change within your organisation is part of the reason to journey towards agile. Many organisations are still being run within a structure that hasn’t changed since the 1950′s.
A modern workforce demands autonomy and purpose in their work and organisations that are able to engage with, and adapt to, this need will be those that prosper over the next 10 years.
In providing agile development teams to large enterprise our experience as been that the we have been able to be a spark-off and be a catalyst for this cultural change.
Such change is a difficult road but is necessary. Agile can be a good vehicle for that.
Pingback: TNSFF
Pingback: Perspectives on Testing » The Seapine View
OK, I am a novice on Agile. When I read “Agile requires that you start managing the project portfolio” it did not make sense in my understanding because I assumed that managing the project portfolio of a business was a default business’ task. Since I was not happy with my doubt, I looked for your book (I downloaded it for free Thanks!). There in your book read the first two chapters and finally I clarified your point. Thanks and I am planning to use this your blog as part of my project class.
Wilbert, you downloaded my book for free? Not just a sample? Hmm, my book is not free. At some point, please buy the book! Thanks. And, if you would, please let me know privately which site has it available for free. That is a pirate site. I will send them a takedown notice. Thank you.
Everyone, I work hard with my publishers, and when I self-publish, to make my books available for a reasonable price. This blog is free, and as you can see, I write a lot on it, and I write many articles, all of which are free. When I do publish books, I expect to be paid, just as you expect to be paid for your jobs. Please support me by purchasing my books, and not downloading them for free. Thank you. I will write a separate blog entry about this.