Tag: Techniques

How to Learn New Techniques

Written by Kent McDonald on January 3, 2017. Posted in Articles.

Introduction: The fourth thing I wish I knew when I was starting out as a business analyst was how to learn new techniques in a way that I can be most effective.

With the vast amount of techniques out there, it’s possible to become a professional student and spend all your time learning about new techniques, becoming an expert in every one. That’s not necessarily what I’m suggesting here. Rather, I think it’s important to be aware of the variety of techniques available, when to use them and how to quickly get up to speed on them when you need to. Here’s how I go about doing just that.

Keep an Eye Out for New Techniques

There are 2 categories of new techniques for business analysts:

Techniques that are new to you, but are practiced by other members of your team.
New analysis techniques that make you more effective.

It’s easy to decide when to do the first type of techniques – usually someone on your team has hit a bottleneck and needs some help to keep things moving. If you have some time available, or the work you’re currently doing is not as time critical, you can be a good team member and help. Hopefully, learning that new technique will also help you be better at business analysis. That was the situation I was in when working on a data warehouse project as a project manager/business analyst and found myself reverse engineering COBOL code to elicit business rules, modeling data, and developing SQL stored procedures. I primarily did those activities because they needed to get done, but they had the added benefit of adding skills to my toolkit I use to this day.

Deciding when to pick up new analysis techniques can be a trickier. You need to balance seeking continuous improvement with not falling into the shiny object syndrome where you think a new technique you hear about is the answer to all of your problems. I know this happens because I’ve fallen into that trap more often than I care to admit. What I have found works best is to find some people I trust and respect and listen to what they are talking about. This works best when you follow people that you know are practitioners because when they share their stories you know they are sharing things they have done. I compiled a list of Product Ownership Blogs and Newsletters on my blog that I follow to find out about new techniques. That list is primarily product management and UX focused because those types of techniques are very helpful for business analysts.

When you come across a new technique make sure you understand what outcome the technique produces, and when it is most applicable. If you explicitly look for this information, you may avoid falling victim to the shiny object syndrome. The other thing I suggest you do is keep a perspective of Just-In-Time instead of Just-In-Case learning.

Just-In-Time learning means you find out what the technique is, know when it’s appropriate to use, and where to find out more information. Organizations like the IIBA (in the BABOK Techniques section) and the Agile Alliance (in the Agile Glossary) provide descriptions of techniques at a level appropriate to understand what techniques are and when they are useful.

Just-In-Case learning means you go on a binge of downloading resources, buying books, and attending classes about a technique even though you aren’t sure when or if you will use it. When you do this, one of two things happen. You learn all this great info about this new technique, then don’t find an opportunity to use it and promptly forget everything. The other alternative is you learn all you can about the new technique and then you walk around with a proverbial hammer in your hand and everything looks like a nail. You applying the technique to solve every problem you come across even when it’s not a good fit. Don’t do that.

Search for Resources About How to Do It

Once you find an appropriate use for a technique, it’s time to do a deep dive into that technique. If you’re learning a technique to help other team members, ask those team members what resources they suggest.

You can also do a targeted internet search where you ask about the technique in a specific context, such as: “Story mapping for health insurance business intelligence”. If you don’t find any useful resources with those specific searches, you can always broaden your search. Pick the results that describe actual experiences rather that the resources that only explain the theory of the technique.

Wikipedia is a good place to start with information about the technique, but use it primarily to find out who initially created it or has expanded the use of the technique then look up resources from those creators. The Agile Alliance Agile Glossary that I mentioned is also a good place to find links to other resources both on the Agile Alliance site and off that provide more information about some techniques.

Targeted questions on LinkedIn groups can also be helpful. Just be prepared to separate the people who have used the technique from those who have read just read about it. Pay attention to people whose answers are like “when we tried this out I found” or “I usually like to do this…” over those who respond with prescription such as: “the daily standup must always be 15 minutes or less and managers must not speak.” When you find some people with actual experience using the technique reach out to them and pick their brains. Your own experience is the best teacher; other’s experience is almost as good.

Establish a Safety Net

This step is most appropriate when you learn a technique new to you but familiar to others in the team. Find someone on the team who is an expert in that technique that you can either pair with when you are doing the technique or run things by before you finish them. Since you are probably doing a task to help someone who is too busy, you’ll have to find a way to get this support that makes the best use of the other person’s time.

When I was doing the SQL development for the Data Warehouse project, my safety net was Mike, a skilled SQL developer in our area. He had limited availability for the project, so I did the development work and testing in a test environment, and then went over it with him. It was important for me to find out not only where I had written bad code, but also why it was bad code. Finding that out helped me to understand more general principles around writing SQL code that I still remember to this day. The same idea applies for any technique you learn.

One approach that teams use to allow members of the team to learn techniques and to provide safety net is called Staff Liquidity. It’s the idea where each member of the team assesses their abilities for a variety of techniques then when the team is deciding who is going to work on what, the people who are less familiar with an activity volunteer for items dealing with that activity first. That leaves more experienced people free so that they are available to coach and mentor. The idea behind this is twofold. 1) the knowledge about key activities spreads throughout the team. 2) The more experienced members are available to jump in when an urgent issue comes up without having an undue impact on the work of the overall team.

Just Do It

You can read about a technique and talk to others about how they’ve done it, but you really learn by doing it. You’ll learn it even better if you make recoverable mistakes when trying the technique out. If there is a new technique that you think may be helpful, make sure it’s appropriate in your situation and try it out. Start with the expectation that you may make some mistakes and be prepared to learn from those mistakes and figure out how you may do it differently in the future.

Limit the amount of time you try a technique the first time. You don’t want to spend a lot of time doing something without any feedback. Try something in a limited fashion and then get feedback on how the technique went, consider that feedback and think about how it will impact what you do the next time.

When I was doing the SQL development, I would write a procedure or two, then I would run those procedures in test and check them with Mike to make sure I was heading down the right path. If I made a mistake at this point it was recoverable because I was in a test environment.

These days I get the opportunity to expand my website building skills when I make changes to the Agile Alliance website. I pick an isolated instance of the new technique I’m trying, do it, then have some other members of the team look at the page to get feedback.

If you are taking a course on the technique, make sure the course includes an opportunity to try out the technique, if not in your own context at least on an example that is somewhat related.

Teach it to someone else

If you’ve used the technique and found it worked for you, and you think you are going to continue to use it, the best way to increase your knowledge and understanding is to teach it to someone else. Richard Feynman, a Nobel Prize winning physicist known for his ability to explain complicated topics to people came up with the Feynman technique which is a great formula for learning anything:

Choose a concept
Teach it to a Toddler
Identify Gaps and Go Back to The Source Material
Review and Simplify

Use the Feynman technique to describe the technique you have learned and tried out to help other people learn it as well, at the same time making sure you really understand it.

How Do You Learn New Techniques?

Those are a few of the ways I go about learning techniques. I’d love to hear what you have found works. Leave your thoughts and experiences in the comments below.

Harnessing the Immense Power of Your Thoughts

Written by Clinton Ages on November 1, 2016. Posted in Articles.

Welcome to the next post about the wonderful journey towards greatness with Coach Clinton 7-Steps to Accomplishment Methodology.

This series of 8 articles is all about developing and expanding your horizons and realizing all of your life’s dreams. We have discussed the first three steps in this seven-step journey and today I will reveal the fourth magical step for you. To keep the conversation flowing, here’s a quick recap of what we have already discussed:

Step 1 – Appraise: Analyzing your actions/habits, eliminating the unproductive ones and picking up the value-adding activities only.

Step 2 – Ascertain: Formulating, categorizing, and prioritizing your success goals.

Step 3 – Approach: Developing a comprehensive, actionable plan to cover all your goals.

Now that we are back in the flow let’s head towards the fourth step – Avert.

Step 4 – Avert

This step is called ‘avert’ because here we will make sure that you steer clear of all sorts of negativities and self-limiting behaviors. How will that be done? By focusing only on the positive aspects of your life and creating a strong will to achieve your goals. Any self-doubts, if present, will be wiped out and your internal space will be cleared up to make way for confidence and commitment.

Have you heard the story of the “Little Engine That Could?” How did the Little Engine manage to achieve a feat that was scaring away the stronger engines? The secret behind that Little Engine’s success was that it believed in its abilities. It pushed aside all doubts simply by chanting the mantra “I think I can, I think I can”! Similarly, this step involves finding the mantra that is made exclusively for you, in order to get the best results. It is also known as the Motivation Affirmation and saying it over and over again makes a huge difference in the achievement of desired results.

What is an Affirmation?

It is appropriate to take a closer look at what actually is an affirmation and how can it help you achieve your goals. An affirmation is a thoughtfully developed phrase or sentence that you repeat regularly. It is basically the act of making a declaration to yourself – repeatedly. The basic premise is that anything can be materialized into existence by repeating the same group of words repetitively. For example, if I’m not in my perfect health and shape, I might develop a positive affirmation like “My health is improving every day”. Simply put, Motivation Affirmation is using words of encouragement to help increase your positive energy and give you the “I think I can” will power to overcome difficulties and accomplish your goals like the Little Engine That Could.

Do you have a hard time digesting the fact that a few simple words can achieve such great feats and are you also struggling with how affirmations are capable of such results? Don’t worry. Because affirmations have been scientifically proven to have the power of rewiring our brain’s functioning to make us believe whatever we are affirming. When you repeat your affirmation, your brain gets a message that this is something important. In other words, this message becomes a part of your belief system, and your body acts accordingly until that goal is achieved. There are a number of scientific studies that verify the positive impact of affirmations on one’s mind and the way our brains function. So, it’s time to put aside your doubts. It’s time to make your dreams come true by drawing energy from the positivity of words!

Why do we need affirmations?

Because we all have developed some sort of apprehension about our capabilities and we have installed a mental ceiling limiting whatever we are capable of achieving in this life. These self-limiting attitudes are a result of a number of factors, which we might or might not have consciously noticed throughout all these years. Every failure – whether big or small – leaves a small amount, a residue if you will, of self-doubt in our minds. This is especially true when we do not consciously perceive this failure as an opportunity to learn and improve. These small deposits pile up to put us in a permanent state of self-doubt, and we start believing that we are not good enough.

This step, in your journey towards success, is very important because using the motivation affirmations, you can easily get rid of these negative thoughts and avert your negative behavior. Motivation affirmations help you in two ways:

By using professionally developed affirmations, you can get the negative thoughts and attitudes out of your way. This cleansing is very important because nothing good can happen if you are holding on to negative attitudes and habits.
These affirmations are called ‘motivation affirmations’ because once the roadblocks are clear, you can use them to motivate and pump up yourself to the point where there is no option other than taking action to materialize your success.

Anatole France, the great poet, and novelist, once said that “To accomplish great things, we must not only act but also dream. Not only plan but also believe.” These words go a long way to reinforce the primary point of this discussion. Dreaming and believing in the realization of those dreams is as important as planning and taking suitable action.

Motivation affirmation is the tool that will help you dream. It will bring out your true desires and by repeating those desires in a positive manner, you will start believing in achieving those desires. Once you start believing, you start achieving. It’s as simple as that!

Since these words are now paving the way for your success, you cannot leave them to chance or luck. It is very important to have your affirmations developed by a professional. With my decades of experience in helping people reach their best, I will work with you to formulate your motivation affirmations. I will do that by analyzing your unique personality, your ambitions and a host of other elements that will provide me with the feedback to come up with the words which will serve as magic for your success. The result will be a bespoke motivation affirmation for you which will catalyze this process of performance enhancement by clearing up your thinking process and making you more confident of your abilities and unique talents.

There is no rocket science in motivation affirmations. It’s just the art of using words to manifest your dreams and desires.

Once you have your motivation affirmation in your hand, you’ll be on your way to chant your way to success.

I will see you soon in the next step of our magical journey. (Hint: It’s packed with action!)

Deep Dive Models in Agile Pt 2: Feature Trees

Written by Candase Hokanson on October 5, 2016. Posted in Articles. 1 Comment on Deep Dive Models in Agile Pt 2: Feature Trees

This short paper series, “Deep Dive Models in Agile,” provides valuable information for the Product Owner community to use additional good practices in their projects.

In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.

Next up in this series is the Feature Tree. If you missed the first edition on Process Flows, you can find that here. Other editions in this series will include: Business Data Diagrams, State Tables/State Diagrams, Decision Trees/Decision Tables and Business Objectives Models.

What is a Feature Tree?

A Feature Tree is an RML Objectives model that shows the full scope of features for a project or product on a single page in a tree format. A feature is just a short form description of the functionality provided by the project or product that brings value to the end user. The Feature Tree is great for bringing new people on a project up to speed and showing executives, business stakeholders, or customers all the features that are in scope for a project or release.

The Feature Tree is similar in shape to a fishbone diagram or an Ishikawa diagram but shows levels of features instead of root-cause analysis. It is easier to read than a flat list of features for a product because the Feature Tree groups them into logical buckets, but Feature Trees are very similar in function to Story Maps or Affinity Diagram which are also other ways to organize features visually for consumption. See an example Feature Tree below.

When would I use a Feature Tree on an agile project?

Feature Trees are useful for almost any agile project because they are just a good way to organize information about the project. The Product Owner (PO) or Business Analyst (BA) will usually elicit the start of a Feature Tree during a sprint 0 or planning type phase, possibly with information from a project charter or light-weight business case. From there, the PO or BA will organize the features into groupings, understand the connections between L1, L2, and L3 features and identify if there are any missing features. Depending on the story hierarchy you are using on your project, you might use Program Epic -> Feature -> Story or just Feature -> Epic -> Story for your L1, L2, and L3 features with the story level being optional (see illustration below).

Since you won’t always know the full scope of the product during sprint 0 or planning, the Feature Tree is always evolving, even throughout development, as the PO or BA finds new features to add to the backlog.

The Feature Tree also helps organize the hierarchy of your backlog as you know have an easy visual of how things are related.

Some ways Feature Trees are modeled to be especially useful on agile projects:

Color coding: the PO or BA can color code the features by release or sprint/iteration, which makes it easy to see at a glance if certain features are in or out of scope for a release
Prioritization by location: the PO or BA can order the Feature Tree such that more important items are closer to the “trunk” of the tree, allowing for visualization of the backlog prioritization
Gap Analysis or Current/Future State: instead of color coding by release, the PO or BA can color code for gaps or current vs. future state of the system (with red, blue, green or little-colored circles we like to call skittles)

How do I create a Feature Tree?

Like Process Flows, Feature Trees are one of the easier RML models to elicit and create. First, the PO or BA should find out if there are any existing lists of features for the project or product from a vision and scope document or a project charter.

From there, the PO or BA would host a brainstorming session to identify potential features and maybe even group them in an affinity diagram or story map. After that, the PO or BA would need to decide the format for their features. This paper is about the Feature Tree as a convenient way to organize the information, but a two level story map or affinity diagram will convey a lot of the same information (just perhaps not tie back to the backlog as well depending on the structure).

The model itself once the PO or BA has decided upon that format is pretty straight forward with only 2 elements:

Trunk/Product Concept– On the trunk of the Feature Tree is the Product Concept; this is a short form phrase that says what the product or project is. This will come from the Business Objectives Model which will be discussed in the next edition of Deep Dive.

Branches/ Feature- Coming out from the trunk are branches which have levels just like real tree branches. The largest branch type is the L1 features. Like the product concept, the L1 features will be described at a high level from the Business Objectives Model. These L1 features will be further broken down into L2 and L3 features (smaller branches) depending on your story hierarchy.

How do I derive user stories out of a Feature Tree?

Once the PO or BA has a good starting draft of the Feature Tree, the epics or features (again depending on your hierarchy) almost fall out of the Feature Tree. Each L2 or L3 branch becomes a feature, epic or story and each L1 branch becomes a Program Epic or Feature (based on SAFe or generic agile hierarchies). See example Feature Tree below:

So a feature for “Create Station” below might become the following epics/ features in your backlog:

Additionally, as mentioned above, you can add color coding to denote releases or sprints like below:

Conclusion

Feature Trees, like Process Flows, are super easy RML models to use on agile projects and derive features, epics, and user stories from because they organize the scope of a project or product onto a single page.

Executives, business stakeholders, and customer love this visual model because it shows them what is in and out of scope easily and potentially even shows them when they will get certain features. Developers and testers like the Feature Tree because it gives them the big picture of the entire project while they are working on specific user stories. Finally, the POs and BAs find this model useful for backlog population early in the project and maintenance throughout, so it is one of the most commonly used RML models on agile projects (second only to Process Flows!)

One note of caution is that because it is so easy to add additional features and scope to the Feature Tree and thus to the backlog, the PO or BA has to be vigilant in the management of the backlog to ensure that only the most valuable features get built for his/her project.

Why Does an Agile Approach Work?

Written by Tim Coventry on September 29, 2016. Posted in Articles.

I’ve been working with an Agile approach for decades, and I know it works.

Before we get into why Agile works, let’s go over what an Agile approach entails. Agile has been around for a while; however, many organisations are just starting to use this approach. Depending on who you talk to, it could mean many different things. However, there are a few well-described approaches these days, unlike when I started working in Agile environments in the late 1990s.

Scrum, Kanban, Large Scale Scrum (LeSS), DSDM, DAD, and SAFe are all suitable Agile approaches. Each approach has challenges but, used well they can provide enormous value to organizations.

Here’s the thing about an Agile approach.

Agile is a state of mind, a series of techniques, and an approach to software development. The ability of the business to adapt and change should set the iteration cycles.

Planning is vital with an Agile approach, and experience is the key to getting things sorted before the gun goes off for the sprints. Just enough analysis and tailored artifacts to deliver the business need is Agile thinking!

Think carefully about scaling so all teams are coordinated to deliver the strategy, remembering that Agile still focusses on business needs and strategy. High-performance teams are built on trust, communication, and a clearly articulated goal on how improvements to business performance are going to be achieved—you are not just building funky software.

Design and build a maturity roadmap so your organisation becomes more Agile over time.

An Agile approach to business analysis works for a variety of reasons.

Firstly, an Agile approach is more likely to break down projects and initiatives into smaller iterations – but so what? Well, this process should force you to define and divide your scope into smaller defined pieces, which will help you to find success in your project. Because you have good project or initiative design, you are more likely to be successful.

Further, Agile teams encourage people to collaborate and play nicely—which, again, is a winner.

Another side effect of an Agile approach is having more control of vendor interactions; some organizations engage vendors with a “silver bullet” mentality, asking the vendor to solve problems and take advantage of opportunities for them. Often they ask a systems integrator to elicit requirements, specify, design, and recommend a solution—and this often results in a conflict-of-interest arrangement.

Outsourcing critical business thinking is never a good idea—every organization must take control of good thinking!

Here’s an example of a good business analysis using an Agile approach.

The client, a large insurance organisation, briefed Business Analysts Pty Ltd (BAPL) to assist them in implementing a new system that would underpin their financial support functions. The existing financial support systems had reached end-of-life and were to be replaced with a new solution, Microsoft Dynamics.

The organization selected an Agile approach to delivery, but wanted to retain the function of business analysis to ensure quality requirements were achieved and adequate process modelling was carried out to provide context, scope, and to assist in change management and training.

With a depth of experience in Agile software delivery amassed over the last ten years, Business Analysts Pty Ltd worked with the development team and subject-matter experts to assist in eliciting the business need. Using BAPL’s knowledge of Agile and process-driven requirements, we were able to seamlessly integrate with the established project team and provide value from the outset.

BAPL played a key role in breaking down epics into manageable user stories without impacting the established velocity of the development team. Additionally, by extending the focus to business process, working with the subject-matter experts, and aligning the user stories to these processes, the development team were given greater context for the purpose of their task.

Some of the key successes:

• improved scope management and traceability of user stories to key business processes and business outcomes
• greater context to user stories, providing greater clarity of requirements and higher quality functionality
• improved change management and training
• greater alignment between the business and software.

Every organization performs business analysis and good business analysis is all about better business performance. Together, technology and good business analysis is the key to superior results.

Good business analysis is the foundation for organizational

• innovation
• business agility
• cost reduction
• cyber security
• risk control
• technology efficiency.

As organizations look to become more innovative to survive and prosper with technology in overcrowded industries, good business analysis is critical. Businesses today are more competitive than ever, and good business analysis through an Agile approach can give organizations the differentiating edge they require to prosper.

Is your organization ready for an Agile approach?

Lean Business Analysis: More About Decision Making

Written by Kupe Kupersmith on September 22, 2016. Posted in Articles.

There are many discussions, theories, and great debates over different kinds of BAs.

There are people that perform business analysis in IT environments; there are ones that are not in IT environments. There are process BAs, waterfall BAs, agile BAs, data BAs, and teams that have multiple people doing analysis. Regardless of when and where team members perform business analysis, they need to perform lean business analysis. To explain what “Lean Business Analysis” is, let’s look at the definition of Lean. From the Lean Enterprise Institute, Lean is defined as such, “The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.” So, I define Lean Business Analysis as creating more value for customers with fewer resources.

How do you accomplish this? Some may say you do it by spreading the BA work to other team members therefore eliminating a person on the team. The problem with that solution is it only addresses half of the definition…with fewer resources. You need a solution that completes both halves…more value for the customer and fewer resources. This brings me back to my old friend, Decision Making.

I have written about Decision Making before in the following posts, Decision Making: An Underlying Competency or What A Business Analyst Does and It’s All About Decision Making. If you think about business analysis as the activities done to help others make decisions, you have started on your path to Lean Business Analysis. By first looking at your project as a series of decisions, you can then determine what just enough analysis is for each decision. When a decision is made, you are done and can move to the next one. For example, one key decision is what problem are we trying to address. Another can be prioritizing features or user stories. Another is a developer determining how to best design a solution.

There are three key components to decision making that I want to highlight.

You need to define all the decisions to be made.
You need to know who the decision maker is for each decision. This may be one person; it may be many.
You need to know the criteria, or information, the decision maker(s) will use to make the decision.

Knowing the criteria, each decision maker has for each decision to be made is how you determine what information you need to elicit, analyze, and communicate. Once the decision is made, stop analyzing. Once a decision is made you have done enough analysis. Then you have created value for a customer and did it with the right amount of resources.

There is more on this process in my previous blogs, so I won’t repeat myself here. I do want to address a consistent concern I hear about this approach. When I talk about this with people over coffee, during or after a seminar or workshop there is a consistent pushback. “What if bad decisions keep getting made?” It’s a great point. You need to facilitate good decision making! My first response is the process needs to include decision evaluation points to make sure the decisions being made are helping your team meet the overall objectives of the initiative. The other thing is you need to help your customers avoid the four villains of decision making.

In their book, Decisive, Chip and Dan Heath, describe the 4 villains as:

Narrow framing
Confirmation bias
Short-term emotion
Overconfidence in the future

For this post, I want to cover the first two because they focus on how you present or communicate information to decision makers.

Narrow framing is the belief that you have two choices. Either you go out dinner, or you stay in. Do you take a job or not take it? Do we implement a project to go after an opportunity or not? You either do it “this” way or “that” way. There is no in between. People often talk about creativity in business analysis. By expanding the frame and looking at multiple alternatives is a way to get creative. Make sure you provide the decision makers with more than a this or that option. A way to check yourself is looking at the information you are presenting and seeing if one option looks like it really leaves the decision maker with no other choice then choosing the other option.

The second is confirmation bias. This is when you are evaluating options. Many people lean towards gathering information or listening to information that supports their view. Have you ever had a person come to you with the solution they wanted to be implemented? I know, silly question. People have ideas, thoughts and even look for information to help them make a decision. That information just happens to support their belief. The rest of the project team including you fall into the trap of confirmation bias. You are on the project you want it to succeed. It is a hard villain to combat.
One way to help combat this confirmation bias is to find a Red Team. A Red Team’s job is to poke holes in your thinking and/or your decision. They are used by the CIA, Army, news organizations, and businesses around the world. In our environment, we say stakeholders for a project are those impacted or can impact your project. A Red Team is a group of people that don’t have a stake in the project. They have no emotional connection. They have nothing to win or lose by your project. Your Red Team needs to poke holes in your logic and ensure you avoid confirmation bias.
The decision-making process is how you can do just enough business analysis or perform lean business analysis. Try it today and share your stories here!

All the best,

Kupe