I’ve been doing non-waterfall development for the past 10 years of my career in one form or another, and though Agile/SCRUM/XP practices are almost assumed at this point, I still see many organizations that need help with making it work. The agile transformation usually starts with a well-intentioned individual in a middle management or lead developer position who tries to set it forth upon an organization with promises of faster time-to-market, less documentation, and golden parachutes for every collaborator within a small project as a pilot. In reality however, really making agile methods work requires adjustment and a willingness for self improvement of every role within an organization. There are many companies out there that offer agile coaching, but I see too many of them working primarily with a single project (or even limited to specific roles on that project) and not really get buy-in from everyone who needs to take part in the change.
I’d like to use this post to begin a series on healthy practices to establish an environment for taking advantage of agile methods within your company. I’ll do a post on each role within most companies, and discuss some important considerations for that role and how their actions should (and should not!) effect others in the process. This is based on my real-world experience and the practices I’ve found to work through applying many of the books out there on the subject. In this, my advice is far from the “de facto standard” of which I don’t think exists at this point. To start however, I’d like to state some underlying realities I’ve encountered that any organization must be willing to face before even considering going down this route.
A common problem I see is touched on by the following post from Nick Malik for Inside Architecture on MSDN’s blogs. In Waterscrum vs. Scrummerfall, Nick (and the links within that I encourage you to read) addresses the fact that successful adoption of agile is very difficult to do without leadership from someone who’s done it before. I’ve bootstrapped agile into at least 3 companies over the years and every one of these was a learning experience for me. The hurdles along the way were enormous and had I known what I do now, it would have been easier for me to hire an expert. Unfortunately these can get pricey, and it’s difficult to evaluate how well of a job they will do when you don’t even know what you’re looking for! If you are thinking about doing agile, be honest with yourself about your level of experience. Remember, you are the guy they will all point fingers at if things go south…
Another problem with these “half-agile” adoptions is the cherry-picking of practices. Agile is supposed to be about empowering a talented development team to be autonomous, and flexible enough to respond to change that wasn’t anticipated. However this doesn’t mean the marketing, business analysis, or product management folks are off the hook for solid requirements. If the functional stakeholder in a project isn’t available to the team as much as needed and all the requirements aren’t known up front, this is a recipe for disaster (I’ve seen it happen). Similarly, if the requirements of a product are emerging as being developed but the development team doesn’t have appropriate tools to react to radical change in the codebase, things will fall apart. The tenets of agility have to be put into practice by everyone up or downstream of the deliverables of the project(s).
Lastly, taking on agile means agreement that there will be new skills that need to be learned by everyone in the organization. Though many of these are small, I sometimes see folks try to continue business as usual even after nodding their heads in agreement to the proposed changes in process. If you are going to truly transform the agility of a business, it takes willingness from every member to be diligent in spending time on these new activities and being professional about feedback, and honest with each other about what is and isn’t working. One of the most frustrating things is to see a key stakeholder throw up their hands to say “this process sucks, let’s abandon our agile efforts” who has been frustrated about a single aspect of the new process but didn’t speak up earlier. Agile methodologies are for people, and are supposed to encourage eliminating waste. If a step in your process isn’t adding value – don’t do it! If you’ve tried something and it’s not working, get in a room with stakeholders and formulate an alternative!
And this leads to my final note about overall agile hurdles – professional talent. In a company of mixed skill where some folks have personality conflicts with others and politics are prevalent, making agile methodologies work is very, very difficult. In these types of organizations it is much more sane to use a traditional waterall approach that keeps all the players honest about what is changing, who is responsible for what, and who is and is not delivering value. Micromanagement is a must-have for resources that are not self-starters, prone to defensiveness, and unwilling to work in teams. For companies that have really mature people however, even if these folks are not as technically adept as might be desired, the potential for success and smooth operation of projects is exponentially higher with agile methods. These teams will find it natural to get together and just “make it work” and will be energized by change instead of frightened by it. It’s these teams that are really ready to use agile methods. If you work on a project with resources of the first type however, your first priority should be creating a professional environment with solid resources before throwing a collaborative, group-driven process on them.
We’ve all worked with the super smart guy who can’t get along with anyone, and even the most personable folks have their bad days, projects, and situations – but in general project structures comprised primarily of people who see their work in a positive light and are enthusiastic about change are the ones that will see you clearly down the road towards agile transformation.