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.
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?
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, https://www.jrothman.com/2011/01/timebox-or-kanban-a-false-dichotomy/ . That’s three options. I bet there are more.
Excellent post Johanna. I’m thinking of something more insightful but nothing is coming to mind. I think you nailed it.
Jason, when you think of more, please do reply.
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.
Pingback: In the News: 2012-12-03 | Klaus' Korner
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.
Thanks, David.
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.
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.
“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.”
Although in recruitment concepts, I have the exact same problem…”because they refused to stop multitasking”. So my question is…should I “fight” (bottom-up) or if not Agile (Kanban), what?
Thanks,
Maria
Maria, you have an interesting problem. You can see the effects of the team’s/management’s actions.Their actions have a direct effect on you. And, you might not have the direct ability to change things.
My suggestions:
1. Start with data:
– Show people data about how their actions affect you.
– Show people data about how their actions affect the work they want to complete.
You might look at Cost of Delay as a way to show people that when they multitask, they can’t respond to your requests and the delay and its cost on you. Also, when they don’t have enough people, the CoD on them.
If people can’t see the data, you use a board for your work. (This is why I like kanban so much. It shows the flow and you can use it to show delays and blockages.) Show people the effect of their delay on your work. Show with a board, measure with data.
2. Look for allies across the organization. Who sees the data the same way you do? Who sees the effects? Can you enlist that person/those people to help you? I suspect you cannot do this alone. You will need help.
3. Ask yourself, and maybe your allies, “What’s the smallest change we can try?” Then create an experiment and see what you can try in a short time period. That time period might be just a day or two.
I have more tips in Feeling Alone on Your Agile Journey.
You might also want to define the forces keeping things the way they are. A force field diagram might help you. Often, people produce results the system asks them to produce. If everyone’s compensation is tied to looking busy (or even velocity), there’s no incentive to finish anything. There’s only incentive to make progress.
Good luck. Feel free to email me or continue commenting with more questions.
Hi Johanna,
I really appreciate your answer and found especially interesting the point 3, “What’s the smallest change we can try?” Maybe small steps are what the team needs in this case. A “safe-to-fail” environment.
As I really “Feel Alone on My Agile Journey”, I will see if I can apply your advice in the article.
Many many thanks!
Maria
Maria, you are quite welcome! Maybe you can drop me a line sometime/comment and tell me/us about your progress.
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.
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.
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.
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 Agile Manifesto
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.
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.
Is agile all or nothing? Can an organization pick and choose when to use agile or when to use waterfall? I am sure agile as well as waterfall do not work for all projects, but does the size, complexity, regulated requirements, new or looking to be replaced systems, etc.., impact the decision of whether to go agile or waterfall? Or is it not as simple as that.
I work for State government and if we decide to make the transition, do we need to change the cultural setting for everyone (all departments we service) involved as well as train everyone (IT programmers) on the agile philosophy and the various development tools? If so, this could be a huge undertaking that will take planning and budgeting. Not to mention the administration is likely to change every four years, depending on the elections, so there is no guarantee of consistent buy-in.
Hi Liane,
An organization can choose which lifecycle to use on a given project. In fact, in Manage It!, I suggest they do. (I have an entire discussion about when to select which lifecycle for which kind of project.)
If you want to transition to agile, yes, you do need to train everyone, eventually. You don’t need to train everyone at the beginning. That would be a waterfall approach to going agile. You want to pilot an agile approach.
You might read Agile is Not a Silver Bullet. You have many choices for lifecycles for your projects. Many of them will be more effective than waterfall and will not require you to transition to agile and involve the cultural implications of agile.
I like agile. I also like staged delivery, especially with timeboxes. I don’t mind RUP, but for me it has a lot of documents. I’m not so big on documents. Maybe you prefer them. It really depends on your project’s needs.
If I were you, I would try something that didn’t challenge the entire culture. You can use deliverable-based planning, rolling wave scheduling, cross-functional teams, timeboxes, feature-driven development and continuous integration on your projects now. That’s called staged delivery. It’s not agile. I’ve been managing projects that way since 1980. Maybe earlier.
You can shorten your waterfall projects. That would make them more effective. You can integrate your testers. You can do many things to make your projects more effective without transitioning to agile now, and those things would make an eventual transition to agile easier.
Hi Johanna,
Thank you very much for your insight and recommendations. After 25 years of using SDM Structured our direction has changed to keep current with development technology and just researching about these new and not so new (where have I been for the past 25 years) methodologies is an eye opener and an almost 360 degree change in our way of life. A hybrid or combination of these methodologies is somthing that we will definitely look into as we get a wide range of requests, from small, nice-to-have applications to large, Statewide applications with required functionality dictated by law, statute, legislature, auditors, union arbitration, etc. and need to interface with multiple other systems. An analysts’ dream project. Haha. Plus if this is to become the State’s new standard, we have a lot of people (technical and non-technical in 20+ departments) to eventually get buy-in from.
Thanks again for your help and I will definitely check out your book, Manage It, for more insight.
Liane, good luck!
One rule of thumb is “when your requirements and scope are fluid or not complete”, Agile can be used as you can get started with what you have and then keep expanding. Very important thing is that Agile teams are expected to have higher commitments as time to deliver is very short. Absolutely, organization culture plays a huge role in the success of Agile based projects as resources/teams are engaged all the time.
Hi Vivek, In my experience, very few projects have few complete and fixed requirements. Some do, such as high priority bug fixes. But, most projects do not. That does not mean everyone should jump on the agile bandwagon. It does mean that agile is a candidate for more projects than people might believe.
I also wrote about iterative and incremental approaches in Manage It! and how to decide which approach is right for you. There is No One Right Way To Do Projects. Especially not if your culture is not ready for agile.
It does mean you have to think. I have not yet discovered a case in projects where thinking is not good 🙂
Our project team is in the middle of our development, iteration 15 out of 34. Do you have any advice for communicating to the project team that by the finish line the product will be what they want. The team is made up of business sme’s (who by nature are detailed perfectionists) and they are strating to fell some angst and worry that it’s not perfect yet. All of the SME’s are first timers on an IT project. The project professionals ( PM, Testers, QA lead, OCM, etc) are all feeling really good about the project , number of defects and current quality but are having trouble communicating that to the rest of the team.
Hi Rob,
This might be a backlog organization/ranking problem. One thing you want to do is make sure that the product owner ranks the backlog so that the team completes features in rank order. You also want to make sure that some of the features are *fully* completed before going on to the next feature.
Sometimes, the product owner sees enough of the feature, and says, “Okay, that’s good enough for now. Let’s go on to something else.” But the rest of the project team has a difficult time swallowing the fact that things are undone or unfinished.
Here’s what I would do:
1. Make sure that the team articulates this at an iteration retrospective. Make sure the product owner is there.
2. If necessary, finish *one* thing to perfection. Just one. No more. Track that time and explain how long it took you.
3. Explain to everyone that 34 iterations is an estimate, and that if you finish enough of the features “just enough,” and you go back to them, you will now know enough to decide how much to complete the rest of the features. You might be able to finish early, or not finish the rest of some things at all.
Is there something you have discovered that you might not have discovered because you have done things just enough? Explain that to the people who are nervous. You are far enough along that you probably gained some benefit from iterating on the architecture. Or something like that. Explain the benefit to the people who are nervous. Explain how the current low level of defects are making it easier for you to sustain your pace. Explain how making progress across many features allows you to explore the architecture and not get it wrong. Things like that.
Does that make sense?
Great post. A thought. To be comprehensive, it would be important to also have the twin post: “Waterfall is not for everyone”. Otherwise we are giving a free pass to the other approach. I don’t see any reason why we would have a different lense to analyze the different methodology.
It would be great if you could post a similar one for Waterfall.
Always a pleasure to read you
Hi Michael, I sort-of already wrote the “Waterfall is not for everyone” post in Manage It! Your Guide to Modern, Pragmatic Project Management. I walk the reader through all of the different lifecycles and explain when and when to not use each one. When to plan and to replan. Okay, so it took me an entire chapter and an appendix 🙂
Maybe it would be good to reprise/summarize that chapter in the blog. I could do that. Would that be helpful?