Mistake proofing your process
Analyzing a process to find where the errors are Continue reading Mistake proofing your process
Category: Investigation
Card sorting – agile BA technique 158
Card sorting is a simple and useful way to gather feedback on which features people want in a new system, which problems they want solve or generally speaking, what they want.
So I was surprised recently when some business analysts I was working with had not heard of the technique and I thought I would describe it here so they can look at it again.
All you need is something people want and a pile of cards to sort:
Is it enough to say that the BA is the “universal translator” between business and IT?
I often hear that we need a business analyst to translate what the business people say, so that technical people understand them. Then, I am told we need the BA to then translate what the technical people say, so that the business people understand them.
I guess it goes something like this:
It sounds good, but actually I don’t think it is true.
Can I still use a use case on my agile project – even if the cool kids don’t use them anymore?
I have been told that use cases are very old fashioned now and that all the cool people have moved onto agile user stories.
But I am old school and I still like to pull the old approaches out every now and then and take them for a spin.
I found myself explaining use cases in both a lecture (where the company wanted me to explain them to the BA teams) and a small team where people had been doing use case diagrams but not really use cases. Then I got asked in a BA course – “do you use stories for agile projects and use cases for waterfall ones?”
My answer was “it depends – probably just ask the BA”. But the student responded that she was a BA and that all the other cool BA’s would make fun of her if she wore the wrong clothes to school or used the wrong tool on the wrong project.
Using a moments of truth analysis to assess a team’s readiness for change
I have previously blogged about a number of approaches to assessing a team’s readiness for change, including the 7-S framework and the arenas of change approach, but today I thought I would explain a less well known approach – the “moments of truth” assessment.
Actually I made it up so it is not too well understood outside of my own loungeroom. The approach is essentially the same as the 7-S style of assessing the interaction of the multiple systems, skills, stucture and other elements of the team’s whole ecosystem. But this is a little different because we start by looking at when (and why) the team’s internal or external customers interact with it. Then we assess the team’s ability to support those interactions.
Moment of truth(n) a moment when a person or thing is put to the test
Collins English Dictionary as quoted at http://www.thefreedictionary.com
Any interaction with a client is “a moment of truth” for the team. It tests the connection between the team’s value proposition, strategy, implementation, staff, skills and systems and it generates the experience that lasts in the customer’s memory until he or she interacts with the team again.
A “moments of truth analysis” therefore starts by identifying the interactions a team has with its customers, stakeholders and potentially vendors.
Continue reading “Using a moments of truth analysis to assess a team’s readiness for change”
Preparing for a stakeholder interview part two – using the GRIFT model
The goal of your interview is the single most important thing to know before the interview, but it is also useful to know a bit more about what you are hoping to achieve before you start the interview.
So that is where I use the powerful “GRIFT” model to do my preparations.
Actually it is not a very powerful model, it is simply a checklist of things to think about, in some sort of order, before interviewing someone. GRIFT is short for the following headings
- Goal (as defined in my previous article)
- Roles (What is your role in the interview? What about the stakeholder?)
- Issues (What issues to you think you might encounter? What will you do?)
- Focus (What is your focus for the interview?)
- Takeaways (What will you deliver as a result of the interview? Are there any action items?)
Since I explained the goal in my previous article I will explain the remaing items in this one – RIFT, I guess.
Continue reading “Preparing for a stakeholder interview part two – using the GRIFT model”
Preparing for a stakeholder interview part one – setting a clear goal
You might be surprised to find out that people often turn up to interview a stakeholder with little or no preparation.
You would probably not be surprised to find out though, that when the interviewer is poorly prepared, the interview results in a conversation without a real resolution and the interviewer has missed an opportunity to get off to a clean start.
So I thought I would add a simple (but very long) guide to some ways you can prepare for an interview. This article, and a couple that follow, are based on the “GRIFT” model that I developed while training BA’s.
Continue reading “Preparing for a stakeholder interview part one – setting a clear goal”
OODA Loops for fighter pilots, business analysts and testers
When I started to learn agile approaches to projects, OODA was all the rage, but it seems to have disappeared from view as modern agilistas move from Scrum to lean to Kanban to ultra-velocitus development.
I guess I am still a bit old school, because I still think the OODA loop is the essence of the agile approach.
So what is an OODA loop?
OODA loops began as an approach for fighter pilots to avoid dying. It is a way to train fighter pilots and also a way to design fighter aircraft, develop tactics for air combat and win wars in the air. It turns out that it is also really useful for agile projects, production support teams and anyone rolling out a product in a competitive market.
Continue reading “OODA Loops for fighter pilots, business analysts and testers”
Famous BAs in history: Mark Twain on interviews
I stumbled on a letter from Mark Twain where he comments on “the interview”:
Controversially, he claimed that interviews are appalling and should be completely abolished … which would seem to be a strong position for a business analyst to take these days. But then Mark Twain was around at the beginning of last century and we have learned a lot since then. Maybe he just didn’t know any better.
Continue reading “Famous BAs in history: Mark Twain on interviews”
User stories for production support part 2: PAC
I wrote an article on stories for production support teams quite a while ago. But I always meant to add a couple more.
The problem with production support is that nobody has time to ask for what they want, but it is all urgent and super critical. So the last thing you often feel like doing is to slow down and understand the context that the user is in (annoyed, relaxed, sitting in a cafe, in their most important sales meeting ever etc). Instead the focus is usually on fixing “it” before you know what “it” really is.
But this often leads to rework. So whenever I am doing enhancements I always spend a little time understanding why the enhancement is needed, who it is needed by and when/how it is likely to be used in the real world. To do this though, I think we always need to spend a little time understanding the people who will use the system and why they need something new.
There are many approaches to doing this, but one I often find useful is “PAC” or “People, Activities and Context”.
Continue reading “User stories for production support part 2: PAC”
