Tuesday, 03 January 2017 07:24

How to Learn New Techniques

Written by
Rate this item
(3 votes)

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:

  1. Techniques that are new to you, but are practiced by other members of your team.
  2. 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:

  1. Choose a concept
  2. Teach it to a Toddler
  3. Identify Gaps and Go Back to The Source Material
  4. 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.

Read 3167 times
Kent McDonald

Kent J. McDonald helps teams discover the right thing to deliver. His more than 20 years of experience include work in business analysis, strategic planning, project management, and product development in a variety of industries including financial services, health insurance, nonprofit, and automotive. He shares resources for effective business analysis and product ownership in IT at http://kbp.media and practices those ideas as Product Owner for the Agile Alliance.

Kent is author of Beyond Requirements: Analysis with an Agile Mindset and co-author of Stand Back and Deliver: Accelerating Business Agility.

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250