By Brian Lucas
“Your mission should you decide to accept it…” voice of Robert Cleveland “Bob” Johnson.
Acted to the theme music of Lalo Schifrin, is Agile really mission impossible? You are in a tense situation. Profits are down or non-existent. Your competition is threatening you. Your employees are unhappy. Now you are expected to get software development done much quicker with smaller development teams and less budget and it has to be done in six weeks or less. Let’s run down the impossibility checklist, Mr. Briggs (or is it Mr. Phelps?):
- No direct connection through social media to your “real” end customers
- Executive management that doesn’t really understand the concept or fund it
- CIOs who feel Agile is just another fad or a threat to their cherished hierarchy
- Architects that don’t have a clue how to fit applications together in a framework
- Project managers who feel demoted as scrum masters and just won’t give up control
- Users who are unable to understand their own needs let alone articulate them
- Business system analysts that want to spend 6 months in analysis paralysis
- Developers that are moving like uncle Joe at the junction and still have software defects
- Operation management with draconian procedures and inquisitional committees
- Testing personnel who have no test policy, test plan, agile tools or training
- Help writers that are always the last to know about new features
- Salesmen that have no idea what the software really does
- Customer support persons who are totally disengaged
Note the lucky number 13! Note also that they all are about people. Does this describe your organization? Be honest! Even if only 1 of these applies, you can’t get the full benefits of agile. If 3 of these apply; your organization is in trouble. In cases like this agile just flushes out problems faster. If they all apply run screaming into the daylight! Often these were issues that existed in the enterprise for years, but were never exposed to the light of day. It is sad how office politics can make mute what is commonly known throughout a company.
If you say they don’t apply to you; my question to those of you in the C level is, “How do you know they don’t apply?” With an alarming frequency the CEO is often the last to know. Today CEOs are often more distant to the actual operations of their enterprise and are deluded by a layer of management that insulates them from what is really going on. Does this sound grim to you? Well it is one of the reasons CEOs are dropping like flies!
How you can be sure these don’t apply and if they do how can you fix them? The answer is that first you have to always guard against complacency and constantly ask yourself the question. Second, cherish and listen to your mavericks. Third, give everyone a path that they can report these situations to without fear of retribution. Fourth, above all else, if you are the CEO, you need to be prepared to have people tell you that you are wrong and not vent your anger on the messenger. One of the most important traits of a CEO is not to instill fear in his employees. To solve the issue(s), turn each of these problems on its head in a Sun Tsu fashion. Make yourself a mission possible check list that is positive:
- Direct connect, through social media, to your real end customers. Set up social media so your customers can communicate with you directly and easily. Have responsible employees answering the customers and engaging them in a meaningful dialog. Under no circumstances whatsoever use company or marketing policy diatribes.
- Make sure your executive management team understands agile concepts and practices them. If they are not agile it is difficult for the rest of the organization to be agile.
- If your CIO or other similar level manager is a control freak and feels threatened by agile have the CEO give them a heart to heart. If they still don’t come around, there is no place in the organization for them. I have seen so many agile efforts being derailed by control freak CIOs who eventually always got fired or retired early. So that it doesn’t make sense not to face this issue head on.
- Your application, systems and enterprise architects need retooling to function in an agile environment. As I have written about before in my post What Every CIO Should Know about Agile Architectures, agile does not mean “no architecture”; it means a flexible architecture. You need to retrain your architects to think in terms of fractional architectures that flex with the changing information system needs.
- If you have project managers who just won’t give up their total control of everything until you pry it from their cold dead fingers. Oblige them – with termination. While not as true now as was previous in agile’s history; old school project managers can do a lot to reduce agile’s effectiveness or make it down right fail. If after good training these people are still not on board – let them go.
- Agile does have weak spots. Shocked? Well the incredible pressure and emphasis it put on the user is the main one. I have worked with far too many users in my career who are unable to understand their own needs let alone articulate them to someone else. First training shouldn’t all be addressed to IS/IT personnel. The user, executive sponsor, scrum master and everyone else on the project have to be part of the training. Second if the user doesn’t have the knowledge in the area you are developing in and cannot reach into the user community at large to get it; call in a subject matter expert.
- Business system analysts that want to spend 6 months in analysis paralysis are antithetical to agile. They constantly make systems more complicated than they need to be and often miss the real need by a mile. As Mike Cohn says, beautify written requirements documents do not equate to timely and working software.
- Some developers are so sheltered in ivory towers of non-competitiveness. Shielded by self-protecting IT/IS managers, they can spend ludicrous times to perform even simple tasks and still have significant software defects. One way to break this cycle is for the user to go outside and get their own IT development support and compare development times and costs. This is happening with increased frequency now as you can read in Middle of the Road CIOs are Getting Hit by the Innovation Truck.
- Give the message loud and clear to your CIO and CTO that operation management’s goal is to get working software into production as soon as possible not create draconian procedures and inquisitional committees to cover their own posteriors. 100% up time is worthless if you don’t have much useful software running in it. I have seen environments where the implementation committees and network management processes took as long to get through as it took to develop the software.
- Testing personnel need to be involved from the beginning of the process. They need training, tools and most of all the support and cooperation from the rest of the team. Test Driven Development is a great way to bring your test people and developers closer together. I favor having the developers code automated test scripts from test cases that the testers write and the user approves. This reduces software defects immensely. It also frees up the testers time to work with the software mechanically. This will uncover the unforeseen nuances of use and bugs that will only reveal themselves to people using a manual approach.
- If you are going to use Help writers treat them just like your test people. Involve them early. If you involve your Help writers in wire framing you will get a better product. Help writers are always thinking about and looking for how they are going to explain something to a user so they naturally look for the easiest way to explain something which drives them to think along the path of what is the easiest way to do something.
- Salesmen have to understand the product. I strongly believe that all salesman need to take additional training each time a new software release goes into production. They should be the alpha customers for the training people. While some salesman might complain about the time this takes. You will get much better salesman out of the process and consequently more sales. I would go so far as to recommend developing your own certification tests; if they can’t pass the test they can’t sell the product.
- Customer support persons need to be engaged. One way is to mine them for the knowledge that they have by talking to them about product improvement directly and not just trolling through help support tickets. Another way is to train them right after the salesmen. I always found that help desk people make better beta testers than alpha testers. Too often customer support is only given the minimalist training or no training at all.
On the flip side here if you do all 13 well it’s difficult to imagine how you can fail. If you are starting from scratch or a severely TARFUed situation, then begin at the top of the list and work your way down. If you don’t realize that you’re in trouble because you are an executive manager that doesn’t like bad news or are insulated by middle managers agile will quickly take you from SNAFU to TARFU to FUBAR and result in a deplorable BOHICA situation. I am going to cover in a future post just how agile is exactly like Mission Impossible, but from a totally different approach that I think will surprise you. Remember till next time – keep agile!
 That is assuming you can find some!
 Sun Tzu (Sun Wu) was an ancient Chinese military general, strategist and philosopher who is traditionally believed to be the author of The Art of War, an influential ancient Chinese book on military strategy. Sun Tzu has had a significant impact on Chinese and Asian history and culture, both as an author of The Art of War and through legend.
 Fractional architectures is a term I have coined to refer to architectures that support high levels of encapsulation, mediation patterns, and atomicity with an overriding function oriented design. It is the service oriented architecture (SOA) on steroids.
 The second highest of the four states of fouled up situations (SNAFU, TARFU, FUBAR and BOHICA) that comes from military language. It stands for Things Are Really Fouled* Up. *Did you really think I’d use an expletive?
 See footnote 4
 See footnote 4
 See footnote 4
 See footnote 4