A lot of the business analysts I’ve worked with really need to walk before they run. But I’ll make sure and incorporate the trust-factor as an underlying theme when I coach someone in the future. Thanks!

Good stuff there. The connection between BAs and IT is crucial. People do not realize that a BA *should* be doing more than acting as a translation layer. When I first got interested in learning more about the software development process other than writing the code, I was doing a lot of learning through my employer’s online training, in the direction of management. I learned a lot about risk management and Six Sigma fundamentals. Reading that stuff really opened my eyes. Since then, I have tried to bring the spirit of both of those disiplines to the table. Indeed, Six Sigma is, in my mind, a type of risk management, since by reducing the potential points of failure, you are managing risk.

But my experience in the business world has been that companies simply don’t “get” these concepts. Risk management? The only risk management that occurs is nearly completely emotion based. “Risk” is when someone feels queasy about an idea, and “managing” risk means to shoot down the idea. This is why so many people in the business world act like dogs backed into a corner, lashing out at anyone trying to improve things. In an emotion-based “risk management” environment, “risk” means “will this change the status quo?” regardless of the safety nets, condition of the status quo, or anything else.

People feel a fundamental lack of control over their own destinies. When they acheive a modicum of control, they defend it. That’s why the manager that rejects any kind of process re-engineering from outside of their group will then turn around and go to IT with a diktat of how the software should work. It’s all about control.

The approaches that I’ve had the most success with involve spending very little time discussing the software or even the project. They approach the customer in a manner designed not to collect requirements, but to instill trust. You talk about past projects, and the sucess that they’ve been. You talk about how the clients tried to have ultra control, but it caused problems until they loosened their grip and let you do a proper *analysis* of their *business* and then draft specs based on that. You talk about things that have happened, both good and bad, so that the customer sees your honesty. And so on and so on. After a while, you’ve built the trust. Next, you spend a lot of “hands-on” time with the customer. You learn their job. You spend time with the people doing the grunt work, find out from them what’s right, what’s wrong, what they would like to see changed. Hint: people are a lot more comfortable being brutally honest and open when they are not at their desk; go to lunch, or visit the smoke break area (for the record, even after I quit smoking, I found that spending time in the smoking area was critical to getting my job done). Do the same thing with the supervisors, the department heads. Don’t take notes right then and there. That scares people. Just talk, listen, ask questions that show that you’re learning. Keep asking, “why?” If you can, spend some time trying to do their job.

So what has happened? At this point, I’m quite familiar with their process, what’s right, what isn’t, what management thinks they’ve said the process is, and what the workers are actually doing (rarely in agreement!). Management has said, “we do this because it is a legal requirement, we do that to make the records easier to handle”, and the workers have said, “we avoid that part of the process because it is hard to do right, and we ‘fake’ this part because they didn’t buy the equipment needed for it to work.” Now I have a realistic idea of the challenges.

At that point, you disappear for a while, and draft a document. This document should contain the following items:

* Introduction to the topic
* Description of the current scenario, including “challenges”, “successes”, and “failures”; be brutal but tactful
* Goals identified by management and through analysis of the current scenario; most of the goals will NOT be driven by the client, but by your analysis
* Point-by-point breakout of features/plans/whatever in your solution, with in-depth details explaining precisely how these will address the goals
* Section providing them with some choice, and a full disclosure of the pros/cons of the choices. Remember, you are fighting against their fear of being powerless, it is better to let them make some choices and feel like they have control, even if they make bad ones. By setting up their choices for them, you ensure that they can’t do TOO much damage to the over all project
* “Next steps” outlining precisely who is responsible for what, including what decisions need to be made
* Conclusion

This document format has yielded outstanding success for me when I have been able to employ it, as has this entire procedure. It flips the traditional BA on their head. Instead of saying, “what are your requirements”? and letting the customer dictate outside of their domain (software projects, software design, UI, etc.), you are allowing them to use your expertise, and giving them control over what is properly their domain (“these are three ways that I have found to meet your needs, which of these works best for you, and why?”).

J.Ja

I touched on the need to think this way in Business Analyst Profit Center, which surprisingly, was written a couple weeks before this article :).

Here’s the problem. The business is a profit center, with an overhead charge for IT. Even when it is not true, that IT cost is perceived as a fixed cost by many business managers.

IT is almost always managed as a cost center. IT teams have budgets, and they do projects. They manage to capacity. This removes the incentive for IT teams to manage to ROI. At least in the couple dozen or so Fortune-500 IT organizations where I’ve worked and consulted.

You’re right, and in my experience, it is usually a lack of education / awareness that causes the problem. Unfortunately, the management accounting systems (with this profit center vs. cost center approach) don’t encourage people in IT to manage towards ROI, so people don’t get the context or training needed to do the simple exercise you outline.

I just gave myself a heart attack a few minutes after your comment when I brought the site down during an upgrade. If you’re reading this, both the site and my ticker are fine. But I gotta go rest now. Have a great one, I’m really enjoying this conversation. Anyone else want to join the fun too?

I agree, and I’ll up the ante by $10. I consider “automating this process” or “writing software to handle this” to be considered a “process change”, even if it is supposed to faithfully reproduce the existing process. So in a nutshell, unless someone can prove to me that spending time & money to pay project managers to manage, BA’s to analyze, programmers to write code, etc. will have real ROI, it’s not worth even thinking about it. And so many of these projects are supposed to save a half dozen clerical positions at $9/hour a whole 10 minutes per day, or compensate for their inability to follow the process (usually because the process is bad, or poorly documented/trained)… if the project took 2 months to complete with 1 full time programmer involved the whole time, a PM spending 10 hours/week on it, a BA for 20 hours and a QA person for 80 hours to test, and 20 hours of sys admin time to deploy/support (not unreasonable for a small project), that is a cost of 420 hours of “very expensive employees” (PM, BA, programmer) and 80 hours of “pricey” employee (QA), for a total cost of about (assuming $70/hour cost for “expensive” and $50/hour for “pricey”) $33,400. So, at $9/hour for those clerical employees (total cost, about $12/hour including benefits and overhead), we would need to save roughly 2,783 man-hours *just to break even*. Wow, that’s a lot of time! That is over a YEAR of employee time. Or to make it more explicit, that project would have to allow 2 clerical employees to be laid off (or reassigned) to show ROI within 6 – 9 months. All of a sudden, this project looks like a really, REALLY bad idea!

Yet, I see companies greenlighting this project all of the time!

It’s simple math, but people fail to get it. The sad truth is, IT is all too often NOT leading to “productivity gains”, but is leading to “wasted time and money”. All too often, it is CHEAPER to pay high school graduates $9/hour to do Mickey Mouse work at a reasonable level of quality than it is to engage IT. I hate to say it, but it is true. Eventually the bean counters will figure this out and a lot of IT folks will lose their jobs.

And of course, no one is asking the question, “if the current process is so great, why are we emulating it in software?”

I posit that the moment it is suggested to write software to replace manual work, that should automatically trigger a full re-evaluation of the process, determine if it is worth writing in code, and if it is, re-engineer it to be approrpiate to software, not merely replacing paper with a Web form and the filing cabinet with a SQL database.

J.Ja

I really hope that you get to work with some good teams in the next year. It doesn’t have to be like that.

I will pick on one thing you said, since this is such a fun conversation. You said “what should be happening is…a complete process rewrite…”

It really helped me, as a former coder, to be able to apply the opinion I expressed in comment #10 (scroll WAY up) about complete code-rewrites, to process-rewrites. The only reason to rewrite a process is if you can make that process more effective (by increasing top-line or bottom-line revenue). If the value of the change does not justify the cost of the change, don’t do it. You should certainly know, as an organization, what your processes are. For an organization to ‘know’ something over time, that means to create documentation.

If your processes are not documented (at a process level, not a procedural level), then you can’t really know where you will get the most benefit from re-engineering. There is always more work to be done than can be done. The best organizations invest their resources where they can get the greatest return. And to do that, you have to understand your processes. Some of them will most certainly benefit from rewrites. But some of them won’t.

Thanks again for helping keep this alive – really good stuff!

I’ve revised a lot of my thoughts regarding Agile and Agile-like development over the last year or so. Some of it was because I discovered that much of my negative feelings stemmed (rightfully!) from people promoting project anarchy as “Agile”. And some of it is because of things like what Scott says right above. I’ve seen more and more the sheer incompetance and mediocrity of our industry, enough so that I am blindingly sick and tired of it. It is clear that probably 90% of the people involved with requirements gathering, specification writing, etc. have no business doing these things. They don’t know what to ask, or how to ask it. You have BA’s asking users and managers who have never been involved with development, “what do you need?”, expecting the user/manager to essentially do their job for them, write it down in a way that a programmer can understand, and call it a day. The users/managers don’t know how to identify their real requirements (that’s the BA’s job!), so they give surface level fluff like, “I need a drop down menu here…” And what do you get? A project spec that essentially says, “replicate what we do on paper with a computer program please: replace the paper with a Web form, the filing cabinents with the RDBMS, the clerk with a search screen.” Guess what folks? If the existing paper process was so great, you wouldn’t be looking to dump it.

In reality, what should be happening is an identification of the goals, a complete process rewrite, and then an implementation of that process in software.

What Agile/Agile-like methods bring to the table is a means of compensating for the overall incompetance of those involved in the process, by allowing them “bonus rounds” or “extra credit” opportunities frequently to make up what they missed. The problem is, the people who stink at this so badly that they are constantly missing major requirements are the same people who turn “Agile” into “Anarchy”.

We can’t win, and frankly, I have become incredibly pessimistic about this industry as a whole. We are not delivering value to our users, and for every ounce of productivity we deliver, we create an ounce of pain. Email is a great communication tool, but it is used to swamp people, for an overall loss of productivity. Applciation replace paper, but don’t figure out how to handle “edge cases” that on paper can be easily solved by writing a note in the margin and crossing out a few items on the form. And so on and so on.

Sigh.

J.Ja

OK, as to “undiscovered requirements” – yes, I’m driving a hard line about them being undiscovered by the team doing the work, not necessarily that they are undiscoverable by anyone.

Sure, the security example may have been discovered but forgotten (I put that in possible-failure-mode #2 from the article). But if it were not discovered, that does not mean it does not exist. Nor does it mean that the team should be absolved of it.

One of the challenges that companies face when outsourcing product development is that the third-party may not understand their domain. The Hyatt example is especially egregious, but it could be something more arcane (and just as critical).

Wordpress software (at least as of a year ago) was not hardened against SQL injection attacks. I know – my blog was successfully compromised, and I had to update to the current version, replace all of the source code (and customizations), backup and process the database, and do a lot of due dilligance to block the exploit in the future and assure that the damage had been repaired. WordPress has been around for a long time, has extreme market penetration, and has many people scouring the freely available source code. SQL injection attacks have been around a long time too. I expected (a year ago) that WordPress was hardened against them. But it wasn’t.

Just because that team had apparently not discovered that requirement, it did not absolve them of the responsibility. A better team would have found it.

In a particular domain, there will be other examples that are just as obvious within the domain.

• Of course an insurance agent can be licensed in multiple states
• Of course the UPS must provide enough power to run the equipment
• Of course the signup form must support visually impaired users

You can make a compassionate argument, with respect to any particular team, that that team would not be able to discover requirement X. I contend that if X is required, you have staffed the project incorrectly. The blame may not lie with the team member, but it doesn’t just evaporate.

A process, such as agile, that incorporates frequent feedback cycles, will present opportunities to uncover otherwise undiscovered requirements.

A process, such as agile, that encourages the team to respond to these “after the train has left the station” requirements is better than a process that requires them to languish because they were discovered “too late.”

“…failure to implement an undiscovered / undocumented must-be requirement still qualifies as incompleteness.”

Well, I guess this can’t be realized until after the fact, so you can be complete…then, oops, you are incomplete. Is the whole insecure Hyatt thing what you are referring to with this statement? I mean, securing a customer’s credit card can’t be considered an undiscovered requirement at this point, I would call it a forgotten one. An undiscovered requirement has to be something no one has thought of before within the domain, and if no one has thought of it yet, YOU CAN’T IMPLEMENT IT. …sorry, its late, but when I read the above statement the first time, I thought my head would explode, better to type in CAPS for a bit to let off the pressure.

OK, the Nyquil is kicking in, will check back tomorrow… Dave W

Another thought I’ll throw out there – “100% responsive” does not equate to “do 100% of the things they ask you to do.”

In the open agile project we’re running here, we’re being responsive to every customer who shares their inputs. We may not do everything they ask, but we will respond to, and incorporate all of their inputs in our decision making.

I’m pretty certain that’s a consequence of Conway’s Law and not necessarily of Agile adoption.

By the way, one of the progenitors of Scrum, Jeff Sutherland, runs one of the most proficient Agile development teams in the world at PatientKeeper, which is mission-critical decision support software for physicians and nurses. Contradicts assertion #1.

On the maturity of the organization, I think it is less about the maturity and more about the commitment. Start ups tend to have a lack of focus in the drive to get something *anything* out the door before their opportunity passes. Established companies have just enough legacy code and habits to be a challenge, but are still short on time. Mature companies are set in their ways. Each situation is different, but regardless of how it is approached, the whole team needs to be commited to “Agile”, and know how to do it right, to make it happen.

On the topic of #4, the “Cranky PM” post is 100% right. “Agile” only works when the product is for only one customer! Go ahead, try being 100% responsive to your first and only customer, and you end up with a product that only they will use. Here is an example. Let’s say that you are working on a “just in time” parts ordering system. Your first customer is General Electric. So you are totally responsive to them, and build exactly what they want. Do you think that Toyota or IBM or anyone else for that matter will want it the “GE Way”? Nope! Instead, you *properly architect your code* (bye bye “fast release cycle”!) and make it so that customizations can occur at implementation time, via database, config file, etc. You need a rather monolithic code base to do that, because you are abstracting so much of the code.

I agree that a poor team will blow up a waterfall project, but the explosion is so much more contained. When your first milestone is missed, you know something is rotten in Denmark. With “Agile”, you wake up one day and find out that some rogue programmer has been taking direct calls from the customer, and cowboyed his way into a real mess. With waterfall, there is just as much testing, it just occurs at a more “built” state. Indeed, I could argue that waterfall is *more* efficient, since you are not retesting the code every twenty seconds. After a certain point, the tests take much longer than the code changes. Therefore, it is much slower to run them constantly than during set points.

Finally, let’s get honest with ourselves. *No one*, not even the biggest “Agile” proponents, will use “Agile” for an air traffic control system or something equivalent. If “Agile” can’t handle a “life and death” project, why would you trust it for “mission critical” applications? At that point, what do you have? Something good for free consumer Web sites and that is it? On the other hand, the Java license states that it is not suitable for air traffic control systems, nuclear power plants, etc…

So I really am going to stick to my “softened stance”. “Agile” can be useful, but only in a very specialize role. To me, it is like a C-Section, one way of getting the baby out, but most doctors do not recommend doing it without a good medical reason. If you have a valid business reason, like a single customer for your product who requires constant evolution of the product, or who is willing to accept the “initial release” provided that their “wish list” gets built quickly, go for it. If you are building mass market software that requires reliability and is complex enough for users to have to be trained in it, “Agile” is simply the wrong tool.

J.Ja

AVA – I think you make great points, and you’re right – the details definitely vary with type of project. They also vary with skill of the team, nature of the office politics, etc.

When the cost of a deployment outweighs the benefit of an incremental deployment – and your example is a great one – you definitely shouldn’t do it. However, if you believe there is a benefit (ignoring costs for a second) to accelerating your release cycle, I would suggest that you
1) quantify that benefit somewhow
2) determine how much you would have to reduce deployment costs to make it a good business decision, and
3) figure out how much it would cost you to make those changes. If there’s enough ROI, you should do it.

You can look at ways to automate some of the testing (for example permutations of dev environment via virtualization) that might work for you. You can explore the possibility of making physical media distribution optional (and/or for a fee) with website downloads available more frequently. You can take a page from the agile folks, and offer “latest stable” + “latest tip”, so that people who WANT to risk it all on the bleeding edge can try, and people who don’t want to will stay away. My intuition is that these things would help with any market, but ultimately it is your call.

http://www.crankypm.com/2007/04/so_you_think_ag.html

The source article has created another discussion that “went a different way.”

What a great read – I love her stuff!

Kelly Waters
http://www.allaboutagile.com | Blog all about agile

Product managers HAVE to focus on multiple customers. Companies, especially young ones, as Ivan points out, HAVE to focus on key customers.

My wife used to work as a mediator, and she used to say “if both sides are unhappy, you know you’ve reached a reasonable compromise.”

Don’t know that I can top that!

Code entanglement. When I was still doing coding/consulting, I was airlifted over and parachuted into some spaghetti code nightmares that would blow your mind. And usually with a complete lack of testing automation.

There are three ways to fix that problem.

1) Rewrite the whole thing but do it right this time. Almost never a good business decision, as much as it appeals to technologists.

2) Change the way you write code starting right now. All new code requires tests, and should be as well designed as reasonable. Over time, you’ll be able to gain confidence that “at least you didn’t break the new stuff.” And that will gradually afford you the opportunity to start refactoring the spaghetti a strand at a time. It may take a year, but there’s no incremental cost (In my anecdotal experience, the breakeven was 3 months, including the time spent creating a testing framework and training the team to use it – AND including the extra time it initially took per work item to write tests. Within a month, there was enough time/cost savings to “pay for testing by the developers.”)

3) Sell the company and change your cell phone number.

Team capability matters. Justin makes a great point that rapid-release cycles will crater with an unskilled team. So will waterfall processes. The difference is that you spend a lot more time and money with a waterfall process before you discover how bad of a job the team did. If you let the developers release the code “into the wild” without some form of validation and testing, then yes – agile is a death sentance with the wrong team. Again – at least you’ll find out earlier.

@Justin J.
Items 2, 3, and 5 on your list seem like very high hurdles to get over in order to justify using Agile. What are your thoughts on the maturity of the organization (early stage startup vs. established company vs. big, honkin’ enterprise) affecting the successful use of Agile?

Item 4 is a tough nut, too, especially for young organizations that HAVE to be responsive to prospects and customers in order to keep the product/company going. I have been in situations where I have been expressly told by the executive staff to do whatever it takes to close whatever the next big deal is. Not a great way to manage a product, but it sometimes has to be that way in order to continue to have a job as a PM (at least at that company).