The week before last, I was asked to provide some sample documents from past projects to a gentleman that is transitioning to a business analyst role in from a different position in another area of the company.

As I scanned through some of my old documents for some good examples, I was a bit surprised to find that I wasn’t all that happy with a lot of my older work. It’s not that the documents were that bad. They weren’t. I just kept finding things that I wish I had done differently; that I certainly would have done differently had I known then what I know now - both from a business perspective, and from a principles of business analysis perspective.

So, what’s my point in calling myself out like this on my own blog?

Over the next few days I’ll be wrapping up a use case document that I think is quite possibly the best one I’ve done so far. I think the design team is going to be able to put it to good use and deliver a good software solution.

That said, in another couple years, I suspect I’ll be just as critical of that document as I am now of the ones from a couple years back. I’m working on a longer post to explain why I think this way, but in the interim I’d be interested in hearing whether others among you have had similar reactions while looking through some of your past work? If so, why do you think that is?

I look forward to your thoughts on the matter.

Copyright Practical Analyst, 2009. View the original post or comment on

Did I Really Write That?

Adrian Marchis at Modern Analyst wrote a helpful article on process mapping in which he describes, among other things, diagramming the “as-is” process as part of the overall process mapping exercise.

A very interesting and active discussion has followed the initial comment to the post made by John Owens stating:

One of the major errors taken in business analysis and modeling is that of modeling the “As Is”, then the “To Be” and then trying to plot a trail from the one to the other. This approach is hugely wasteful of time, money and peoples’ goodwill. Most modeling projects run in this way take so long to deliver results that they fail.

My take? I commented that I think there can be value in comparing as-is and to-be models to highlight the benefits of the proposed changes. I also think that an as-is model provides a contextual baseline (gets you on the same page) when dealing with stakeholders across business silos. That said, I am an advocate of not doing work that no one will use and no one is waiting on to complete their work. So when that is the case, by all means, skip the as-is.

Since that initial interaction, Owens, Marchis and several others have weighed in with well-reasoned comments over the value - or lack thereof - of the “as-is”.  Scott Sehlhorst (@sehlhorst) and David Wright (@dwwright99) have also provided their “two-cents”  just to name a couple gentlemen readers of this blog will probably recognize.

What do you think about documenting the as-is process? Valuable, or waste of time?

Before weighing in, I’d encourage you to go read the comments on the original post.

While we’re on the topic, do check out John Owens’ site, where he has posted on the discussion as well. He has some very interesting insights and material available on business systems analysis and business and data modeling.

Being able to learn from great posts like Adrian’s, and interaction between folks like David, Scott, John and others who know what they’re doing and have been doing it for a long time is one of my favorite things about the BA blogosphere. Read up!

Copyright Practical Analyst, 2009. View the original post or comment on

What Good is the “As-is”?

Business analysts? How many times have you been asked what you do for a living and had to pause to think for a minute about exactly how to describe it?

“I translate business-speak to tech-speak and vice versa.”

“I help my  company apply technology to solve business problems.”

“I work with computers.”

“I’m sort of like a consultant, but internal to the company.”

“I help business folks validate their business cases, and then help IT understand what the business needs.”

“I write requirement specs for software developers.”

“I work in sort of a hybrid business/IT role to help define business problems and deliver solutions.”

“I work in IT.”

“It’s complicated.”

Those are a few approximations I’ve probably used to answer the question, “so, what do you do for work?”

Granted, some of those are cop-outs for when I just don’t feel like going into it, or I know the person asking doesn’t care anyway. The problem is, I’ve been doing this gig for a while, and haven’t really had a consistent “elevator pitch” for what exactly it is that I do.

Jeff Martin, founder of Collective Genius provides some help in his article, “You Help Companies Change.” Per Martin:

If you are practicing activities that fall within the BABOK, then what you do is very simple and only takes three words! You “HELP COMPANIES CHANGE.” …. The activities of business analysis are specifically to implement change. We change processes, products and technologies to continually move organizations forward and to make them better.

In the comments of the same article, fellow Analyst, Atlantan and Jonathan, “Kupe” Kupersmith from B2T Training adds:

When people ask me what I do, I’ll be sure to lead with “I help companies change.” This will peak most people’s interest allowing me to go deeper into exactly how I can help.

I think Kupe’s right about it being a great conversation starter. The odd thing is, that’s pretty much exactly what I told people who asked what I did when I was in consulting. I’m not sure why I didn’t cary it over as I crossed over into industry in my present BA role.

Anyway, Martin’s article is a fun, useful read and in it he has more to say on Analysts and their role as agents of change. I’d encourage you to go give it a look.

That said, what are some things you’ve told people when asked what you do? I’d be as interested in hearing the funny or weaker examples as the good ones.

Oh, and thanks to Alex Papworth (twitter) for sharing the link to Martin’s article on Twitter.

Copyright Practical Analyst, 2009. View the original post or comment on

So, what do you do, exactly?

Consider the following Albert Einstein quotes:

Everything should be made as simple as possible, but not simpler.

We can’t solve problems by using the same kind of thinking we used when we created them.

And of course, the renowned definition of insanity:

The definition of insanity is doing the same thing over and over again and expecting different results.

Think about these quotes in the context of your individual work. Then, consider them in the context of  how your team or delivery organization operates.

What are some things we could improve by simplifying? How can we think differently and what can we do differently to get the desired results instead of the same old results?

I could follow with another 500 words or so of what I think, but in this case I’m going to follow Einstein’s advice and leave “simple enough” alone.

Copyright Practical Analyst, 2009. View the original post or comment on

I’m with Einstein

The IIBA is holding an online kick-off of the new version of the Business Analysis Body of Knowledge (BABOK) Tuesday, March 31 at 1:00 PM EDT

Topics will include “what’s new in version 2.0, understand how to use and benefit from it, and find out what you need to know to get ready for the updates to the CBAP® exam” as well as Q&A time. Head on over to the IIBA site for registration details. I’m interested to hear and see more about version 2.0 and plan to attend. Hope to “see” some of you there!

Copyright Practical Analyst, 2009. View the original post or comment on

Come Fête the Release of BABOK 2.0

Bob Lambert says IT should take the initiative in solving problems  of business/IT misalignment, and thinks the requirements process can be an effective vehicle for reaching out. I agree.

I could come up with  a number of reasons why IT has an interest in being the one to reach out, but one reason in particular occurred to me as I was reading through Lambert’s post.

Certainly, both sides have a part to play, but IT should take the initiative not only because they possess the “knowledge that business people need in order to maximize the value of IT and efficiency of business processes”, but because, in essence, the business is the customer and corporate IT is just another vendor.

Now more than ever, business folks have a wealth of outsourcing and off-the-shelf purchase options that place homegrown IT in the position of having to compete for business. If IT doesn’t present a compelling value proposition and make the effort to align with the business, then someone else - who is willing to work harder at it - will.

Regarding use the requirements process as a vehicle for reaching out, Lambert has this to say:

In many organizations IT manages the forum in which these conversations can occur: the requirements process.  In my experience a good requirements process is long enough for the business and IT teams to get to know each other, offers generous opportunity for both structured and unstructured conversations about business needs, and brings together knowledgeable business and IT participants.  IT is typically able to bring the insights of seasoned application developers to the fore in a well planned requirements effort.

Yes, everyone has responsibility to “cultivate personal relationships based on mutual need and respect,” but IT can and should bring substance to the relationship in requirements definition.

I could say, “amen” and leave it at that, but as an analyst I will add that I think that an IT organization that brings a true “help me help you” attitude to its interactions with the business during requirements gathering can do a lot to build ( or smooth) relationships and align organizations. To do it right, more give-and-take may be required at a planning or steering committee level, but don’t discount the value of initiative taken at the grassroots!

Also, to give credit where due, I should note that Lambert’s post is actually a response to Ara Trembly’s original article, Business/IT Misalignment: Whose Responsibility? (isn’t the blogosphere great?). I’d encourage you to give Trembly’s article a look, too for full context.

So, what are your thoughts on how best to align business and IT?

Copyright Practical Analyst, 2009. View the original post or comment on

IT’s Interest in Business/IT Alignment

I’m becoming more and more a believer in the value of modeling and visualizing requirements. I was trained in the more traditional methods of eliciting and capturing requirements, and have seen success doing things that way, but I am quick to  admit that a picture truly is worth a thousand words (or is it a mock-up is worth a thousand “system shalls”?)

In this post I’ll share a few great links and quotes on rapid UI prototyping that have helped reinforce the value of visualized requirements in my mind, and that I thought you might find interesting.

Now, bear in mind that prototyping can be as simple as the mock-up on a paper napkin, and as complex as a fully functional prototype that actually evolves into the end product. As a business analyst, my interest and focus will tend more toward simple wireframes and mock-ups that I’d use to draw out additional requirements and to set design on a solid path.  So, on to the good stuff -

• In an  excellent read highlighting the shortcomings of traditional requirements gathering techniques and the importance of collaborating to conceptualize solutions, Andrew Gordon shares the following on UI prototypes:

Use cases are okay, but there’s no substitute for putting, at least what looks like, a real solution in front of stakeholders. In my experience UI prototypes validate system requirements better that any process modelling or workshops could ever do.

• The Pierson Requirements Group claims their customers are:

[A]ble to capture 93 – 95% of the business requirements functionality by using a collaborative requirements method and by creating and validating paper prototypes with the business community… If a more traditional interviewing approach is used to gather requirements, studies show that only 65% of the requirements will be captured.

• Charles Field blogging at Pathfinder finds that,

[A]nnotated pictures are far more specific & engaging than trying to describe with only text things that can be easily shown. If that adds pages to the document, it is a small price if it gets read and understood.

• Here’s a great article on prototyping. I includes some tips on effective prototyping and a great grid comparison list of rapid protyping tools. It includes all the more popular apps and some interesting ones I hadn’t heard of.

• Looking for example wireframes? Here’s a website (and corresponding Flickr group) devoted to the topic. And while I’m on Flickr, here’s another group dedicated to user experience sketches.

• I’m actually evaluating Balsamiq Mockups right now, myself, and will be sharing my thoughts on it and a few others off the list that I’m familiar with in the coming days.  I’ve also recently been made aware of another mock-up tool aptly named Mockup Screens. Both are extremely reasonably priced, and relatively feature-rich.

• If you really want to keep it simple - and free - and use Firefox, have a look at the Pencil extension. Per the Pencil Project’s homepage:

Pencil turns your excellent Firefox 3 browser into a sketching tool with just a 400-kilobyte installation package. Pencil will always be free and can run on virtually all platforms that Firefox 3 supports.

I’m going to stop the list there for now, although the web is full of great resources on requirement visualization/mock-ups/wireframes, or whatever you want to call it. That said, what other mock-up and wireframing productions do you use or recommend?

Mockup image by lilit

Copyright Practical Analyst, 2009. View the original post or comment on

Requirement Visualization: Mock-up & Wireframe Goodies

First off, if you didn’t get a chance to attend the webcast, I understand it will be available via the IIBA website in about 4 business days.

Secondly, Kevin and Julian did a nice job with the presentation today and answered a lot of questions. I am glad I attended. Maybe it’s my inner geek coming to the surface, but I was really pretty excited by some of the ideas IIBA is working on and about the new and improved body of knowledge.

I have to admit that I had let my membership lapse over the past few months and had to renew just a few minutes ago just so I can get my hands on a copy of the updated BABOK.

Anyway, below are just a few notes I jotted down while listening that I thought my readers might find interesting.

Wider Appeal

For v2.0, the IIBA made a conscious effort to ensure that the BOK reflects the techniques used by most business analysts, and it applies to a wider range of methods, including agile and BPM.

I recall some felt that previous BABOK offerings were more  traditional, waterfall-type methodology-centric. 2.0 has been mapped against CMMI, agile and DoD methods so far to name a few and is relevant to practitioners using all these methodologies.

What’s next for IIBA?

Here’s the stuff that really interested me. There are no plans or dates for the next version of the BABOK as yet. Instead, the IIBA is working on things such as:

• Developing specialty-based extensions to the BABOK, such as for the strategic planning-level BA.

• Launching a community portal for IIBA members. According to Julian, the community will represent IIBA’s efforts to integrate new media and the professional development experience. Expect the community to include collaborative projects on the topic of business analysis, blogs, wikis, group discussions, whitepapers, links to existing resources with ratings by the community and lots of other goodies.

• Providing the BABOK in wiki format on the community portal. The intent here is to allow community to annotate, add detail, and discuss/refine BOK content. It will enable IIBA to gather feedback from the community to help identify gaps, and it doesn’t have some of the same constraints that a printed document has. In Kevin’s words, it could really become “an encyclopedic resource.”

• Finding common ground with other professional organizations. PMI was mentioned specifically. It will be interesting to see what synergies can be reached between the two organizations. At the same time, the effort to map the BABOK to other methodologies will continue.

So, what about the CBAP?

• The CBAP exam will remain based on 1.6 until July 31, 2009. August 1 or later will be against v2.0.

• The updated exam for 2.0 hasn’t been written yet.

• Solution assessment & validation will be more important (weighted more) in the 2.0 exams.

• Another webcast will be scheduled later to discuss the CBAP exam specifically.

Well, there you have my highlights in about 500 words. Obviously much more was covered, such as translation of the BOK into other languages, key differences between 1.6 and 2.0 regarding the knowledge areas, and other items.

Do check out the webinar when it comes out for all the details.

So, did any of you attend the webinar? What were your thoughts and impressions on the whole deal?

Copyright Practical Analyst, 2009. View the original post or comment on

Notes from the BABOK 2.0 Launch Webcast

A little linky love this week for those of us who like to read all about requirements management.

• John Simpson of Jama Software (makers of the Contour requirements management tool) and I have carried on a little dialog on requirements over the past week. He posted some of the Q&A’s on the Jama blog. Go have a look, but here’s a teaser:

Jama: If you had one fundamental tip to provide people, what would it be?

Jonathan: If it had to be just one, it would be to strive to satisfy ALL your customers.  As business analysts, we work with the IT delivery organization to deliver products that satisfy business needs.  That’s the obvious part.

What’s less evident, but perhaps equally important is that we also work with the business to meet the needs of the IT delivery organization (sort of a “help me to help you” scenario).  As consumers of the business analyst’s products, the designers, developers and QA folks are also very much a business analyst’s customers.

I think focusing on the consumers of our deliverables as customers gets us to the point where we acknowledge that writing a bunch of requirements statements and tossing them over the wall is not meeting the internal customer’s needs.  It drives us to the type of collaboration that results in good requirements and successful projects.

• Genefa Murphy, Product Manager for HP’s requirement management solution maintains a blog dedicated to RM.  (h/t Requirements.net)

• This article on Computer World posits that requirements management tools can be used to make communication about requirements “more organized and successful”, and provides some real-world examples.

• Bright Green Projects and Playground are a couple new, web-based requirements management tools that I’ve been informed of over the last week. I’m always interested in evaluating new tools, and they both seem to show promise.

• Check out my previous post on requirements management resources, too, for more good reads on RM and links to other management tools.

Copyright Practical Analyst, 2009. View the original post or comment on

Requirements Management Link Love (09-13)

And welcome to Practical Analyst!

If you listened to my podcast on Requirements.net a few weeks back, you may remember me joking about wanting to change my domain name because “nothing says ‘business analysis’ like jonathanbabcock.com.” In fact, you may have already noticed that I’ve changed domains from JonathanBabcock.com to PracticalAnalyst.com.

I had been planning on making the switch for a while, but had been waiting and waiting for the “perfect time”. I had considered a big re-launch with new features, and in a new more CMS-like format and other spiffy updates. But when it comes down to it, there’s no telling when or if I’d have gotten around to all that. After all, I have a day job and a family, too, and  I’m fine with the blog format as it is for now. The name change, though, was easy.

So, why change? Certainly, one of the reasons I started blogging was to establish a personal brand of my own, but the primary reason was to provide practical tips and commentary on business analysis for project professionals, and to meet and learn from others in the field. Basically, it’s always been about business analysis; not so much about Jonathan Babcock. Anyway, I think “practical analyst” does a much better job of conveying what my blog is about. It’s a small change, but I think it is for the better.

So, yeah, I will be starting from the bottom again in terms of search rankings, and updating profiles on a lot of different social media sites, but in the end I think it will be worth it.

I wanted the change to be transparent to those who have been kind enough to link to my site and articles, so I have set up a redirect so all of your old links to JB.com content should still work, but you may want to update the URL if you’ve got me in your favorites or on your blogroll.

Last of all, I  would like to take this opportunity to thank those of you who have read my blog over the past 2 years and contributed with comments and feedback, and those who have just subscribed to my feed. It’s been a lot of fun, and I look forward to much more of the same under the new banner!

Copyright Practical Analyst, 2009. View the original post or comment on

Farewell to JonathanBabcock.com

We’re hearing all about debt nowadays. Consumer debt, corporate debt, government debt… the list goes on. As professionals operating in a software engineering environment, there’s an additional type of debt of which we also need to be mindful.

Technical Debt

Per Steve McConnell:

The term “technical debt” was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.

Follow Steph adds:

Developer Debt means taking the quick and dirty way today knowing that tomorrow we’ll have to pay more to fix the issue because it will have evolved into a bigger problem, hence the idea of debt with interest.

In Cunningham’s own words:

A little debt speeds development so long as it is paid back promptly with a rewrite. …  The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load…

I think one of the contributing factors (among many, all of which I won’t go into here) to increasing technical debt is the fact that business owners often don’t understand or appreciate it. Here’s a quick, hypothetical example. You give the business owner 2 choices:

• Option 1: Can hard-code at every opportunity, use a few existing database attributes for purposes other than those for which they were designed - this will help us save the time it would take to add new rows.  We could cut a few corners on normal conventions for formatting and commenting code. We can also just slide the functionality into system “B”,  even though we plan to retire it within the next few years, and system “A” is the one better suited for it. We would have to wait another 7-10 days before the system “A” developers wrap up work on another project. The hard-coding is throw away, of course, and cutting corners on the rest of it is going to make it much more difficult for developers that have to go in and make future modifications, but this path will get you your product in 2 weeks.

• Option 2: Can provide an architecturally sound and scalable solution with clean, commented, and reusable code. We’ll need to wait a little longer for developers for system “A” to become available, but that is really, according to the longer-term architectural vision, where this functionality needs to go anyway. This path will get you your product in 10 weeks.

In many cases, your stakeholder probably didn’t hear a word until the last sentence of either option. At that point, of course, s/he wants the faster option.

Again, per Follow Steph:

It’s much easier to implement a quick fix today and ignore the longer term costs because we’re dealing with today, with this quarter, with this release, with now.

Or, imagine your business sponsor thinking: “Not only will the cost of developing it be cheaper, but we’ll begin to benefit earlier from the new functionality! We can realize our ROI for the project way sooner! I don’t care about the whole ‘clean code’ or ‘architecturally sound’ stuff, anyway, as long as the functionality meets spec! That’s all stuff for IT to worry about. Hey, I might even get a raise out of this!”

Ok, so that last bit was a slight exaggeration and to poke some fun, but you get the point.

Using the Analogy

I really like “technical debt” as an analogy/metaphor. It’s something that the non-technical business stakeholder can understand and appreciate. As with our own personal finances, we can do it the right way and pay for it now, or we can do it the quick and easy way and pay for it later with interest.

As a business analyst, I see it as my job to clearly communicate the fact that exactly like card or loan debt, “interest doesn’t sleep” and it compounds over time. What started out as a small expenditure can eventually end up costing a great deal, and can limit our ability to make further improvements later.

Now, to be very clear, my intent in bringing the notion of technical debt to your attention is not to give the impression that we always need to do things the longer, better, more expensive way first. In a perfect world, we’d always have plenty of time, people, and money to “pay with cash,” but such is not always the case. In the real world, sometimes the quick and dirty way is necessary.

In either case, an analyst’s charge is to help business decision makers make educated decisions based on the available options, and to understand the potential ramifications of those decisions. We do this by presenting  the options, trade offs and corresponding risks in clear terms that they can understand and appreciate.

Enough out of me..

Do your stakeholders understand the notion of technical debt? Have you ever used that term to describe it? What are some other analogies that you’ve found effective in making technical things seem not-so-technical?

Also, I touch only very lightly on the concept of technical debt. Please do go back and read these articles for the more deeply developed analogy, and some other interesting sidebars.

Additional Reading

Here are some of my bookmarks on technical debt that I’d highly encourage you to read if you’re interested in the concept and want to understand it in greater detail.

• Steve McConnell’s 10x Software Development - This is probably my favorite of the articles. McConnell goes quite a way in developing the debt metaphor, and even provides a taxonomy for technical debt. For this article, you really have to read the comments, where even Cunningham, himself, weights in to get the full benefit.
• The WyCash Portfolio Management System - This is Cunningham’s original article. Interestingly, it isn’t an article on “technical debt” per se. Scroll down to paragraph 5 for the bit on technical debt.
• Developer Debt at Follow Steph also provides a lot more meat to the debt analogy, including a graphic that illustrates that how incurring developer debt can lead to a point where “nothing can done in any reasonable time or method.” Again, the comments are well worth a few minutes to skim.
• On Technical Debt - Revisiting the Technical Mortgage - Really develops the analogy of technical debt as a “mortgage” of sorts.
• Martin Fowler on Technical Debt is a brief, but worthwhile read on technical debt.
  

Share

Copyright Practical Analyst, 2009. View the original post or comment on

Accounting for Technical Debt

There have been some really interesting articles in recent days and weeks that have been comparing use cases and user stories, and highlighting the advantages of each.  I’ve cherry-picked some of the best from my collection of bookmarks to share with you here. Hope you enjoy!

• Scott Sehlhorst provides some guidance on finding the best fit for capturing user requirements by comparing user stories and the various forms of use cases. He includes some helpful graphics to illustrate his points.

• Martin Fowler replies to the question, “What is the difference between use cases and XP’s stories?“

• Mike Cohn wrote an excellent article on the advantages of using user stories for requirements for which I did a brief synopsis a while back that can be found here. In a separate article, Cohn also provides a useful format for capturing user stories.

• Use case guru Alistair Cockburn compares use cases and user stories, explains some of the difficulties that can arise from giving up use cases for user stories, and gives 5 reasons why he still uses use cases.

• Agile UX points out “14 major differences” between use cases and user stories.

• ExtremeProgramming.org also has a nice primer on what user stories are, and contrasts them to traditional requirements.

• In The Agile Engineer’s opinion, “user stories are fine for functional requirements, but they are completely useless for quality requirements (aka non-functional requirements).

I’ve said before that we use use cases in my shop, but I’ve found that even though we don’t operate in a SCRUM or XP environment,  using Cohn’s format for documenting user stories is a quick and useful first step in identifying and later documenting use cases.

Regardless of what method you use, it is good to be familiar with the available options and their relative strengths and weaknesses.

Do you know of any other, similar articles? If so, please share.

Copyright Practical Analyst, 2009. View the original post or comment on

Use Cases or User Stories? Read Up!

I’ve received some very interesting feedback in the comments section and via e-mail to my recent article where I questioned how the legislative process might benefit by applying principles of business analysis. As a specific example, I used the recently passed economic stimulus package.

Today, I’d like to bring your attention to a similar article I found that is written from a project management perspective. The author is none other than Gregory Balestrero, CEO of the PMI. As you might expect, his emphasis is more on making sure that the initiatives included in the package are rolled out as quickly and effectively as possible. Per Balestrero:

First, get the people who know how to manage complex change initiatives — these are not career politicians but are experienced project professionals — who can manage change portfolios… that can get results.

Second, emphasize the competency of project management …, like they have begun to do in many of the governments around the world. But they should not allow “pockets” of excellence to prevail. On the contrary, the governments should leverage the pockets of excellence to develop an enterprise discipline in project execution.

I’d encourage you to read the article through, but don’t stop there. The comments, to me,  are every bit as  interesting and informative.

Of course, reasonable people can (and do) disagree as to whether the stimulus legislation - or any other legislation - is the right thing to, but in these articles, that isn’t the point.

The interesting thing to me is the discussion on the portability of project-related skills and how other sectors such as government/legislative could benefit from better application of the principles and practices project professionals such as analysts and PMs use daily to solve business problems.

“Gantt” photo by videoaktiv.

Copyright Practical Analyst, 2009. View the original post or comment on

Economic Stimulus, Meet Project Manager

This post is spurred by a few articles I’ve read recently which have only served to reinforce some similar thoughts I’ve been having for a while now on the constant, competitively toned comparisons between agile and traditional development methodologies.

As I read article after article extolling the wonders of these new methodologies against the weaknesses of the traditional methods, I begin to wonder if the emphasis isn’t too much on agile methodologies over agile principles.

One of my favorite quotes on “agile” is from Alistair Cockburn’s Agile Software Development. He states,

The question for using agile methodologies is not to ask, “Can an agile methodology be used in this situation” but “How can we remain agile in this situation?” A 40-person team won’t be as agile as a six person collocated team. However, each can maximize its use of the agile methodology principles, and run as light and fast as they can creatively make their circumstances allow.

Just as a recent example, take the article Agile and waterfall neck and neck as business side fails to engage. In it we read that agile isn’t being adopted more widely because business executives aren’t involved enough in the process. A couple paragraphs later, we read employing agile methodologies requires a higher skill-set and smarter people.

Of course, I read that and think “what methodology wouldn’t be successful with more business involvement and higher-skilled workers?” Sure, in many cases, the business stakeholders just aren’t invested enough in the success of a project once they’ve sent their order to the kitchen. But by the same token, I’ve known many a business stakeholder that wishes s/he could spend more time on the project and would were it for the fact that proximity, other responsibilities, or any other number of perfectly understandable obstacles keep that business owner from ever being able to reasonably participate in a “daily scrum meeting”

What about the rest of us?

What to do for companies with large, distributed development groups with business stakeholders that, for whatever reason can’t be as engaged as is called for in some of the agile methodologies? What about in the case of companies with workers that aren’t sufficiently skilled or “smart enough” to do all of the tricks required of an agile methodology?

I realize that software is business; people want to sell books, trainers want to sell training on the hot new tools and methods, and consultants are always going want to sell their clients the next big thing, but I think that there is quite a bit of value in just understanding the high-level principles of agile, such as those stated in the manifesto, and looking for opportunities to apply them in sensible ways in your current environment, whatever it may be.

Transformational change might not be affordable or even practical given the current economic environment. I think that the first, and perhaps most productive question we can ask of ourselves is not “what methodology should we use so we can benefit from agile principles?” but, “how can we apply agile principles to what we do today to make it more efficient/effective?

To expand on Cockburn’s notion of applying agile principles, here are a few of my thoughts/hypothetical questions that can be applied to making any methodology more agile:

Individuals and interactions over processes and tools

• If meeting with the business on a daily basis isn’t feasible, then what is? Let’s make arrangements to do what is feasible.
• How can we get better at communicating with business owners throughout the course of the project?
• How can we help the business understand the importance of  regular, quality interaction and its importance to the success of the project?
• Let’s examine the value stream of our current processes so we can understand what components add value, and which do not. Then, let’s focus on the parts that add value, and cut down or eliminate the aspects that don’t. Any process that has been around for a while has some administrative baggage that can be cut loose. Trust me.

Working software over comprehensive documentation

• Are there ways we can focus less on big-thick-documents and the litany of “system shalls”  without fundamentally changing how we requirements?
• As business analysts, how can we make more effective use of requirements modeling and definition tools and good practices to better serve our downstream customers?
• How can we be more iterative and incremental and still complete our deliverables and meet traditional project milestones?
• How can we make sure that someone is waiting on and needs the documentation we produce, and not just produce it to complete a task on a Gantt chart?

Customer collaboration over contract negotiation

• Can we remove the notion of “throwing deliverables over the wall” that inevitably leads to the analysis-paralysis that so weighs down traditional waterfall methodologies? How can we do things in a more incremental and iterative way?
• How can we foster a “team” environment where all members - business owner, user, analyst, designer, architect, develop, QA - are vested in and have a sense of ownership regarding the success of each project aspect or phase?

Responding to change over following a plan

• How can we get better at accepting and embracing that we don’t, and probably can’t know everything up front?
• Once we’ve done that, how can we get better at incorporating change into our current processes?

I do have just one other comment on agile methodologies with regard to “following a plan” point of the agile manifesto. It seems as some of the methodologies are becoming more mainstream they are becoming more formalized and standard, which, in the end, could make them just as rigid as the traditional methodologies. Take this quote from the above mentioned article:

If you do it all — do every step of the agile process — it works well and is balanced. If you cherry-pick and only do things that makes sense to you and your business execs, the value drops off rapidly. You’ve got to have smarter people to do agile, people who can take the broader view.

Doesn’t that sound suspiciously like “following a plan?” It will be interesting as more companies climb aboard the agile express to watch if/how divisions arise between the agile purists and those that end up using scrum, XP, TDD as just another formal methodology with all the formal boxes to be checked, etc. In other words, how long will “agile” remain agile?

Now that I’ve said all that…

I don’t want to come off sounding like I have anything against the agile methodologies. I absolutely do not. As a business analyst in the 21st century, I think it is beneficial to understand the positives and negatives of all the various ways of delivering software. I think that these methodologies have arisen because the software engineering market had a need that demanded them. They fill a very important niche and help address some problems that have been around for a very long time.

I’ve know that I’ve learned a great deal in my readings and discussions about the various agile methodologies, and, although I’ve never used them formally, I’ve seen my team employ agile principles in order to become “more agile” even though our we operate in more of a spiral model environment.

What are your thoughts on the distinction between agile methodologies and agile principles? I’d be especially interested to hear of ways that you may have made your traditional methodology more agile. How agile do you think a more traditional methodology can reasonably be?

Other articles that may be of interest

Below are a few articles on agile adoption and comparison with other methods written by others that I’ve bookmarked. That’s not to say that I agree with all of the points being expressed, but I did find each article of interest and thought a some of you might also. Oh - one or two of these links might require registration.

• Principles behind the Agile Manifesto
• How agile development affects role of business analyst
• Agile Business Analysis: Interview with Scott Ambler
• When Is Agile Development Not So Agile?
• Why Newton was agile and the Titanic was not
• When should I use agile methods on my software project?
• Agile Risks
• Has Agile Peaked?

Copyright Practical Analyst, 2009. View the original post or comment on

Agile and Traditional Methodologies Compared…. Again

Before you tune out, don’t worry, while “politically motivated” this is NOT going to be a post on politics, but on process and procedure - business analysis, if you will. That said, as an American, it’s been hard to tune out talk of the recently passed “economic stimulus” package, wherein we’ve apparently discovered that by having government spend a number of dollars with enough zeroes behind it, we can get our struggling economy back on track.

Anyway, last week I caught myself evaluating the whole situation from a business analyst’s perspective and began to wonder how I would try to handle the mess if it were my project and I were the BA. I began to think through some of the questions I might ask and how following fundamental principles of business analysis might improve matters.

When it gets down to it, how do we know that all the programs and spending have accomplished or are going to accomplish what we want them to? And not just for this bill, but for all of the mega-billion dollar proposals? And not just for this administration, but for every administration past, present and future?

Ok, I know I’m sounding like a skeptic, here, but don’t blame me - it’s my job. An important part of what I do as a business analyst is to make sure that resources are spent to the best benefit of the customer. This post is a summary of my musings from a quick, 10-minute-or-so brainstorm I did the other day on the topic.

Clearly Defined Problems:

How might outcomes be different if we made sure that legislation had clearly articulated problem statements so all could  be clear as to what specific points of pain each “project” intended to address? Sorry, but as a business analyst, I’m going to have to tell you that “the economy is messed up” is just wayyy too vague a problem.

SMART Objectives:

How might things be different if we had a clear definition of how success would be defined and how we’d measure it? If we limited scope to a few prioritized, SMART (Specific, Measurable, Attainable, Realistic and Timely/Testable) objectives? Sorry, but once again, “fixing the economy” is way to vague an objective.

Traceability:

How much easier would it be to determine what “works” and what doesn’t if every program/line item (read: dollar) had to be traceable back to one of these clearly defined objectives? How much easier would it be to identify which resources (funds, in large part) were actually allocated to their intended purposes as opposed to getting lost in the bureaucracy?

An Agile Government?:

So, the stimulus package was a massive BTD (Big, Thick Document) measuring in at nearly 1100 pages, and “stakeholders” had less than a day to review the final draft.  Kind of sounds like the requirements review schedule from a  project destined for mediocrity at best, huh? What are the odds of us moving to a more iterative and incremental methodology for getting legislation through the pipeline? How successful could it realistically be if we did?

You know, something like “working legislation over comprehensive documentation,” or “constituent collaboration over contract negotiation.” I’m not a legislator or a government expert but is it necessary that every bill be so long, complex and convoluted that the end-user of government services (that’s us) doesn’t even bother trying to read or understand them? Give me some user stories!

What else?

So, there are a few of my thoughts. I’ve never really done the “open thread” thing, but I would be very interested in your thoughts as project people and business analysts. How could principles of business analysts be applied to government procedures to make them more effective/efficient?

Also, am I the only one that looks at non-job related things like the legislative process and thinks, “Wow, they could use a good BA!”?

One reason I enjoy being a business analyst is that the principles and skills are so portable. Root cause analysis, defining SMART objectives, tracing solutions (and dollars) to objectives, finding the most effective ways to communicate ideas and many other things BA’s do daily with our project work are just as applicable in solving other types of problems.

What are some ways that you’ve either applied, or seen principles of business analysis applied effectively outside the IT project environment?

Copyright Practical Analyst, 2009. View the original post or comment on

Economic Stimulus, Meet Business Analyst

Life Lessons Flowchart image by nbrier

Craig Brown, who runs the fabulous project management/business analysis blog Better Projects made a call for participation to various bloggers in that niche to list the first and last analysis models we’ve used at work. Being the good sport that I am, here’s my reply.

The First

The first analysis model I can remember using was a basic swimlane process diagram. I used that quite a bit starting out as it is a) simple to pick up and use, and b) a picture is worth a thousand words and people just seem to “get” the simple flow diagrams. Mind, I purposely don’t call it an activity diagram, because, at the time, I don’t know all of the UML notation, but the simple MS Visio swimlane diagram is still one of my favorite tools, especially for illustrating simple busines flows to a non-technical audience.

The Latest

Just this past Friday, I spent some time on a couple types of analysis model diagrams.

The first was just your basic use case diagram. Yep, the one with the stick people pointing to their little goal bubbles. I’m going to take it to a meeting tomorrow afternoon with some business stakeholders and one of my design SME’s. It is more of a technology infrastructure project to optimize/automate some existing functions that still require a bit too much manual effort than a project for new functionality, so I am just trying to make sure that I’ve captured all the actors and functions that we think have a stake, or may be affected by the project.

Cockburn will tell you that in the early stages of use case modeling, we’re after “breadth before depth.” I’ve found that bringing the very basic draft diagram makes it easier to keep the players in the range of the level of detail I’m looking for at this early stage.

The second is a context diagram for a high-level business requirements document for a separate project (we call it a business requirements document, but for the Wiegers disciples out there, it equates to the vision and scope document).  This is a diagram I use early in analysis to understand which other systems and groups interact with the project’s core system.

In this case, the context diagram isn’t a detailed communication diagram but a simple visual to help the project team make sure that we’re involving the right folks in our detailed analysis activities.

So, there you have it. I’m sure Craig would be glad to have you participate in the meme by commenting on his original post, or you’re welcome to do it here. I’d be equally interested in your responses.

Share

Copyright Practical Analyst, 2009. View the original post or comment on

Analysis Model Meme

Here are some recently bookmarked items on business analysis and related topics that I thought I’d share.

• Understanding the root causes of poor software requirements from Nick Malik is pretty exhaustive list of symptoms and root causes for poor requirements. I think it’s a great start, and well worth evaluating in the context of one’s particular software engineering environment. I love posts like this where others share some valuable foundational work that they’ve done that can be beneficial to the community at large. (h/t Craig Brown)

• Laura’s sharing her presentation on reverse engineering testable requirements. Take a look and let her know what you think.

• David sees the “myth of changing requirements” as a matter of framing the requirements dialog.  He advises that requirements churn can be reduced by focusing on the details of business processes, or asking “what do you do, or plan to do in the future?” in lieu of “what do you want?”

• I look forward every week to Geri Schneider Winters’ “Businesses Analyst Tip of the Week.”  If you’re not getting it, then you’re really missing out. As examples of content, last week she summarized the different types of software engineering methodologies, and this week she tackles naming, managing, and versioning requirements if you don’t have a requirements management tool. Sign-up via the box in the top right corner of her blog.

• Apparently, wireframes are much more effective than interpretive dance. In this article, Alice Toth provides some practical tips and extols some of the benefits of wireframing.

• Here’s a nice, brief “How to..” on preparing a use case.

• Lastly, Icon Restore is a little freeware application I installed last week that allows you to save your desktop icon configuration and then restore it when it gets thrown out of whack. It’s been a life saver already. You’ll especially appreciate it if you use a Windows laptop and switch display types (stand lone, docked with a monitor, with a projector, etc.) on a regular basis.

Alright, that’s all for this week. Have you come across any “must-read” material for business analysts this past week? If so, please do share!

Share

Copyright Practical Analyst, 2009. View the original post or comment on

Recommended Reading (09-11)

Here are some more interesting reads from my business analysis bookmarks. If you’d like to hear about my bookmarks as I find them, you’re welcome to follow me on Twitter.

• INDEX for business analysis - Marcus Ting-A-Kee is maintaining a really useful and comprehensive index of  blog entries touching on skills for beginning BA’s, requirements fundamentals and other topics of interest for analysts of all levels. I just found it this morning and have already begun reading my way through the list.

• Read the UML Guy’s argument for Requirements Analysts, where we read “If we don’t know our requirements, we can’t have quality.”

• Marc Talbot @ Seilevel wrote an interesting post on recognizing and cataloging patterns in software requirements. Marc’s post has caused me to reflect on some similar work I’ve been doing that I’ll probably post on in the next week or two.

• Jama Software, creators of the Jama Contour requirements management tool, has issued a whitepaper providing “7 Essential Tips to Ensure Success with Requirements Management.” It’s worth a read and provides links to some free templates, including a prioritization matrix template that I thought was pretty good.

• The cranky product manager laments the “crazy, insulting, demeaning, and threatening lunatic fringe” of the agile community that is waging a religious war against “non-believers”. Wow.

Copyright Practical Analyst, 2009. View the original post or comment on

Business Analysis Digest (09-12)

Ok, now this is just for a little fun. During some time off a while back, I went to Project Gutenberg and downloaded The Adventures of Sherlock Holmes. I still haven’t read them all, but I was surprised to see the great detective speak out so strongly in favor of requirements in A Scandal in Bohemia.

It is a capital mistake to design and develop before one has the requirements. Insensibly one begins to twist business need to suit design preferences, instead of design preferences to suit business need.

Ok, so that’s not exactly what ole’ Sherlock really said. The actual quote is below.

It is a capital mistake to theorise before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.

The original quote actually stands well enough on its own in terms of practical software engineering advice. I just wanted to share the first one because, believe it or not, that is actually what I thought when I read that line. Wow! He could just as easily be talking about requirements before design, or understanding the problem before jumping to the solution! Yes, I’ve considered that deriving software engineering maxims from the dialog of fictional characters in my leisure reading may not be altogether normal.

But just so you know I’m not the only one that looks to apply business analysis to happenings outside the office (or vice versa, in this case), Terry over at the Requirements Defined blog posted an interesting article on how he, after some frustration in shopping for a car for his wife, decided to break down and elicit and prioritize her requirements for a vehicle. A few others (including myself) have commented on experiences we’ve had, or potential opportunities to use our project skills outside of the work-a-day world. Go have a look!

Share

Copyright Practical Analyst, 2009. View the original post or comment on

Sherlock Holmes on the Necessity of Requirements