As business analysts, we’re trained to help business stakeholders prioritize projects and requirements within projects to help ensure that the right things are done in the right order to optimize the return on their investment. I think it’s important that we take our own advice when it comes to our analysis efforts and keep ROI (Return on Investment) at front of mind.

Assuming our raison d’être as BA’s is to help stakeholders reach a shared understanding of what is required for a successful product, what are the things we can do to create that understanding at the lowest cost in time and effort?

And I’m not suggesting we skimp or not take proper time to do the analysis, only that we be smart about it. One of the reasons traditional delivery methodologies get a bad rap is that they are so regimented and template/checklist-bound. Or, maybe it’s that analysts (and other project team members) interpret them as requiring the regimentation and checklists – but I digress.

In any case, you do have to do the analysis. You just have to be expert enough to understand what models and methods – among those available to you – give you the best return on your investment for a particular project and its accompanying set of circumstances.

A few examples:

• If we are producing a document that no one reads, the return is probably not worth the investment of time and effort.
• Further, if we are producing a document that everyone reads and approves, but that doesn’t contribute directly to helping get product out the door, not only is our time and effort wasted, but so is that of everyone who takes the time to review it.
• If we are spending extra time on paperwork just to make sure that every section of a document has at least “something” in it, the return is probably not worth the investment of time and effort.

There are just so many types of requirements, so many types of models, so many tools at an analyst’s disposal that one can easily get caught up in doing things to be doing them – as part of a process/template, because they worked well enough another time, or because “that’s what we’ve always done.”

When focusing on “the process” or “the checklist”, one can easily forget that the value we provide is not in producing documents, but in clearing the path that leads to stakeholder alignment through shared understanding.

There are lots of “good things” that we could do, that may be helpful to someone, somewhere, sometime. The trick is to learn to identify and focus on the “best things” – the things that will move this particular effort furthest forward with an acceptable level of risk for the time and effort invested.

I say “at an acceptable level of risk,” because analysis paralysis almost always results from well-intentioned project teams doing “good things” well past the point of diminishing returns in a futile attempt to entirely remove risk of the unknown from the equation.

Before diving right in and “doing,” I find that it’s a good idea to assess the available tools in my BA toolbox – by that, I mean the collection of documents, models, methods, tips and tricks – basically the things that I can contribute that could help sharpen that shared vision of product/project success for my stakeholders.

It isn’t practical to use them all for every project, so I have to decide which tools will get me the farthest toward that shared understanding at the smallest cost. Once I have a pretty good idea on how I think I can add value, I work with my project team members to make sure they understand and are comfortable with those tools/models/etc. Once the team is on board, off we go – readjusting as needed when circumstances change.

So, here are a few questions for your consideration. An answer of “yes” MAY indicate an opportunity for you to modify your activities to improve your allocation of time and effort to improve ROI.

• Are you doing tasks/work just to fill out a template, or a generic project plan?
• Do you use the very same modeling techniques, with no variance, for every project?
• Do you get the sense that your documents aren’t being fully read or used to drive downstream activity?
• Do your analysis efforts seem to take longer than you think they should?
• Does what you’re working on contribute directly to creating a shared vision among stakeholders of what is required for success on the given project/product?

So, when is the last time you considered the ROI for your analysis efforts? And what are you doing to improve it?

View the original post or comment on Business Analysts: Don’t Forget Your ROI!

Related posts:

1. Business Analysts: What Do We Want to Create?
2. Leadership Through Communication
3. Four Key Knowledge Areas for Business Analysts

I hope you’ll enjoy this guest post (our first ever, actually) by Rowan McCann of Bright Green Projects. - JB

Introduction

Back in the 90’s self-managed teams were all the rage but they had a high rate of failure mainly because team members lacked people skills.  These ideas of self-managed teams were borrowed by the Agile movement when in 2001 they formulated a ‘new’ way of working, based on Agile principles. These principles value individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.

For these ideas to work in practice Agile team members  must know something about teamwork and this means understanding a lot about human behavior and why people do the things they do!

Agile team members are usually composed of highly skilled knowledge workers with strong values of Independence. Some are worth more to an organization than the people who manage them!  Many software developers are quite introverted, preferring to interact with their computers rather than people.  My own IT degree course hardly spent any time on people skills and nothing on the even more difficult concept of what people need to do to ‘self-manage’ into a high-performing team.  I’ve had to learn this in the world of experience. I wonder how many readers find themselves in a similar position?

If you look at the Agile web space you’ll find that the emphasis is on ‘engineering best practice’ and tasks, rather than team processes.  Many project managers, too, are used to old-school leadership where they are more comfortable with control and the power that goes with it. So for Agile IT teams to become high-performing it’s essential that, right from day 1, time is spent in helping the team to initiate the process of adaptive learning and this requires a focus on behavioral skills.

Rather than let Agile Teams try to reach high-performance by trial and error it seems to me that the first thing to do is for everyone to understand the behavioral characteristics of their team members. For a business analyst to be effective in an Agile environment they must understand a lot about people and how best to interact and influence them. A good starting point is to learn about the nature of teamwork and the preferences people have to engage with some tasks and not others.

The Nature of Work

A starting point for Agile Teams is to understand the nature of the work that all teams need to focus on.   The Team Management Systems Types of Work Wheel identifies eight distinct ‘Types of Work’ that need to be undertaken by all teams, regardless of their industry.  We have found this concept invaluable when working in the area of Agile Project Management.

The eight work functions are listed below, with the approval of Team Management Systems.

If you want to get valuable feedback about your current or future Agile Team we’ve put up a free questionnaire on our website. You’ll get a free 8-page assessment of what you think about your team’s performance, based on these eight Types of Work, or work functions.

Team Management Systems Types of Work Wheel

	The Advising function is associated with the gathering of information from all stakeholders and responding quickly to changing requirements. It involves keeping up-to-date with developments inside and outside the organization and passing advice on to others to help them in their work. It requires a transparent flow of knowledge of ‘what’ is going on and ‘where’, and a focus on ‘consulting skills’ so that information can be gathered quickly, accurately and effectively. A good Requirements Management System enhances this work function.
	The Innovating function involves generating new ideas and new ways of doing things. This requires the development of creative problem-solving skills so that the team remains one step ahead of its competitors. To do this well requires original thought, imagination and innovative thinking.
	The Promoting function is concerned with the identification of opportunities and the ‘selling’ of these opportunities to others, both inside and outside the organization. It often involves the application of influencing skills and the making of presentations to others. It can also involve communicating the team or organizational ‘vision’. High visibility throughout the organization may also be required.
	The Developing function is associated with the turning of concepts into ‘reality’. Ideas are worked on to produce practical products and services. In many cases it may also involve developing workable and practical solutions when problems arise. Agile Teams need good analytical skills so that requirements can be quickly prioritized, enabling accurate estimates of iterations and burn down charts.
	The Organizing function involves organizing people and resources efficiently by setting clear goals and objectives and making team members accountable for their actions. It is also associated with the implementation of quick effective action when problems occur, so that the planned outputs are always capable of being achieved. In summary it’s the function that ensures that the work of the team is structured and focused towards common objectives.
	The Producing function focuses on outputs, ensuring that iterations are completed to high standards of effectiveness and efficiency. It’s the function associated with the regular delivery of releases and other services. It requires a systematic approach to work and an emphasis on the delivery of products on time.
	The Inspecting function requires an attention to detail and an emphasis on the monitoring of systems, contracts and outputs. It’s also associated with a focus on accuracy, ensuring that work outputs are always delivered to the right quality. This function is the classic control function where procedures are regularly monitored for their efficiency. It’s often a core feature of the iteration review process.
	The Maintaining function is a support function which ensures that proper standards of conduct and ethics are upheld and that quality is maintained. It’s also associated with supporting others in the team so that the team processes follow agreed ground rules. Personal conviction and loyalty are often important to this function as is an interest in helping others.

Work Preferences

For teams to be high-performing it’s essential that these eight Types of Work are done well. But Team Management Systems has discovered that rarely does anyone actually enjoy doing all of these functions.   People show distinct ‘work preferences’ for maybe just two or three of these activities.

Work Preferences are dimensions of individual differences in tendencies to show consistent patterns of relationships, thoughts, feelings and actions in the work environment. Work Preferences determine the conditions we all set up to allow our mental and psychic processes to flow freely.  Preferences are usually transparent and are often the first thing we notice in others – ‘He’s rather quiet, isn’t he?’ or ‘She never stops talking.’  Some people prefer to think things through on their own whereas others need to talk out loud to clarify their ideas. Preferences are readily visible to others and are usually the basis of first impressions.

When we are working to our preferences we set up conditions where our psychic energy can flow freely.  If we are more extroverted we like work where there are lots of interactions with others, both inside and outside the organization.  If we are more introverted, then we like conditions where we can work on our own with few interruptions and a minimal requirement for meetings. Under these conditions our energy can flow freely with minimal resistance.  Just as electrical energy generates heat when it meets resistance so our psychic energy generates tension and stress when it has to flow through areas that are not our preference.

I have a preference to work in the Advising and Innovating areas on the Types of Work Wheel and I don’t really enjoy Promoting or Organizing activities, so wherever possible I’ll spend time thinking about new ideas or finding out as much as I can about the project.

It seems that the ‘Law of the Four P’s’ applies here. We all tend to practice what we prefer; for example you might prefer to play golf rather than squash. Therefore at any opportunity you are more likely to be on the golf course rather than on the squash court. The more you practice golf the more likely you are to perform better at it and maybe even become perfect. So it is at work. We all tend to Practice what we Prefer and over time we become more Proficient in the areas of our preference. This in turn gives us Pleasure from our work.

What happens in an Agile Team is that there’s likely to be an imbalance when you look at the work preferences of all the team members.  If everyone is like me then there’ll be a tendency to give priority to making changes and incorporating the latest ideas.  Teams like this may have the weakness of never tracking their burn-down charts!

Other weaknesses occur if everyone enjoys just Organizing and Producing.  Your team may be well organized and on-target but is it really delivering what the stakeholders want or indeed need?

So, if your Agile Team is to be truly effective you must understand the work preferences of all team members and look at the preferences balance.  It will give you an immediate picture of strengths and weaknesses, as far as teamwork is concerned. Information like this helps ensure that everyone’s work preferences are matched to the critical demand of the job they have to do.  Where the match is high, our energy flows freely, we are more likely to enjoy our job, stress is lower and we feel happier at work.  But all eight work functions must receive the priority they need and never be relegated to lower importance.

Is it possible to identify a person’s work preferences? Fortunately the answer is ‘yes’. Many years of research by Team Management Systems has led them to a reliable and valid way of doing this.

The Types of Work Wheel is a model about essential team tasks but there is a strong relationship with work preferences. For example people with preferences for extroverted relationships and creative information gathering map most often into the Promoting area of the Types of Work Wheel whereas those with introverted relationship preferences and practical information gathering most often prefer Inspecting work. Those who like analytical decision-making and prefer to work in a structured way show a bias for Organizing work whereas those with beliefs decision-making and a more flexible approach to the way they organize themselves and others enjoy Advising work.

The Team Management Wheel

The integration of the Types of Work Wheel with the work preference concepts led to the development of the Team Management Wheel.

The TMS Team Management Wheel

A person’s work preferences can be mapped onto this Wheel as a major role preference and two related role preferences.  Thus someone might show a preference as a Creator-Innovator with related roles of Thruster-Organizer and Concluder-Producer, or as a Controller-Inspector with related roles of Concluder-Producer and Upholder-Maintainer.

Here are some general characteristics of each sector:

Using the Team Management Wheel to Improve Teamwork

There are many ways to use the Team Management Wheel to improve Agile Team performance. Some of these are highlighted below.

Self-understanding

Receiving detailed feedback on which team roles a person is likely to prefer helps them realize why they emphasize some team activities but ignore others.

Team balance

If all members of a team map unevenly around the Wheel it helps explain why some team activities are ignored.  After all, we tend to give priority to those tasks we like doing.  If there is a team imbalance then everyone knows that an extra effort needs to be made to make sure that less-liked team activities are done well.

Work allocation

Knowing what team roles someone prefers can help with the allocation of tasks.  For example, giving an Explorer-Promoter tasks with a high need for detail is probably an unwise move.  Asking Reporter-Advisers to work in a job that requires a ‘thrusting’ approach to organize projects and deliver results on time may cause them unnecessary stress.

Colored meetings

Many teams use the concept of the Team Management Wheel in planning meetings.  Green meetings focus on information and ideas.  Yellow meetings explore options and discuss relevant ‘promotions’.  Red meetings are all about planning for action and results.  Blue meetings are review meetings to go over the detail.  In this way adequate time can be assigned for four distinct but important features of teamwork.

Understanding others

Different roles on the Team Management Wheel see the world in different ways.  As a result, team members tend to make negative attributions about those on the other side of the Wheel.  Explorer-Promoters may see Controller-Inspectors as dull, boring, pedantic and detail oriented.  Controller-Inspectors in return may see Explorer-Promoters as loud-mouthed, waffling and with little substance.  It’s a natural human tendency to look negatively on those who are ‘different’.  However all roles are necessary to get the best from a team because, often, it is out of diversity that the best solutions arise.  Learning how to appreciate individual strengths can be achieved by use of the Team Management Wheel.

Linking

I haven’t mentioned Linking yet but it’s probably the most important idea on the Team Management Wheel and the subject of an article on its own. It’s an activity responsible for integrating and co-coordinating the work of the team. It’s not a preference but a set of important skills that applies individually to team members and collectively to the whole team. Ideal Agile Teams have a low level of leadership control and a high level of autonomy.  In these situations team effectiveness largely depends on six key skills of People Linking. These are the skills of Active Listening, Communication, Problem-solving and Counseling, Team Relationships, Participative Decision-Making and Interface Management.

For People Linking to be effective it’s important for all Agile Teams to establish a set of ground rules.  These are an agreed set of acceptable individual behaviors that define how team members will interact.  Usually they comprise 10-20 statements that are posted in the team meeting room or on the Agile Project Management Platform, agreed at the start of the project and reviewed after each iteration. If a team member is unhappy with a particular team process then it’s easy to open up a discussion just by referring to the relevant ground rule which everyone has already agreed to.  Conflict is often avoided by this simple process.

White meetings are Linking meetings, often referred to as the daily 5-minute stand-up meeting when teams are co-located. If you’re interested, I’ll talk about Linking in a future article. In the meantime try out the free Agile Team Performance Questionnaire.

Copyright © 2009 Bright Green Projects and Team Management Systems. All rights reserved.

Bright Green Projects is a cloud-based Agile Project Management Solution, developed by a team of Management Consultants with 10 years experience working internationally.  Take a look at http://brightgreenprojects.com/overview to watch a quick video.

View the original post or comment on Agile Teamwork – what BA’s need to know (Guest Post)

Related posts:

1. Choosing Between Agile and Classic Management Methods
2. Agile and Traditional Methodologies Compared…. Again
3. On Business Analysis in an Agile Setting

David Wright  is no stranger to many who participate in the various online business analysis-related forums and online communities. He’s been in the business for over 25 years and, during that time, has accumulated quite a bit of practical knowledge and insight.

Not long ago, he decided to put pen to paper and share some of that accumulated knowledge in Cascade; a guidebook using a framework of 13 principles  to describe “better practices for effective delivery of information systems in a multi-project environment“.

I’ve read and enjoyed the book myself, and thought it’d be interesting to get a little background on Cascade and the thought process behind it.

With that in mind,  I sent David a list of questions that you’ll find below along with his responses and a few of my own comments on the book.

Cascade is a pretty unique title. How did you come up with that?

It’s a play on Waterfall methodologies. I always thought Waterfall was a misnomer, because of the standard criticism of it being slow; I have been to Niagara Falls a few times, and it has never looked slow. A “cascade” is usually visualized as a small but very quick moving thing, and it just clicked with me when I was looking for a high-concept name for what I was writing about.

What motivated you to write Cascade? What are your goals and aspirations for it?

It was something I had to get out of my head and down on paper (or Word doc). I have been working in information systems long enough that I had a set of “rules of thumb” that helped me be successful while avoiding failures I have seen before. I was having a conversation one day with a friend about methodologies and manifestos and what they really accomplished, and it dawned on me that my own experiences and “rules” addressed the same topic. It took me about a half-hour to write out the first cut at what would become the practices in Cascade. After that, it was a matter of fleshing it out with examples and war stories. I guess it comes to that old adage of writing about what you know.

My goal now is to share Cascade with any and all who might find it of interest, and who might be helped by it. To be honest, I did not think about this much while I was writing it, I just needed to get it written. It is a vast marketplace of ideas out there, so achieving that goal is the challenge now; writing it was the easy part!

The book specifically addresses multi-project environments. What caused you to focus there?

It is the reality that most any IT shop faces, but when you want to find some methods to help deal with that reality, what you will find most in the market is methodologies that describe how to best deliver a single project. Most of the time in my career I would be working on several projects at the same time, reflecting the fact that the IT departments I worked in were always executing many projects at the same time. There was never the luxury of doing one project at a time, get it done, and then start another one. There are always too many demands on IT from all parts of the rest of the business to allow that. So constantly working in that environment lead to the experiences that drove out my rules and practices.

There are lots of good practices when it comes to IT delivery. Just curious, how did you whittle the number you addressed to the 13?

It was actually built up to thirteen. I started with  my initial draft list, and added a few more to address certain experiences, and it settled down at 13. Anything else I wrote after that fit into one of the thirteen. At this point, I like the number itself, at least for now. I am still working on projects every day, so I may have some more practices to add down the road.

Who would you say would benefit most from reading it?

I would like to think that almost anyone involved in multiple projects at a time could find some benefit, from project sponsors through to testers. I suppose the main audience is IT Managers who are responsible for a group of projects, or manage the people who work on many projects. Most of my actual work over the years has been in Business Analysis with some Project Management when needed, so that’s in there too. The idea of the separate practices is that you only need to read those that affect your work the most, then hopefully readers will take in the rest after that.

What about Cascade are you most proud of or has given you the most satisfaction?

As a Business Analyst, I have done a lot of writing over the years, but always for a project purpose: Project Charters, Business Cases, Requirements Documents, and so on. Cascade is something I wrote for myself, no methodology or templates or standards to drive what I wrote. So, seeing it done was a moment of pure pleasure of accomplishment. I had never pictured myself as an “author”, so to be one now is a good feeling, I highly recommend it to anyone who thinks they might have it in them.

My Thoughts?

First of all, I appreciate David taking the time to respond to my questions, and enjoyed reading the responses. I hope you did, too.

As I said above, I read Cascade and really enjoyed it. It was a quick, 100 page read with a light, familiar tone and a nice pace.

I wouldn’t say David has invented any new principles or coined any new buzzwords with Cascade, but he does provide some specific and sound advice on how familiar principles can be put to good use in a multi-project environment.

I think it’s a good resource and I do recommend it to business analysts particularly for the useful way it ties principles of business analysis in with architecture, project management and resource management principles.

Availability

Cascade is available at Amazon and other various online booksellers. If you’d like to get more acquainted with David, look him up on Twitter or check out his blog (which contains quite a few Cascade teasers if you look back through the archives).

Have you read Cascade? If so, what were your thoughts? What other recently-released books would you recommend as a good read for BA’s?

View the original post or comment on “Cascade”: Q&A with David Wright

No related posts.

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 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? 

View the original post or comment on Agile and Traditional Methodologies Compared…. Again

Related posts:

1. Agility vs. Bureacracy (and other thoughts)
2. Choosing Between Agile and Classic Management Methods
3. On Business Analysis in an Agile Setting

I came across a post by Meade Rubenstein this evening that I liked because it made me think a bit about methodology and how it evolves (or devolves) as it matures. We all want to get software out the door better, cheaper, and faster, right? And all the buzz lately seems to be around adopting agile methodologies.  Rubenstein’s opinion is that that agile methods, as is typical for “revolutions” in how things are done, will become more bureaucratic as they become the norm:

[L]ike all other revolutions (this one being one of process from traditional SDLC to Agile/XP) – the new becomes the norm and the norm become bureaucratic – making further drastic changes required. I’ve always seen Agile and XP initiatives as an attempt to deliver greater value by removing the imposed management overhead and miss-steps (such as thinking mediocre can replace exceptional with the right process in place) – and, unfortunately now that many Agile/XP practices/processes have become the norm, they are now the anchor.

I can appreciate the notion that with agile, even though there is less “imposed management overhead,” what overhead there is can certainly become rigid and regimented. That said, the balance of this post won’t be quite as much a structured reaction to Rubenstein’s post as it is just a couple of the thoughts that the article spurred and that I’d like to share.

Will “Agile” Remain Agile?

While agile methodologies have been, and will continue to be a quick and obvious win for some shops, I wonder how “pure” agile methodologies will remain over the long haul for more mature, heavy-footed companies trying to transition. It’s easy to imagine some agile-adopters – even among the most well-intentioned – gradually shifting back to old ways by adding “just a few” new activities here and there that add marginal value, but that make the process of delivering good software more cumbersome. It will be hard in some shops to overcome the notion  that the best way to avert risk is to produce more documents. Sure, that’s going to happen. And they’ll still call it agile.

Will Agile Become the Norm?

We’ll also probably find that in some environments, XP (or whatever other flavor of agile methodology) just isn’t the best fit. I won’t deny that we’re in the midst of an what seems to be an agile revolution, but what I’m less sure of is that methodologies like XP/Scrum will ever be the “norm” to the degree that traditional waterfall/spiral methods were for so long. I thinkXP, Scrum, and other agile methodologies are providing us with alternatives that we can all learn from, and that work great in some places, while heavier methodologies are still better suited to others.

The Agile “Discussion” Benefits Us All

What I’ve enjoyed most about this whole “agile movement” is that it is causing all of us – even those of us that use more traditional methodologies – to discuss agile principles and look at ways to make our processes leaner and more efficient.

I think Alistair Cockburn summed it up well in his book, Agile Software Development:

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.

I’ve been very interested in the whole agile/traditional methodology discussion that’s been going on from the blogosphere to the break room (especially as it pertains to the role of the business analyst). What do you think?

Bureaucracy – Magritte photo by Oddstock.

View the original post or comment on Agility vs. Bureacracy (and other thoughts)

Related posts:

1. Agile and Traditional Methodologies Compared…. Again
2. Sharing the Love – 2007-04-01
3. Passing Thoughts on Business Analysis & Requirements

While skimming the book, Lean Software Development: An Agile Toolkit, I came across a passage that has been on my mind for a few days that I’d like to share.

Many software development processes require paperwork for customer sign-off, or to provide traceability, or to get approval for a change. Does your customer really find this makes the product more valuable to them? Just because paperwork is a required deliverable does not mean that it adds value.

A good test of the value of paperwork is to see if there is someone waiting for what is being produced. If an analyst fills out templates, makes tables, or writes use cases that others are eager to use—for coding, testing, and writing training manuals—then these probably add value. Even so, there should be a constant search for the most efficient, effective means to transmit the information.

Lean Software Development: An Agile Toolkit, Mary Poppendieck & Tom Poppendieck, Addison Wesley, 2003

While the book was written in advocacy of agile methods of software development (one of the tenets of the Agile Manifesto is the emphasis on “working software over comprehensive documentation”), I think these ideas also ring true – and perhaps especially so – for “heavier” methodologies.

Now, I’m not knocking documentation in general. There is great value in a spec that represents meaningful, collaborative dialog through which key decisions are made and that expresses stakeholder need in a way that is intuitive to designers, developers and testers. Depending on the company or the industry, there may also be compelling reasons (level of criticality, government regulation, etc.) to produce detailed documentation that, in order to not get too far off-topic, I may address in a later post.

My point is that sometimes we (and I’m talking about myself first and foremost)  get so caught up in doing things just because they’re part of “the process” that we neglect to seriously question whether our time might not be better spent on activities that are more likely to hasten the delivery of good software.

The bottom line is that regardless of the process for getting software done, there is no value in paperwork that no one needs and no one cares to read.

Here’s a challenge: Take a look your current delivery model. Does it include documents or regularly performed activities upon which no one is really dependent? Would eliminating them free up resources for value-add activities that might potentially shorten the delivery cycle? If so, how do you go about amending your model?

As always, I’ll be interested to hear your thoughts.

View the original post or comment on Does Your Paperwork Add Value?

Related posts:

1. Documentation is No Substitute for Interaction
2. Agility vs. Bureacracy (and other thoughts)
3. Agile and Traditional Methodologies Compared…. Again

As I was skimming the book Agile Project Management—How to Succeed in the Face of Changing Project Requirements by Gary Chin, I came across an interesting method for determining whether to use classic or agile management methods.

According to Chin, the determination is made by evaluating project environments and organizational stakeholders.

Project Types

For “Operational Project” environments, or “projects that are run with a regular frequency, are very similar to each other, and are critical to the day-to-day running of the business,” he tends to favor classic management methods.

For projects focusing on the development of new technology he favors agile methods. To clarify what he means by this type of project, he states:

I am not talking about a new product or application, but rather the development of breakthrough technology, upon which future products will be built… Technology development projects are very unique in nature. There is no template project teams can work from and, in fact, a project management template, or any template for that matter, may greatly restrict the team creativity required to create such a new technology platform.

For product or process development projects, which require more business and less technical expertise, he doesn’t see as clear break toward either, but potentially a blend of the two.

Organizational/Stakeholder Environment

Per Chin, the number and type of organizations and stakeholders involved in the project also influence the classic/agile balance. He indicates that classic project management is better suited for handling the complexities of intergroup coordination and accountability necessary in projects with several external stakeholders, stating “[w]hile it is not impossible to create a successful agile environment across multiple organizations, it will be significantly more challenging.”

He favors agile management most in projects under a single organizational or corporate umbrella, and states that this is the environment “where most technology projects that can benefit from agile PM reside, and thus, it is an area with a strong potential return.”

This array of project types and organizational environments combine to provide a matrix resembling the one below that can aid in deciding on the appropriate method of project management.

(Table adapted from figure 2-7 of Agile Project Management—How to Succeed in the Face of Changing Project Requirements by Gary Chin)

Conclusions

Obviously, there are holes to be poked in any simplified method of making complex decisions, and Chin acknowledges that, “[d]eciding to employ agile PM is not a simple, black-and-white question.”

For all its simplicity, I did find the agile/classic matrix to make quite a bit of sense. At the very least, the approach Chin used provides some useful insights that can help in deciding which management method best suits your situation.

If you get the chance, pick up the book. Chin provides much more detail on the topic in his book than I have in this simple summary. He includes several other factors that may influence the classic/agile question, and tackles numerous other agile project management topics.

So, what are your thoughts? Would you agree on the factors used? How would your decision matrix differ from Chin’s? As always, I’ll look forward to your input.

View the original post or comment on Choosing Between Agile and Classic Management Methods

Related posts:

1. Agile and Traditional Methodologies Compared…. Again
2. On Business Analysis in an Agile Setting
3. Agility vs. Bureacracy (and other thoughts)

I must admit that I am not as knowledgeable as I’d like to be when it comes to some of the agile methods. To remedy this, I’ve been doing some research to learn more about user stores and to determine how they are different from use cases and from traditional requirements.

Here are some of my recent findings of interest that I wanted to share in case others of you may be in the same boat.

Martin Fowler specifically addresses the question, “What is the difference between UseCases and XP’s stories?“:

Use cases organize requirements to form a narrative of how users relate to and use a system. Hence they focus on user goals and how interacting with a system satisfies the goals. XP stories… break requirements into chunks for planning purposes. Stories are explicitly broken down until they can be estimated as part of XP’s release planning process. Because these uses of requirements are different, heuristics for good use cases and stories will differ.

Mike Cohn, whom I’ve cited before on the topic of user stories, provides insight on a format for articulating user stories that he has found to work well.

I advocate writing user stories in the form of “As a <type of user>, I want <some goal> so that <some reason>.”

For example, “As a corporate finance user, I want to know yearly how much in taxes are due to the state treasury so that the company can comply with state tax regulations (and avoid penalties for non-compliance).”

I think this format could be just as beneficial in a non-XP environment as a mechanism for requirements elicitation. In fact, I’m going to use the spreadsheet form of which he provides a sample for use in one of my new projects. I plan to ask my stakeholders to put themselves in the place of the user (in at least one case, the stakeholder will actually be one of the users) and let them state, from a first-person perspective, what they need to be able to do, and the value of being able to do it.

Too often as I’ve written traditional SRS documents I’ve either been asked or wondered to myself what was the value of a given requirement or set of requirements. With this format, we’d include a statement of business value with each user requirement. Good stuff.

For your reference, and contrasts them with traditional requirements.

In summary, here is what I’ve gathered so far based from my readings on user stories (much of this is derived from ExtremeProgramming.org’s useful description of user stories) :

1. User stories are primarily used to estimate development time, as opposed to use cases which focus on how users (actors) interact with a system.
2. User stories focus on user needs and are technology/implementation detail agnostic.
3. User stories become acceptance test scenarios.
4. User stories are typically written on cards and not diagrammed using the UML as are use cases.
5. User stories are an alternative to the traditional SRS document full of “shalls”. When it comes to detailed functional, system and quality requirements, those are worked out between developers and the customer.
6. User stories are most often identified with the XP (extreme programming) approach to release planning and development, which is a form of agile development.

I am a student as much as a practitioner of requirements analysis, and am always open to new information in tips. If you have any additional information or personal feedback on user stories or extreme programming or other agile methods, then please share. I’m always interested in learning more.

View the original post or comment on More on User Stories

Related posts:

1. Use Cases or User Stories? Read Up!
2. What are user stories, and why should I use them?
3. “Party of Four” Key Considerations in Product Development

Matt Lockhart of Magenic Technologies, Inc. posted an excellent article at TechLinks a while back on things that need to be considered when determining whether development work should be done on or offshore.

Among others, Lockhart draws attention to topics such as budget, relationship management, onsite travel, CMM considerations, the risks of miscommunication, and economic and political risks that need to be carefully weighed out before deciding to go offshore.

The way I see it, offshore outsourcing of IT work – chiefly development and QA – is not going away. Those of us stateside will have to learn to adapt and thrive in this new type of environment in order to remain marketable. For many of us, retooling may be necessary.

From a business analyst’s perspective, I’m not so naive as to think that my role couldn’t possibly be performed overseas, but I don’t think that the role of the onshore BA is going away anytime soon. I’ve alluded elsewhere on this blog to the notion that the business analyst role can be at least as much a business role as an IT role. Until companies start farming out their marketing, finance and operations to offshore MBA’s – and I don’t see that happening anytime soon – then there should remain plenty of work for the BA in helping define business problems and objectives and refining business processes.

Anyway, if you’re interested at all in the dynamics and trade-offs involved in offshore vs. onshore development arrangements, I think you’ll find this read well worth your while.

View the original post or comment on Onshore vs. Offshore

Related posts:

1. Agility vs. Bureacracy (and other thoughts)
2. Agile and Traditional Methodologies Compared…. Again

Ok, time for something light. This is funny stuff. Forget the phases or iterations – THIS is how the development lifecycle really plays out… Right?

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
4. Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
5. Repeat three times steps 3 and 4.
6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
7. Users find 137 new bugs.
8. Original programmer, having cashed his royalty check, is nowhere to be found.
9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
13. Programmer produces code he believes is bug-free…

Let me know whether this made you laugh or want to cry.. I think I’ve seen it from both sides!

This and other project management related jokes and truisms are available from Visitor Tracking.

View the original post or comment on The REAL Development Lifecycle?

Related posts:

1. “Party of Four” Key Considerations in Product Development
2. New Tools – and Their Implications
3. Sharing the Love – 2007-04-01