Have you noticed lately that there are a lot of industry “buzz words” and “phrases” that seem to be driving your corporation’s strategy and your every day approach to work? “Agile”, “agility-minded”, “progress over perfection”, “fail faster”, “do more with less”, and “get stuff done” are a few of the common ones these days. These are all challenges that are being issued on a daily basis. You know what? I don’t disagree with those challenges. I think it is a natural decision for leaders to make as they strive to make the bottom line or find creative ways to increase profits, but is it doable?
Your goal is to get information. You want to get as much information as you can. You can always eliminate nonessential and irrelevant information when you analyze the information you have obtained after you have gotten it. Considering that the only way that we can be sure we will ask the Right Question is by getting the right answer, and the only way we know we got the Right Answer is by getting as many answers as we can. During the process of getting the information, we need to do everything we can to increase the flow of information and that includes preparation for asking as well as the actual act of asking the questions.
Recently I delivered a workshop on Risk Planning and Analysis for the Business Enterprise. I was asked about the various levels of risk within an organization. In response to that question, I explained that there are many levels of risk that could be organized along standard company structure. My preference is to use three structure approach - - strategic, tactical and operational.
So, here’s the scenario: Your organization wants to purchase packaged software to support a key business function. Your team thoroughly evaluates several products and chooses the best fit. During discussions with the vendor, you discover they “use Agile.” This is great because your organization “is Agile” too! Awesome! Contracts get signed and we all get to work.
Then, things start to go awry as your assumptions jump out of the dark corners and startle your progress. Communication crumbles, messages are confused, processes and practices differ, team dynamics and what even is “a team” seems to be a huge struggle. You soon discover that the most basic agile terms being used do not mean the same thing! Your version of Agile does not align with your vendor’s version of Agile.
It’s easier to defend Business Analysts than it used to be. Part of the reason is because I am defending the role in general. My job isn’t on the line any more. For other people this is a much more immediate concern. Still, it brings back memories. I hear the question at a conference or networking event and my heart shrinks. “Why do we need business analysts?” No matter how the topic comes up, it always makes me sad*.
I used to think other folks didn’t get it. The significance provided by analysts was obvious and self-evident to me. How could managers, executives, teams, and developers not understand all the value BAs add? Can’t they see BAs are the glue that holds these projects together? What would a project be without the contribution of a good business analyst?
Part 1: What do Business Analysis and Entrepreneurship Have in Common?
Welcome to the first installment of the Entrepreneurial BA series. Given we are both entrepreneurs and BAs it seems logical for to write about this topic. But, why bother? What possibly could be relevant about entrepreneurialism for a business analyst? Well, for starters, it’s a great career option and more and more viable with each passing year. Even if you are not interested in forming a start-up, the principles of entrepreneurship are becoming increasingly important for organizations to innovate and stay competitive.
Many years ago few of my colleagues started working on a project, which was not so complex. It went well for the first few months. The problem started when the team travelled to client location to give a demo on a module to seek client’s feedback. The client suggested certain changes that were accepted by the team. The team built the module with new suggestions however, the client suggested few more changes. After a couple of similar back and forth interactions, this situation gradually led to passing the buck in the blame game between the client and the development team. The project was ultimately shelved by the company as it was no longer a delivering a good ROI since the client refused to increase the time and the budget any further.
Situations like above may not only lead to rework, wastage of time and effort, financial loss but may also result in huge customer dissatisfaction leading to loss of repute in extreme cases. Additionally resources working on such projects would be more than willing to exit such projects.
Each year we like to reflect on what’s happened in the business analysis, project management, and Agile professions and make our predictions for the upcoming year.
To summarize the trends we saw in 2014:
- Continued excitement about Agile projects with more informal communications and documentation and use of modeling tools to get from high-level user stories to detail needed to estimate and build them
- Focus on Design
- Cloud computing
- Greater interest in business analysis by project managers.
Below are the seven new trends we see in the Project Management and Business Analysis fields for 2015.
In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition. In both books I took on the topic of Backlog refinement.
In part one of this post, I set the stage for what backlog refinement was by referencing the Scrum Guide. Then we explored 5 of 12 overall refinement tips. I’ll continue with the remaining seven tips here:
12 Tips for Effective Backlog Refinement
6. Talk Less, Spike More – I’ve noticed a very common anti-pattern in many refinement sessions that teams explore each story far too deeply. They wax into conjecture and guessing about design challenges. They debate implementation approaches. They argue estimates on stories that are still quite immature and ill defined. In a word, they talk too much about the stories.
What is co-design?
A number of terms have recently cropped up that reflect a new way of developing IT solutions – co-design, joint solutioning, as a service etc. Fundamentally they are all trying to fix a common problem and need to be properly managed to achieve the outcomes expected.
The premise behind the approach is that the traditional way that businesses have specified IT systems has been inefficient. It is quoted that 60% of code in IT applications is never exercised. The systems that have been built have high complexity, are difficult to upgrade and consequently provide a lower return on investment.
The new co-design process makes the reasonable assumption that the suppliers of these systems have valuable experience in implementing solutions and can use this experience to recommend “best practice”. Organisations procuring these solutions should merge the best practice recommendations with their own requirements in a collaborative supplier / buyer engagement.
“Certified Business Analysis Professional” (CBAP) always seemed a little awkward for a professional designation. Those of us who got it early actually worked directly with people to take the test (no on-line then). I had some low fun teasing the exam team (Cleve Pillifant and team, thank you again) about the acronym. It was low of me since the exam team was available and the decision makers were not (shout out to Kathleen Barrett, hope you are doing well). To those whose eyesight is fading, the “B” can even be mistaken for an “R”. This is no big deal and is common enough (case in point “PMP”).
Now things change, because it is increasingly obvious that ANALYSIS (breaking into parts) is only half the battle (the easy half). The harder “half” is business SYNTHESIS. * Synthesis means taking the parts stated by stakeholders (requirements [stated]) and organizing them into possibilities by reducing confusions and artificial constraints (“but we built what they told us to build…whimper, snivel”).
Modeling IS simplifying. Simplifying requires doing something MORE, NOT LESS. Some of you will understand the statement “If you want it shorter it will cost more.” We know this is true because stakeholders are very reluctant to “simplify” the information they can offer. We also see this is true because we must reconcile wants across silos – often very committed silos.
“You are remembered for the rules you break.”
Anyone who has studied the history of medicine will notice that some of our biggest breakthroughs have been the result of a single scientist breaking the rules. History tells us these are the same people who have also effectively changed a conventional paradigm. For example, the world is flat, wash your hands, earth revolves around the sun. Often times, the rule-breaking scientist pays a considerable price for being a change agent. The pain of change forces an outlandish idea to become a piece of conventional wisdom.
Even in the social sciences, we often see rule breaking as a means to progress and enlightenment. Just look at Rosa Parks and others like her during the Civil Rights Movement. Nelson Mandela in the face of Apartheid. Ronald Reagan challenge to Gorbachev to tear the wall down.
Few of the areas within the business analysis context are least understood and as a result the business analysis document becomes a dumping ground of the project content and activities.
Do these questions ring a bell?
- Can we avoid the BA documents to be a dumping ground or catch all for the project activities?
- Are the stakeholders trying to prescribe “detail tasks” instead of focusing on their actual needs?
- Does your stakeholder team get upset when you refuse to record un-related information in the BA documents?
- How do we make sure that un-related things are really those un-related things and it needs a bigger and better house?
As Business Analysts, you need to be cautious about the information which needs to be captured. You should be able to decide/comment on content of the document. The suggestions below may help you decide in the future should the above questions arise.
Recently I was working with a group of 25 professionals in developing their business analysis capabilities. Business Analysis as a profession has gained a lot of popularity over the last 10 years. All sorts of professionals and consultants are focusing on creating a tool kit so they can help businesses make better decisions.
One challenge I often see is the lack of understanding of the various types of requirements that a business has and the ability to link those requirements. It concerns me as there are a lot of professionals and business leaders doing things that are in no way connected to the business needs and the key strategic agenda items.
The first thing to consider is the definition of a requirement and the second is to know the four key requirements and how to apply them.
In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition . In both books I took on the topic of Backlog Grooming.
As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog
Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.
Backlogs & Refinement
Why don’t we first start with a definition of Product Backlog. From the July 2013 Scrum Guide, I’ve captured the following:
The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
The idea of sitting through a requirement workshop via teleconference seems like torture. Virtual requirements meetings tend to bottleneck our ability to effectively collaborate. Attendees and facilitators:
- dread the dead air and the anonymous beeps in and out: “Hello, this is Angela. Who joined?” “Bob. Bob? Bob, are you still on the call?”
- seem lost without visual cues like hand raising, eye rolling and head nodding. “Does everyone agree with that change? Is there anything else we need to add?” Silence. Facilitator wonders: “Does that mean everyone agrees or no one is paying attention or everyone is talking on mute?”
- feel constrained when they can only collect/offer information verbally, one person at a time.
- feel limited when their most successful in-person techniques don’t translate to a virtual environment.
Painful, but Required!
Despite the dread and pain, the need for effective virtual collaboration is increasing. Even in small to mid-sized organizations, it’s rare to find all stakeholders sitting in the same building or even in the same city.
“Some of these things, are just like the others, some of these things are not quite the same, can you guess which things…” Analysis is the “anti-methodology”, always seeking coherence, relationship and significance rather than exclusion.
Let’s use some BABOK categories to organize stakeholder “stated requirements”. In the process we will see how we can distinguish “requirements” from requirements when we model potential solutions.
Let’s say your stakeholders have stated things like:
If I had some extra time on my hands I would set out to revamp how performance reviews are done, especially for project teams, especially for you. Too often performance reviews are based on individual performance over team performance. I think about this often and looking back on some posts I have written, this seems to be a topic I bring up every now and then. Recently, I attended a seminar and the speaker said something that triggered this thought again. He said, in so many words, “When working on a team you need to know your background and experience. If something comes up that needs to get done, and it aligns with your experience, say...’I can help with that’.” This is regardless of your job title or function. It seems obvious and makes sense, but often people stay in their silos. Why is that? Is it money? Is it performance measures based on your job title? Is it due to how individuals get promoted? You know the routine. You can’t get promoted into a role until you show you can do it. So people don't focus on what the team needs, they focus on doing tasks that will get them promoted. Another thing is employee of the month programs. Too often they promote the hero mentality. People that win this award are the ones that sweep in and save a failing initiative. They work extra time and save the day. This promotes anti-teamwork behavior.
So why do I think those issues are the culprit? Because team productivity works when those things are not an issue. I am on a volunteer committee and how we are operating is an example of how teams should operate. I have no title… just committee member. The only ones with a designation are the co-chairs. The reason for that is it helps with organization and points of contact for other groups to interact with us. They know they can reach out to the chairs if they have questions/comments. The chair can then get the right people involved. When we formed as a committee we worked on three things after having a shared understanding of our goals and objectives.
More and more workers are bringing their own devices to work, often to the chagrin of IT types who will then have to manage numerous devices running often divergent operating systems. However, there is another category of employee that relies on accessibility and simplicity from his work tools: the mobile worker. This is essentially anyone who regularly travels for a job, and has moved beyond the realm of keeping life on a laptop. These days, it is more convenient to compartmentalize aspects of work and distribute that workload to the devices that best handle it. According to a recent article from the Huffington Post, “ninety two percent of workers believe their smartphones should be enabled for both work and personal use”. This is up a 2012 report showing the average American knowledge-worker carrying roughly 3.5 devices at any given time.
This reveals several compelling trends regarding the devices that workers carry with them. Obviously, items like tablets are a staple of the mobile worker’s repertoire, but more interesting is the fact that workers are not consolidating their devices. Rather, they recognize inherent strengths and weaknesses of the various platforms, and instead of sacrificing functionality, they sacrifice the convenience of only carrying one device.
Can you even imagine Lionel Messi or Cristiano Ronaldo jumping up-and-down on the edge of the soccer fields screaming “pick-me, pick-me”. Absolutely absurd right, people pay big bucks to have them on their team! This is how I feel when the topic of innovation comes up in business. I can see the value a BA can add because it’s as clear as day for me and the team, but no one else seems to see the contribution that a BA can make. We would love to scream from the rooftops that this is what we’ve have been trained to do; we have the toolset to tackle the challenge - we can add value, we are knowledge workers.
This is becoming a common occurrence for BA’s, when faced with the question “How can I take my business from being a commodity (widget) to being an integrator?”
A commodity/widget is produced to serve a specific purpose without any additional value add, and as such is easily replicated. A widget by definition is generic and non-descript.
The integrator not only serves the purpose at hand, but also explores and delivers additional value. Its aim is to continuously understand, adapt and deliver that extra bit, so that the consumer is always amazed and left wanting more. It’s the edge you can give to the business- keeping it a step ahead of everyone else.
A Business Analysis Centre of Excellence (CoE) can be an effective means of improving the way business analysis is performed, resulting in better business outcomes from successful projects and operational support initiatives. It often begins with an ambitious training program, followed by a distribution of templates and instilling the best practices. Some CoEs are successful, but all too often the CoE is disbanded after a couple of years of disappointing results. Having been involved with dozens of CoEs with different companies, I’ve observed some of the most common mistakes and how to avoid them.
1. Failure to Engage the Right Stakeholders
Many CoEs successfully inform executives about the CoE’s reason for existence, and they also let the BAs know what is expected of them. However, few BA CoEs meet the needs of the other key stakeholders. These stakeholders have their own priorities and challenges, and may not have time to worry about better business analysis. Take the time to understand their needs, and to help them make the necessary transitions.
I saw the following series of snippets in a LinkedIn discussion on the Agile ALM tool Rally. Bear with me as you read through them to get the context for our discussion…
I have a serious case of "I want to get back to JIRA Agile".
My latest challenge with Rally is to find the best and most true way of dealing with unfinished stories at the end of a sprint.
Story: I as a ScrumMaster want to move 3 unfinished stories from Sprint 1 to Sprint 2 gracefully so that the team will have these stories in the next sprint without falsifying the velocity of Sprint 2 or the backlog and not creating any more overhead for the ScrumMaster.
- Total backlog story points stays true
- Velocity of previous sprint stays true (commitment is reflected accurately)
- It's not adding a huge amount of overhead on the ScrumMaster or the person doing it
- It doesn't need a custom app for doing this
As I was reviewing the presentations from this year’s Building Business Capability conference, I kept running into slides that looked like the graphic below to describe frameworks which model how organizations operate (the details have been left intentionally blank to protect the innocent):
The Everything Framework
In this one example there was no less than 13 different model components and 25 relationships defined!