Agile or non-agile BA?

When you consider it, if as a business analyst you focus on identifying and solving the real business problem, it doesn't matter whether you are working in an agile or non-agile environment.

Expansion of business analysis scope

The activities that absorb the attention of the business analyst seem to go in cycles. Sometimes the business analyst is involved with more technically oriented work and other times the business analyst is more strategically involved with business planning. Much of course depends on the events and circumstances of the times. Right now there seems to be a significant emphasis on security, especially business and information security and disaster recovery and business continuity.

Granted the experienced business analyst should be able to pick up any business area in a short amount of time applying his or her skills and abilities as communicators and analyzers which equate to fast learning. But the areas of business continuity, disaster recovery, and information security, even when not talking about the technical aspects, are not necessarily what might be considered business lines.

Perhaps there will be business analysts who specialize in the business aspects of disaster recovery and business continuity. Unfortunately these areas are not full-time long-term jobs because once the business continuance and disaster recovery plans are created they are turned over to the people who will test them and then in the unfortunate event that they may be needed, to execute them.

Business security should be a constant and ongoing concern of the business analyst, but seems to only draw the attention of the business in general and the business analyst in particular when there has already been a security breach. Prior to that most businesses, and unfortunately business analyst as well, seem to have either an “it won’t happen here” or “it’s somebody else’s job” attitude.  Each of us as business analyst has to be aware of the risks and potential for security breaches from all sorts of threats and attackers.

Business Analysis Predictions

I was talking to a group at a meeting the other day and they asked me what prediction I would make for business analysis over the next few years.  I have made predictions in the past, but cannot remember what they were or whether they came to pass. So take it for what it’s worth, here is what I said:

Executives will still look for the silver bullet and quick fix especially where people can be removed from the product development equation. At the same time analyzing the business (marketplace, product mix, competition, business structure, root cause analysis of business problems, business capabilities, business capacity, etc.)  will become increasingly important as a factor of business success. Business analysts will move away from IT and requirements orientation and take a more strategic position analyzing the business to uncover problems, weaknesses, vulnerabilities and opportunities which will then be passed to Agile teams to solve or implement. Business analysts who are requirements documenters only will find their jobs dwindling while those business analysts who focus on solving business problems will flourish.

The agile coaching contradiction

Agile teams are supposed to be self organizing. And yet when teams have trouble organizing, the common solution is to bring in an agile coach. But the agile coach is not on the team. If the agile coach provides the motivation or approach to organization, or organizes the team him or herself than the team did not self organize. If all teams, according to agile, are supposed to be able to self organize, what does it mean when a team can self organize? In the agile philosophy if a team does not self organize do you disband the team and try again? Or do you assume that that show this work?

Defining Goals

The business analyst is often associated with goal making, the definition of a goal. While the project manager is the role primarily responsible for the goal of the project, the business analyst is the one who defines the goal of the product, what does the organization intend for the product to do for it. Is the goal of a new product to increase revenue, stay competitive, move into new markets, complete a product line?

Clearly the goal associated with solving the particular business problem has a great effect on how the project is done and how success is determined.

To assist the organization in defining an achievable goal business analyst needs to understand what a goal is.

A goal according to the dictionary: "the result or achievement toward which effort is directed; aim; end."  Being the result, it must state something to be achieved. However, saying "our goal is greater safety for our workers (using Georgy's last item)" does not help us.  How high? Will one defect less than before be considered 'higher quality'? It satisfies the goal. 

So we need to apply a measure to the goal for it to have meaning: "Our goal is to have ten percent fewer worker injuries."  The goal now has more meaning in terms of achievability, but the results are still questionable. Ten percent fewer injuries over the next day? the next month? the next century? 

For the goal to be effective - and what is the purpose of stating a goal if we don't care whether it achieves the results? - we need a time frame for achievement. "Our goal is to have ten percent fewer worker injuries this fiscal year than last fiscal year." 

Three elements of a functional goal (functional means the results are achieved and not just stated): a statement of achievability, a measurement that prove it has been achieved, and a time frame by which it should be achieved. Then we can state the goal (what results we expect) and achieve those results - and most importantly for everyone, know that we have done so. 

Prototyping and the Busienss Analyst

A prototype is "the original or model on which something is based or formed" according to the dictionary.  Prototyping is the act of creating such a prototype.

There is no part of the definition that suggests prototypes are done a certain way.

Therefore storyboards can certainly be considered prototypes as can wire frames.  Each should be done iteratively with increasing layers of understanding and refinement between the person creating the prototype and the person for whom the prototype is being developed. Use cases can also be considered a prototype. Anything that allows others to see the picture that is in your mind of the final solution is a prototype.

I have come to the understanding of the term 'prototyping' as the iterative actions and interchanges between developer or business analyst and the business person to create the model on which the software for a system is based. As early as the 1970s working on minicomputers with businesses that were new to automation, we found it easier to mock up the interfaces and operations rather than try to explain the concepts. Prior to that we used paper prototypes to show users what their reports would look like when the system was completed. In those days there was no user interface to prototype.  

There are issues and concerns with dynamic prototyping which describes animated, usually computerized prototypes.  I have found the viewers of a dynamic prototype using low tech tools such as white board or flip chart are much more likely to request changes and are more willing to experiment until they find the metaphor that works for them than they are with the dynamic prototypes (such as iRise).  I think it’s a cognitive thing. Viewing anything on the computer has the imprimatur of being permanent and having taken a lot of work to create. The viewer, usually a user of the system being modified, is hesitant to suggest changes. When the same screen is shown on a piece of paper, the viewer will make all sorts of changes without concern. 

Yes, in some ways a Requirements Document might be considered a prototype, but the review sessions tend to be more wordsmithing than productive. The prototype concept would have you create prototypes, either static or dynamic, and keep iterating them until they fairly accurately represent what the final solution will be, and then document the prototype in the Requirements Document. 

Change leaders or Lead Change

Change could be led by current leaders who are inspired by new ideas (which may come from someone or something else) or who realize (or are shown) that the current direction or the existing state of things just is not right or is not working. 

I think it is somewhat disingenuous to assert that the situation can change but those who are leading the situation cannot. To suggest that change only comes through  revolution (replacing current leadership with new and different leaders) does not allow for the Eureka! moments or the "oh, my God, what have I done?" moments. We have plenty of evidence historically of leaders changing their politics, position, beliefs and so forth, and in many cases that is exactly what makes them leaders, as opposed to those who are intransigent or stubborn and go down with the ship instead of finding a new way to save it.

And there are plenty of examples of leadership changing, but nothing else does.