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![1] 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[2] 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[3] 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[4] 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[5] to TARFU[6] to FUBAR[7] and result in a deplorable BOHICA[8] 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!
[1] That is assuming you can find some!
[2] 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.
[3] 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.
[4] 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?
[5] See footnote 4
[6] See footnote 4
[7] See footnote 4
[8] See footnote 4
Keeping Agile™ with Brian Lucas 
Very funny and very true. This is a different sort of post for you. I have become a regular reader and enjoy your blog a great deal. While I am somewhat disappointed that you don’t post more often, what you do post is always worthwile and full of wisdom. This post is less scholarly than some of your previous ones. It is very down to earth and entertaining. I would love to read about some of the snafus and tarfus that you have known about in your career. I’ll bet they would make an interesting post. I am forwarding this post to a number of my clients. I look forward to reading your next post.
Riley – thanks for your comment. Of course you know if you fail in your agile effort the CEO will disavow any knowledge of your actions. Unfortunately many of us are all too familiar with snafus and tarfus and fubars than is healthy for American business. It never ceases to amaze me just how many businesses survive doing stupid things and running on high octane insanity. They survive because somewhere someone is providing some value to a customer somehow and the competition is just as screwed up and inefficient and the customer is blissfully ignorant of it all. If we were talking about solution selling I would pose an imagine statement at this point which would say, “Imagine if there was no company politics in your organization. The CEO was open to opposing opinions, could be told when his/her ideas were silly and received bad news with honest gratitude. Everyone in your company was fully engaged, competent and worked well with everyone else. What would it be like…” Sounds like something that someone should try to make work doesn’t it? -Brian
Most of us only complain about mission impossible situations or dream about it being better. You are writing about it and making it happen with wit and humor and knowledge and talent. One day soon company by company will get the message and we will change. Thank you for showing us all the way.
I agree with Riley this is very funny and very true. I would love to read about some of the situations that you know about that did not turn out well and your analysis as to why.
I would like to hear about how to deal with the kind of nonsense that goes on when politics are involved. It is so frustrating to know what should be done and not be able to say it because it will tick off some boss.
I really want to thank you for these tips. This is a solid 13 point check list on how to do agile successfully and focuses on the people and not the process or the terms. As a CEO of a midsized development shop, I struggled with control and quality issues when we began using agile 7 years ago. I spent money on training some of which was wasted and we thrashed through issues with customers that wanted agile speed, but couldn’t define their actual needs in real time. As we gained more knowledge and experience with agile, I began to focus in on the very same 13 points you identify here. If I would have had your checklist at the start it would have saved me 5 years of grief. Anyone getting into agile for the first time should take special note of this list and use it as a set of goals in their agile adoption effort. In short, this is a good direct and truthful post without the nonsense and fluff you normally read. If you have time please explore the subject of agile estimating in one of your posts. I am anxious to hear your ideas!
Greg – Thanks for the comment! I wanted to explore with my readers the subject of estimating since I have some pretty definitive ideas about what works and what doesn’t; particularly in reference to estimating versus priorities and sizing. It is just a matter of getting the time to do it. -Brian
Great article! I work in an organization that dipped its toes in the Agile pool, and adopting Agile promised to make us better–better at responding to our customers by developing a product that they really want to use. But I’m afraid the Agile wave shattered on the rocks of the list of problems you describe above. The key people approached adopting Agile the way Lothar of the Hill People considered changing how to conduct the great hunt. When provided with a suggestion for improvement, he replied, “That is a good idea, but we fear it, so we must reject it”. And so, we’ve merely adopted Agile labels, but we’re still working in small waterfall iterations.
I dream that some day, I’ll get to work in a true Agile organization, but I may pass on before that day comes.
I work in the same kind of organization Baron and it is a real pain. The politics run wild, people in management are incompetent and process is king. You would not believe the stupid way they tried to implement agile with a project manager that had no experience in it and was working to defeat it every step of the way. Despite all that there were some things that did work about using agile. We did get a lot done quicker. But we are now moving back to the old way again since the agile advocate left the company. Life is great, NOT!
I was a faithful viewer of the old TV series. Your post is colorful, creative, true, easy to read – wisdom for every businessman! Please keep posting these and many more! One of the best blogs I have ever read! :Walter
Thank you Walter! I will do more on Mission Impossible in a post soon.
You are right Walter! It is really too bad however that every businessman does not recognize this wisdom.
What an entertaining article Brian! While most of this did not apply to my situation, I still enjoyed it! That is a tribute to your writing skills. Sometimes I feel I am on an impossible mission for a different set of reasons. I never actually thought I would really enjoy reading a blog. The way you begin it, draws me right in however. I wonder if you could write a mission impossible article not just directed at computer systems. I saw in a comment that you intended to do another MI article. I also want to say that I am very impressed with the language, sensitivity and timeliness of your replies. You act like a TRUE gentleman, something rare in this day and age. Your new friend Fran.
OK Fran my new friend I will write an article just for you and not mention computers at all. I will call it, Mission Impossible really is agile.
Brian,
Your checklist is one that I am sure many CEOs would find painful to admit to in their organizations. Most that read it will be in denial and dismiss it outright. So often people like you, who are obviously very intelligent, are right about a subject that others (myself included) have spent a great deal of time, money and effort on with poor results. When you advance a solution rapidly, regardless of its validity, we resent it. That is our loss, but that is the way of the world. I find your 13 points to be valid in many businesses that I know and am involved it. To your credit, you provide a positive solution for each one, if only simply expressed. I would ask that you expand on your 13 positive points in a future article. A paragraph on each would help many at the C level deal with the harsh realities that we are now faced with in this agile business clime. With each article I read my appreciation and respect for your abilities grows.
With Deepest Respect,
T.DiMarcio
I will expand on these as time permits. Thank you for your words of encouragement. Far too often the messenger is shot and mavericks corralled in a pen of small and self-protective thinking. These are the very people an enterprise needs to reinvent itself.
It does feel at times that agile in mission impossible!!! I worked on many successful agile software development projects. Later on when the concept was expanded to a larger venue it failed, sometimes horribly. Your list covers that gamut and that is something I really appreciate. I like the references you make to any one item and any three items. I feel that the thirteen points are not all equal however. Some are absolutely critical for success; others while still important can be skirted around a bit. For example, I have worked on successful agile projects where the user was far from knowledgeable, but the analyst made up for it. I have also seen cases where development had poor unit test track records and the test team uncovered all the bugs. It is somewhat a minor point I grant you, though I believe your list would improve if you added a prioritization to each point.
Good points and I agree completely. As for the Mission Impossible feeling most of us have been there at some time. You have two choices: take a deep breath and ride it out or hop on your horse and ride out of town as they say in the old west.
I assume this was the first in the series of the mission impossible theme. I agree with your points here and your suggestions on how to turn them around. Many of these apply to manufacturing and services as well as software development. I think it would be a great idea if you added variants for each of those industry categories as well. I am impressed with your writing. This is the third article I have read and you are three for three – right on target. Well done sir!
Sincerely,
J.Turner
That is a very good idea! I will add it to the list of things I need to write about. Thanks for your support and the suggestion!
Brian, I am getting so much enjoyment from your blog. This mission impossible theme has given us all a hot topic at break to discuss the old show and the wonderful, sexy and smart characters that were in it. In truth, when confronted with a problem, I now ask myself what would be the agile thing to do. Some of us have put the mission impossible ring tone on our phones. Working in a hospital environment can wear you down. You have been a breath of fresh air and I actually see little changes being made because your blog has got us thinking. Thanks for being you!
Totally cool! Thank you so much for sharing the success you are begining to see with me!
Brian – I want to thank you for your blog, your generosity, your professionalism and all that you share with us. You are a very intelligent and creative person and you are helping to bring a positive message of change and hope to everyone who reads your blog. You have already made a huge difference in my organization. From the comments I have read on your blog you are affecting others deeply as well. Your message of the need to change is both simple and profound. Your writing is so smooth it almost sings. Thank you so much for being the right person, at the right time and in the right place! -Jack
Jack, what can I say, but your the MAN! Some of my readers offer compliments for my suggestions, you act on them! If my writing sings then I am in the company of Homer and Tolkien and L’Amour three of my favorite writers. I do not under any circumstances feel that is true, but I appreciate your continued support and wish you all the best at reforming your organization.
I have passed this on to the management of our information services and of course I have received no reply. Its a shame they aren’t as responsive and dedicated as Wayne appears to be. Keep writing more articles Brian. You have not posted in a while. -Fran
Oh Fran if only there were more hours in the day.
You absolutely have really good article content. Regards for sharing your website.
Smack dead on target! This is a great checklist for identifying problems in your enterprise and how to address them. If you don’t follow these rules, ANYTHING and EVERYTHING can become mission impossible. Congratulations Brian on another super post!!!!
I couldn’t figure this out cause I never knew there was a tv series then someone clued me in. Guess I’ll have to watch it. Is it on Netflix?
I can attest that this checklist is 100% accurate! Agile is absolutely MI at my company. We are dead on with all the negative checklist points you have stated. The CEO thinks he knows everything about everything and is 20 years behind technology. He came from DEC and thinks he really understands software development. All his executives are toadies. We have an over large IT staff and develop truly terrible software. We do use various other IT companies for software development since we are in the manufacturing business, but every time we get one with integrity that tells him what he is doing wrong he fires them. That is his MO if you disagree with him you are fired. I am retiring in February so by the time anyone reads this I be gone. Maybe it will help someone else.
This is a comprehensive checklist that should be on every CEO, CIO and IT Project Manager’s desk. We should all set up measurement points for each item and check on its health constantly. LVP
Would you recommend that if some or all of the negative conditions in your first set are true that the business avoid agile? If they have not been successfully addressed, is it then your recommendation that waterfall be used?
It is sooo Mission Impossible where I work, I have given up trying to introduce change. Politics have won out and until I can get another job I’ll just keep my ideas to myself. Dilbert would feel right at home here.
It sure is impossible in my company. My boss yelled at me and gave me a failing review rating for bringing up the fact that we should consider agile development methods. Everyone is so unhappy here. They keep firing and laying off people cutting back and asking us to do more. I have not seen management cutting back or taking pay decreases.
Darleen – It sounds like a poisonous atmosphere. My advice would be to move on if you are in a position to do so. Things are starting to break in the business community so there is more opportunity out there. Good Luck
Agile is never mission impossible only ignorant and belligerent managers are.
Our CEO is a megalomaniac control freak you bet its impossible here!
Brian please don’t publish my name or email address. My company is a mess. We are supposed to be doing agile development. It is not anything that you describe or that I have read. The project manager here is the person you could imagine. She is nice to your face then stabs you in the back at every instance. She fought the introduction to agile at every step of the way. She is very skillful politically and plays up to the other managers. Nothing is ever her fault. Worse she was recently promoted in a management shake up. It seems like we do the worst of everything. There are so many bugs in the software that we develop. How the management doesn’t know all the damage she is doing to the company I guess I will never know or understand. She creates PowerPoints and presentations that are so far from the truth and gets away with it. I would like to leave. I have looked for another job and found a few that a temporary as a contractor. I am a single mother and have a young child to support. So I am afraid to take this risk. In the past when someone complains the get a bad review and are eventually let go. The HR manager always takes the company position and never keeps anything you tell her as confidential. The president says his door is always open, but I am reluctant to go to him. Most people here just live with it. Are most companies like this? do you have any advice for me? I am at my whits end.
Good Post!
Is agile really mission impossible? In my opinion, it really depends upon the people in the organization. In particular, the CEO or whatever the top executive is called. If they really understand what agile is and are truly committed and have the courage and political power, the answer is yes regardless of how messed up things are. I admit that is an awful lot of qualifiers. You can always sneak in a little agile software development success even if the CEO is agnostic towards agile or oblivious. That ends up being only a drop in the ocean though. It helps a team, but does not have a large overall effect in the enterprise. Unfortunately, for many organizations that are run by executives brought up in the hierarchic pecking order of the old boy network, it IS an impossibility. They cannot imagine a flat structure and the concept of treating the workforce as equals is against everything they fought for in their business careers. There are a few examples of large enterprises that were created to be agile or have become agile, but these are less than 3% of businesses listed in the Fortune 500. Agile will not become the predominate structure for organizations until smaller businesses that have grown up in the last decade become the dominant force and demolish the old guard of hierarchical monoliths.
Wilhem Craiger
Consultant
I think agile is mission impossible if the attitude is not there. Everyone needs to be committed from senior management through the user community. If everyone is onboard and motivated it will work. It will seldom work if only the development team is excited. It is interesting, but as a CSM (yes Brian I agree it had little real meaning) I have seen teams of even C and B level developers succeed with agile when everyone was all onboard and being supportive. I once somewhat covertly watched a user actually sit down with a reasonably inexperienced developer who was struggling to get a C# component to work and patiently answer questions the developer had about how it was supposed to work and what could be left out. The user was a very intelligent young woman though definitely not a programmer. She asked insightful questions of the developer as problems arose and his explanations actually helped him solve his own problems. Before people start clamoring about the user story containing this or asking where the senior developer where, let me say two things. First this was their first agile effort and they were still figuring out how to write great user stories. Second this was a new company and there was a serious lack of senior developers. I was the only outside person brought in to be the Scrum Master. Before beginning the CEO brought everyone together and held an all day session about agile, what it was, what the expectation was for it and why it was important to them. He further got it across that it was going to be a learning experience for everyone including himself and that they were going to succeed and that blame and finger pointing were not going to be tolerated. He really did his homework for a non-technical person and I was more impressed with him than many in our industry who supposedly have serious agile credentials. Now back to the user/developer story. Watching this was a beautiful moment. I do not know a better word to describe it. Instead of the developer who was a) inexperienced and b) not the smartest person in the world, being thrown under the bus and fired for incompetence, his efforts were improved through team cooperation. The fact that this support came from a user made it even more remarkable. We all know the very adversarial relationship users and IT have developed over the years. Needless to say the project was a success and even the weak developer in question was able to find a nitch in the organization as a very good help support person because he developed a wonderful attitude towards helping others as he was helped. Too many people say that you need an A team for agile to be successful. I agree that if you have an A team and everyone is cooperating and supportive from executive management on through the user community that you can achieve incredible results with agile. But that is rare and unrealistic! You can be successful with agile using the normal mix of people if everyone has the attitude of cooperation and success and works as a team. That is what is most important.
It is where I work – Brian! I’ve tried several times to make this happen and was shot down in flames every time. As soon as I get my CSM I am out of here.