We wage a lot of agile transformations for our clients at Cardinal. We also deliver lots of Scrum.org training. A common reservation I hear from our new teams and students about moving to agile is, “But we’re not ready. We need to [fill in the blank]: gather requirements, do design, evaluate and purchase an agile management tool, file a change ticket, get approval, evaluate technology platforms, procure servers, etc.”
No, you don’t. Just do it.
In the 2004 movie National Treasure, the lead character Ben Gates states, “If there's something wrong, those who have the ability to take action have the responsibility to take action.” That quote (while fictional) always stuck with me. It’s how I think about our agile transformations. Technology teams have struggled, mostly with failure, for 35 years with waterfall. There’s something wrong with that and it’s your responsibility to take action. Let’s discuss some positive actions you could take to jumpstart your agile initiatives:
Communicating effectively is hard. It’s particularly difficult when you don’t know what you don’t know. There are a million electronic, distributed communication mechanisms but none compare to Face-To-Face (F2F). Co-locating your team solves this problem. I can’t tell you the number of train wrecks we’ve averted because someone overheard something and corrected a falsehood or identified a conflict or communicated a dependency. This co-location doesn’t need to be anything fancy. Make sure you’re not bothering other people nearby but card tables and power strips will suffice in the short term.
Create a simple, easily-modified, centrally located communication mechanism for your team. I recommend a simple whiteboard and a bunch of 3x5 cards. Those giant 3M Post-It poster-sized sticky notes work great too. In its simplest form, this board needs to depict what work is waiting, what the team has in progress and what’s done. Don’t worry about tools. Not even free tools. At this point in your team evolution, they will present so many options and features, you’ll spend all your time learning the tool and wondering why your team isn’t using something called Epic Feature Burndown Chart Analysis (yes, I made that up).
Most teams avoid starting because they lack a [fill in the blank]: DBA, analyst, tester, enterprise architect, etc. At a minimum, you need the role of product owner/manager to present a list of ordered desires and a few folks to fulfill those desires and add value. In the Professional Scrum Foundation (PSF) classes we deliver, our teams typically number 3-4 and produce fully functional, tested solutions in a few hours! We try to distribute traditional roles across these teams but occasionally there’s a team lacking a developer. These teams often end up producing some of the best solutions. I think a lot of times this is because they don’t suffer from a desire to gold-plate and readily adopt no-code or existing platforms. Chances are you have the people you need. Get creative and figure out the rest.
“We can’t build out that feature yet. The database isn’t built yet.” Err on building features and value end-to-end instead of in a layered, sequential fashion. How much does the final database resemble the first design? Typically it’s night and day different. Don’t try to predict the future 9 months from now. Besides, how much value does a 5th normal-form database represent if your customer can’t access it? None.
I also witness teams evaluating countless solutions and technologies before finally choosing one; only to be disheartened when a shortfall is encountered. Your enterprise readily accepts Java, .Net, SQL Server, DB2 and maintains a SharePoint instance. Why are you evaluating Ruby, NoSQL and PHP again? Sure, they’re great tools but only one person on your team has ever used them and you’ll encounter nothing but closed doors when you try to push these into the enterprise. It doesn’t provide any value. Get something working that provides value and your product owner could potentially ship to customers. Fight the urge to reinvent the wheel and embrace the resources available to your team.
“This approach won’t fit into our [fill in the blank]: budgeting, SDLC process, capitalization, performance review, etc. process.” Ok, that’s fine but figure out how it can. Control what you can control. If your enterprise requires a design document or budget scoping document, provide it. But don’t use this as an excuse for avoiding starting an agile approach. Pick your battles and avoid the fight altogether so you can go wow your product owner instead. Over time, as you continuously produce exactly what your product owner wants and your [insert metric here]: customer satisfaction, conversion rates, revenue, usage, etc. constantly climbs, your team will get a lot less hassle about that missing level three estimate. (Disclaimer: I’m not advocating no-design or no-estimating…just don’t put it all up front!)
Ever notice people almost always include a quantitative measure of the amount of weight they recently lost? “I lost 12 pounds on the carrot peal diet!” I think this because it’s a lot more impactful to cite a specific amount rather than a somewhat nebulous, “I lost weight.” When commencing an agile effort, take a bit of time to understand from your product owner what is most important to them: transactions per second, conversion rate, customer growth rate, etc. These numbers should be tied to your goals and efforts. It will also help clarify decisions about how and why to take a particular action. Add value as quickly and regularly as possible and use metrics and measurement to prove that value.
Even if your environment supports agile, it can be difficult to get started. If you have a long journey, it always starts with that first step. Don’t wait for perfect. Start with good enough and you’ll likely discover greatness along the way.