Dr. Winston Royce first described a model for working with large software systems in 1970, which we’ve grown to know as “Waterfall”. Interestingly enough what many never read in his writings on SW development, is the following quote: “I believe in this concept, but the implementation described above is risky and invites failure.” (Source: Dr. Winston Royce. Proceedings, IEEE WESCON, August 1970) Why could he have said this? Could it be that many times requirements are emergent? Perhaps it’s that estimating large and complex bodies of work based on a requirements document can be incredibly inaccurate?
While I have a large bias towards Agile methodologies, as a consultant it’s my responsibility to evaluate what truly is the best solution for a client. I was recently on a project in a marketing organization, and while there certainly were some opportunities for Agile principles to be utilized, a framework like Scrum or Kanban just would not have been possible. I’ve heard some waterfall purists sum agile up to a bunch of people who want to get out of documentation and commitments to timelines. Ouch. But I also hear a lot of criticism from agile truthers about anyone who leverages waterfall as being clueless and archaic. Can’t we all just get along? Yeah, we can actually. But we have to start to recognize that Agile and Waterfall have value in different ways.
I’d love to have some discussion about what is seemingly a great divide between Agile and Waterfall methodologies. To help those in each “camp” understand why a specific method has value towards solving their business problems. What are some examples where you think a Waterfall process was truly the best solution for a project? What were some of the identifiers you had to come to that conclusion? Have you had success with using a “ScrumerFall” model where the Requirements, and design is all done up front, but Execution is done in sprints?
Fear not agile warrior, you are not alone and help is on the way. They are many situations where someone just knows that agile could help or even change the face of the entire company if utilized…yet someone or many people within an organization are opposed to the idea. So what should you do? First off what are some reasons someone would be against agile?
- The’ve been on a team where agile was used, and failed.
- They don’t know enough about agile or have misconceptions.
- They don’t believe agile is right for their organization/product.
- They’ve worked with an Agile Coach/Scrum Master/Consultant that was not very good at their role. Yes, not everyone does their job well…even in the wonderful agile community.
- They are from the past (I kid…I kid! That was an IT Crowd reference)
Now for the part you really came to this blog post for: What are ways I can help my organization adopt and/or support agile?
- Start emphasizing agile principles in whatever work you are doing. As a consultant that works on a wide array of projects with a variety of methodologies, I’m often tested with how to apply principles on a personal level. Getting out of the theoretical and nitty gritty practical application is a great exercise towards see if/how agile could work at your organization. If this is something you feel is “out of your league” or you just don’t have the time to do, it’s OK. There’s other ways to makes strides towards becoming more agile.
- Propose solutions to problems from an agile perspective but without using agile lingo. Some people are just turned off to agile terms and immediately roll their eyes when you say “backlog grooming” or “daily scrum”. But if you are able to problem solve using agile principles you could begin to win over even the harshest of critics.
- Create a mini scrum board for tracking your own work. I heard a story of a person who was trying to advocate for their company to adopt agile, and started doing a scrum wall in a shared space. Pretty soon scrum boards were up all over the company. Some were labeled “Inspiration wall” or “Wall of vision”. Everyone from IT to Sales was using them. Baby steps can be better than no steps, right?
- Contact consulting companies. See if they would be willing to share about agile within your organization. Some consulting companies will do this for free because it’s a great way for them to help your cause, as well as demonstrate their expertise in this area should you need their services down the road. Or see if they are willing to just share free resources with you.
- Join user groups and contribute to the agile community. There have been times where my primary daily function was far from an agile focus, but I was able to stay energized by attending local groups or writing blog posts in my personal time. Also, sometimes effective reflection comes when you are looking in from the outside.
- Find a new opportunity. (Please take this with a grain of salt as it’s just my opinion.) This for many reasons isn’t the first option anyone would like, but it may be the right solution. As the industry seems to be moving more and more towards adopting agile, it’s less likely that a company is just flat out rejecting agile. It could be that they proclaim to use agile but it’s very broken or dysfunctional. These kinds of situations can cause stress if you are a firm believer in the agile principles. But is the disappointment or stress consistently outweighing the rewards or satisfaction experienced? If yes, it may be time to look for new opportunities. Robbie Bach wrote a relevant article you may find useful called “Knowing When To Walk Away“
What about you? What advice would you have for someone in this scenario? I’d love to hear what other people have done or are doing.
Dear internet and devoted bloggers, I’m sorry. I occasionally write some blog posts on my personal blog, but for the most part I’ve been one of those who consumes but doesn’t contribute. Have you ever thought while searching for something “I really should be one of the people that posts helpful information on the internet and not just the one who searches for it.” ??? Well…I have too, for many years, and that’s part of why I am starting this blog.
I’m a project manager in the Seattle area working at a consulting firm. In recent years I’ve been working with agile team more and more, and know I’ll have some information others might find useful. I’ve developed such a strong interest in agile/scrum that I’m going to get of my keyboard butt and write!
I’ll be posting about practical everyday tips for agile teams, my experiences with different training resources, agile memes and will even have guest bloggers from time to time. Hopefully we can keep a lighthearted and humorous approach to solving real business problem.
Thanks for stopping by The AgileSphere!