Business analyst in agile Software development 3: Product Owner

Perhaps the most obvious role for the business analyst to assume when presented  with the options afforded by the typical agile software development implementation is that of Product owner. 

The characteristics seem similar and the experience the business analyst has in defining requirements and solutions seem to play well in the product owner arena. The product owner defines a set of specifications for the project that are rendered as ‘user stories’ and posted in a priority order on the product backlog. This seems right up the business analyst’s alley.  The business analyst must work with all the product stakeholders to define a set of specifications that solve the business problem and render it in the form of requirements.

The product owner meets with the solution team regularly to go over the product backlog to elaborate and explain the details of the stories so the developers can write the code to implement them. The business analyst meets regularly with the solution team to review and explain the requirements and changes that develop during implementation.

There is a lot of similarity between the business analyst and the product owner. Where the similarity ends is where the problems begin.  The product owner has complete authority over the ultimate product and by reference over what the team does and the order in which the team does it. And the product owner has total authority for acceptance of whatever the solution team delivers.  The business analyst by definition has no authority.  If you have been a business analyst for any length of time, assuming that authoritarian position from one who works strictly with influence might be quite a hurdle to overcome.  Additionally, despite the apparently parallel requirements definition tasks, the product owner does not spend time collecting and analyzing information to produce the requirements. In this regard, the product owner is more like a project manager than a business analyst and Ken Schwaber, author of Scrum, warns against the business analyst moving to product owner for just that reason: the business analyst may revert to performing as a business analyst and not as a product owner.  However, if you can make that transition, becoming the product owner is a good step for a business analyst in an agile world.  If not, I have some more suggestions coming up.

The business analyst in agile software development, part 2: What is your value??

Let’s talk about where the somewhat negative attitude toward business analysts in the agile community comes from. Please note that the attitude is changing for the better, and we’ll talk about that later.

The knock on business analysts is because of the observed behavior of business analysts who perceive their role as one of ‘collecting requirements’ from the stakeholders. As such they facilitate a meeting and ask the stakeholders in the meeting what they want. The stakeholders respond, and the business analyst writes the requests down as dictated, rewrites the requests into the formal organization-defined business requirements document, get it approved, and pass it on to the developers. The developers, seeing this, wonder why they can’t simply ask the stakeholders the same question, get the same set of requirements, and start working on them without the interim steps.

As hopefully can be seen, the problem is that the business analyst in the scenario does not really add any value to the transaction between the stakeholder and the developer. Perhaps the business analyst might point out that he or she provided translator services by translating business-speak into tech-speak.  The agile developers say that they can just as easily ask for an explanation of any terms or jargon they do not understand, and there will be less chance that of mistranslation. Again, the question is what value is added?

As a business analyst, in general, not just in terms of agile, we have to know what our value is to the organization, and also to all the parties. What is our value to the stakeholder? What is our value to the solution team?  This is not an insignificant question.  Many business analysts assume that just because they are a business analyst and they are assigned to a project everyone will understand the value they bring.  After all, no one questions the value a Java developer brings to the project.  Remember, though, that the profession of business analyst is very new and as a profession we are still struggling to define our place in the scheme of things.  So if we cannot come up with a universal definition of what a business analyst does (other than practice business analysis) how can we expect that everyone else will share a common definition? 

Even a Java developer has different value on different projects and perhaps even at different times during a project. While the senior line manager is defining the business case, the Java developer may have limited value, for example.  If the primary bulk of the code is being written in C#, the Java developer has less value than the C# developer.  And so forth. 

The issue is, what is your value to the organization?  Can you state it in unequivocal terms?  Can you state it so the organization management not only understands but agrees if you were called upon to do so?

Can you state the value you are adding to the project?  Can you state it in such a way as to gain accordance from the team and stakeholders involved with the project?  Can you defend your value statement if someone does not agree (as in the statement of “I add value by translating terminology” above). 

Once you can define the value you add to the project and to the developers then you will be in a position that any software development approach, even agile, cannot unseat you because they cannot replace your value with anyone but you (or some other equally qualified business analyst). And you don’t have to worry about being booted off the agile island.

I will give you some time to think about your answer and provide a few suggestions later. In the meantime, in the next installment I will address the issue of it being too late. When the die is already cast and the business analyst role is already removed from the software development process, what do you do?  Where do you go?  Answers next.

The Business Analyst in Agile Software Development Part 1

I am getting a lot of questions and concerns from business analysts about how business analysts fit into the agile world that appears to be taking over software development, and just about every other thing.  My local grocery store has a sign that says “agile grocery shopping”. I’m not sure exactly what that means. I’ve been afraid to go in and try it.

Because of the interest and uncertainty, I thought I’d do a few blogs on agile and the business analyst, looking at the issue from a variety of different perspectives, both good and bad.

Here is the bottom line according to the agile zealots:  there is no business analyst in agile.  Wow!  Is that harsh! 

I have had many long conversations over the years with agile adherents such as Ron Jeffries, Scott Ambler, and Steve Gordon among others about the subject of business analysts in agile software development and the message was always clear: there is no need of business analysts in agile software development. Why? Because the theory is that the developers will talk directly to the customer, in the form of a product owner or a customer on-site, and need no intermediaries.  To the ardent agilists, a business analyst is just an impediment who offers no value to the transaction. Why would a developer need someone to translate what the business is saying when the developer can talk directly to the business person and not run the risk of miscommunication?

This is not really meant to be a pejorative condemnation of business analysts by these stalwart gurus, although many developers do not have a positive view of the role of business analyst which I will address in my next blog. 

The issue is what does a business analyst do when faced with the situation of the developers and others suggesting that their value to the software development effort is negligible and their services as business analyst are no longer needed?  I have four possible solutions and a bit of positive news in the forthcoming blogs.

Are you qualified to do business analysis?

In a recent discussion I was asked if there are a set of competencies, other than a certification, that could define a business analyst. Is there a list of characteristics that will indicate whether a person will make a good business analyst or not? Here is the paraphrase of my answer: For one thing, many of the competencies, such as ability to communicate in both written and verbal formats, do not have finite measurements. Some people communicate better than others and some communicate well in writing, but not verbally. All might be good business analysts, and all might not. I think a list of competencies (abilities, traits, talents, etc.) that a person typically needs to possess to be successful at business analysis would provide a good guideline for all those interested in performing as a business analyst. If a person is honest about their own competencies - where they are above average in performance and where their ability or knowledge is lacking - the person can seek improvement in that area. And that is a good thing. In the end, if you took the winner of the Nobel Prize in Business Analysis and sat them next to an average workaday business analyst, you might not be able to distinguish between them based on a competency list. In fact, the Business Analyst of the Year may not be able to pinpoint what he or she does differently than the average business analyst. The competencies, such as communication, inquisitiveness, empathy, analytical abilities such as critical thinking, visualization, curiosity, system thinking, networking, influence skills, negotiation and mediation skills, and so forth, have become so habitual and part of the prize-winning business analyst that he or she would not be able to describe them. The list of competencies should not be used to distinguish a person as a business analyst or to qualify a person's ability as a business analyst, but to provide a guideline for those in the profession and those who would join the profession as to what they have to work on, to hone, to improve, so that the competencies become inherent, habitual and automatic.

The business analyst and ITIL production requirements

I spend a few weeks in London in September and October capping a year long project that involved both analysts and production and operations managers. I had assumed over the years that the physical move into production was a project manager's responsibility. The PM was the one working with the production people to ensure a smooth transition into production, usually while the developers, business analysts, QA and users are completing the acceptance testing and getting final sign off of the product. In this particular company which follows ITIL it turns out that there are a number of standard procedures (which I helped initiate many years ago and are now refined into smoothly running processes) that are more business-related than project related. As we worked on various projects and processes I began to realize that the business analyst can actually do a lot during the project to make the transition easier for production. I talk a lot about the business analyst making the transition easier for the users, which does not go away, but there are also tasks the business analyst can do to ease the flow of the application into operations. It turns out that the overall business requirements do not only come from the users and business stakeholders. It is not enough to just make sure the problem is solved and the requirements are met. It’s not enough for a business analyst to ensure the described well enough for the developers to build. The business analyst also needs to work with the production people to make sure that the application moves smoothly into operations. There are requirements from production, for example ITIL standards to meet, that have to be defined as well. While these are not necessarily business requirements, they do affect the business in that they affect the ultimate delivery and use of the application in the operational environment. Since the business analyst is responsible for solving the business problem, the business analyst should be aware of requirements for that solution to go live. The guiding principle is always: if the users (customers, stakeholders) are not using the solution to solve the problem, the problem is still not solved.

Some thoughts on BA goals

I just received a series of questions from a number of different beginning business analysts. I thought it would be good to share some of their concerns and my responses to them. Feel free to send along your questions. I enjoy responding and helping out. One new business analyst / project manager is required by his company to establish goals for himself and his project and he sent along his goals to see what I thought of them. The first several related to the project itself and were more in the line of a series of goals that, when achieved, would get the project in a good standing. The last one stated: • Use critical thinking skills to gather information and negotiate with sponsoring unit This goal came from some previous correspondence in which I recommended enhancing his critical thinking capabilities to be more successful as a BA. (More on that in a future blog). Here is my response: "This statement is good and in alignment with general business analysis tenets and good practices. However, it states a continuing effort rather than something to be achieved. For example you might write the following goals: "1. Gather enough information from the sponsoring units to make good project decisions "2. Negotiate with sponsoring units (instead of automatically agreeing to specifications of time or resources) Now your plan to achieve these two goals might include "Ask at least three questions for each directive the sponsoring unit gives me. "Suggest at least one alternative approach or solution to each directive the sponsoring unit gives me. "This exercise forces you to think critically about all your interactions with the sponsoring unit. You may decide on a political basis not to actually voice the question or alternative solutions. However, even if you do the exercise on your own back in your office, you will be building your critical thinking powers so that the questions will begin to come naturally to you." It is not enough just to have goals. Once you establish the goals you need to devise a plan for achieving them. That plan could be a simple improvement or change in the way you are doing things that gets you closer to the goal as I suggested above. or it could be a step by step approach to achieving the goal. Either way, without a plan to achieve the goal, the goal sits like a target in a shooting gallery and you do not have a weapon.

Box checking

Box Checking Processes don’t have a good name, except with management. Management likes processes because they are easily controlled and managed. You can see the numbers. You can see where things are as opposed to where they should be. You know these things because there are reports that tell you. And many of these reports and activities have no other purpose than to provide management with the numbers and evidence that the process is working as defined. I had a job recently which required me to duplicate work in various ways. It was a contract and I was paid for my work, but it seemed terribly redundant and, well, silly, to keep putting the same information into different formats. When I asked my contact about the demands for the reports and numbers, he said he didn’t know why they were required. “Management needs them to check the box”. The implication of that statement, which for some reason of serendipity I have heard over again the past year, is terrifying. Management is not reading, assimilating, monitoring or actually doing anything with the information. They are just making sure it got delivered so that they can be sure the process is proceeding according to plan. There is a certain amount of reason in keeping TODO lists to make sure that everything is done and nothing forgotten, and to check off the items as they are done. But with a TODO list the items serve a purpose when they are done: you have bought the milk, bread, and eggs; you have washed the car, mowed the lawn and taken out the trash. When the items on the TODO lists that make up processes have no meaning or use in the current process then it does not make sense. Many of those items, like reports, sign offs and verifications are left overs from previous manual or early automated processes where such checks were necessary. Some are left over from the early stages of a process when activities were tried, determined to have no value, but left in anyway. So the additional reports that have the same information in a different format are costing the company money. So, I violated protocol, my own included, and in a meeting asked the senior manager who was requesting the reports if it were necessary to prepare the information a third time in a different way. He stammered a bit (he actually stammered) and then said “I don’t want you putting in extra work if the information is already available.” He asked one of his direct reports, Tom, if the information were available in a form they could use. Tom told him that he currently had the information and was using it and would not use any new version of the information. The senior manager rescinded the request for the new report. Sometimes it only takes asking why the information is needed, what is it used for. If the answer is to ‘check a box’ then you may be performing a useless activity and no one has realized it yet. If you are not worried politically you may challenge the work you have been asked to do. And you should if you feel the work is not adding value to the project, the organization or your job. You have that right.