Live from BAWorld: What To Do With Interfaces

Mary Gorman from EBG Consulting presented “Integrating Interface Analysis into your project: Just-enough, Just-in-time”. This talk was one of the advanced topics, with the intent of teaching about how to do interfaces – software, hardware, and user interfaces. I’m going to capture some summary points from her talk, either the key points or the ones I found most important:

1. She talked about just-in-time interfaces, specifically of interest is that idea that you can identify interfaces early in the project (first days even). A lot of projects wait on these, but there is no reason for that and you may miss things if you wait.
2. Do just enough. In some cases you can do minimal formal documentation, just enough to build and demonstrate the system, whereas other times you need very formal structured documents.
3. Business rules are at the center of all models. They are used by all models, and you will discover them in most models.

Mary talked about interfaces in various types of projects. For example in COTS projects, interface work is usually not about the user interfaces, but rather more about system-to-system interfaces since the COTS software has to integrate. When working on a project to update a system, existing interfaces have to be looked at for updates, and new interfaces or users might be added.


And she points out that a nice bonus from working on interfaces is that you also will likely improve your user requirements – by finding new users, new stories, incomplete stories (missing interactions), missing data attributes, and missing business rules.


My favorite part of this talk is that Mary used a role playing exercise in which people played different systems or the customer, and they used a ball that was tossed around to represent data passing between systems. She used it today to demonstrate the concept, but I talked with her afterwards and she does in fact use this technique for eliciting interface requirements.

I was excited to attend this talk because I have a lot of respect for Ellen and Mary from EBG, they seem to know a lot about practical things about requirements (as compared to a lot of the speakers who talk so high-level it's not usable material). They have some good books and whitepapers to learn from outside this forum if you haven't read them.

Live from BAWorld: A BA Mentoring Program

I heard a talk on building a mentor program for business analysts (BAs) by Dave Ramauskas from HTSC, along with 2 people from his mentoring program. They started by describing a challenge which we’re familiar with – that it is hard to recruit really good Bas, and very few of those found are hired. That’s why it’s important to use mentoring to grow the junior BAs and retain the senior ones.

They did a nice role playing skit to demonstrate what the mentoring relationship might look like in a specific scenario. As a side note - there were only a few talks I’ve seen here that did something like this, and they are all my favorite talks.

They walked us through the details of their mentoring program. And like with most companies, it’s a challenge to get a program up and running certainly, but they seem to have done well for a first cut. Here are the things they did, with my comparisons to how we handle this at Seilevel.

1. How to match mentors and mentees: Some suggested using personality profiles, others suggest just matching based on skills. They tried a variation on “speed dating”, they call it “speed matching”. In our organization, we let them pick each other. The mentors decide to be mentors, publish a little piece about their mentoring style, and mentees get to leisurely browse the profiles and talk to the people until they find someone they want as a mentor. The two parties then decide if there is a fit.
2. Implementing the program: They suggest using a written development plan for the mentee to help focus the mentoring efforts. They referenced a Harvard study to demonstrate the value in writing goals. We use something similar where we have mentees work from an organized list of skills areas for the growth path we want people to go through.
3. Wrap-up: They do a graduation from their mentoring program. This is different than our mentoring program, which is always ongoing. I believe their structure to it suit their need of growing a set of highly talented newer resources for a period of 9 months each year.

Mentoring requires time and resource commitment from both parties and management to put time in it, and for the most part they seemed to have that. Also, it’s worth mentioning that some of the specific BA skills are not trivial to mentor. They didn’t really address this aspect at all, but from my own perspective that the average person isn’t necessarily going to be good at mentoring something like elicitation or facilitation skills. In the end, I think they do some things very well. I cannot stress enough that our mentoring program is a work in progress to say the least, so I'm thrilled to hear about some others trying to set this up as well.

They suggested a couple of books on mentoring:

1. Strength finder 2.0 - Apparently there is an online tool to help you identify your strengths, and the book helps figure out how to apply those at work.
2. Mentor and Mentee Guides

Live from BAWorld: A Case For Visual Models

I heard a presentation at BAWorld, but for this one I won't mention who it was, because I'm going to critique it in a very specific way. The talk wasn't bad per se, but one thing about it really bothered me. You see, the speaker displayed a slide that was supposed to convey traits of an effective team. The slide contained a circle with 16 lines coming out from it (like a sunshine almost). Each line had a trait on it, for example "committed", "conflict management", "self directed", etc.


The speaker then asked us "What traits are missing?" And my immediate reaction was to go to a place of "Seriously? You want me to read a list of 16 things and tell you something meaningful that is missing?"


So this is another fine example of Miller's Magic number, aka 7 +/2, where the human brain can only hold that many things. So by the time I get to item 10 out of 16, it's unlikely I remember the first.


Add to that, the ideas around the wheel aren't parallel ideas, so it's even more frustrating. If you are going to make a list like this, make them the same type of word - i.e. verb, noun, etc. Ideally they should be of similar type too, but that's harder to measure.


And finally, if you are going to use a visual to display your list, that's great, except that it needs to be one that actually organizes the information in a way that is useful. A circle of lines did not help organize the list. Maybe if he had grouped items together, there would have been 7+/2 items at the first level, with a few branches off each of those.


People did play along and shout ideas, but honestly, I thought the ideas overlapped with what he already had up there. Who knows.


This whole example is simply more justification for why we use visual models to represent information. With an appropriate model choice, we wouldn't have to remember 16 things, it might have helped force a parallelism, and finally it will help organize the information.

Live from BAWorld: Getting Your Stakeholders to Help You

Marie Bankuti from Tether Free Vision presented “Help Me Help You! How to Proactively Educate Your Business Stakeholders for Greater Project Success” this morning at BAWorld Boston. She discussed the typical challenges to project success that we see on projects and had the audience contribute. The ideas the audience came up with included conflicting interests, trouble articulating a vision of success, business users were cocky and thought they could do it without IT’s overhead, no time from the business, and pressure to hit dates and cannot focus on what is really needed in that time.

To summarize Marie’s suggestions:

1. Understand your stake, meaning vision or mission. Understand yours, your users’, your IT groups’, your and company’s.
2. Nurture your relationships, including understanding the people who you work with, their pains, and even what they do outside work.
3. Explain your process. Do this through things like case studies of it working or not, and just explaining why it’s needed.
4. Define expectations. Make sure it’s clear how you each will communicate, what the roles and responsibilities are, and what accountability there is.
5. Ensure credibility. This means things like disagreeing tactfully and with respect, collaborate, follow through on commitments, but in general model the behavior you seek from the teams you work with.

All in all, Marie gave a nice general overview of how to get teams to work with you.

Live from BAWorld: A Funny Start to the Day

A couple of us from Seilevel are representing at Project Summit & BAWorld Boston this week. So in typical form, we’ll be blogging live from BAWorld as the inspiration hits us.

This morning’s keynote talk was by Simon Cotter and it was on “The Power of Humor in the Workplace”. He’s a real estate/sales guy turned standup comedian. Now, I have to admit, it was a bit early in the morning for me to be laughing out loud, but I did find him amusing. It was a creative keynote. Frankly, I tend to find keynotes typically too broad to be applicable or by people who have big names but aren’t necessarily great at presenting. This guy actually kept me engaged for an hour and certainly handled the crowd well. His general point was about how to use humor to develop relationships. If you do that, people simply will want to work with you. And then he had more practical tips about how to do this if you don’t think you are funny - things like using safe jokes, quick wit, self-deprecation, and physical objects.

I completely believe in this concept. You know, I look forward to the funny people coming into the office every day. Who doesn’t love a good laugh? And you don’t have to be an overall comedian, just amusing sharing anecdotes with the crowd can make your coworkers chuckle and bond a little. In our training, we try to add some bits of humor to keep the students awake.

Anyway, there are 2 points I think are important in using humor – keep it appropriate (sexist and racist jokes are off limits) and keep it in check (we are here to get a job done, not just to be funny). Can you think of times where people were relying so heavily on their humor that they keep you from actually getting to the point? You just want to make sure everyone is engaged with your humor and move on to complete the task at hand.

Ok, so I feel like I should end this with a joke. Here goes:
A Business Analyst and a Project Manager walked into a bar....
Ok wait, unfortunately, I got nothing! Feel free to add some funny comments though.

RE'08 Follow-up: Teaching About Unknown Software Requirements

At the REET08 workshop, Ray Barnes presented a paper “Teaching the Unknown and the Unknowable in Requirements Engineering Education” written by himself, Donald Gause, and Eileen Way.

In their paper, they talk about the need to accept that the "unknown" and "unknowable" exist in requirements.

Confusing? That is - "You don't know what you don't know."

And while it is challenging for a requirements engineer to deal with, it is still a very necessary skill. Their paper is specifically focused on teaching students about the uncertainty and how to work with it. They have the students do “real world” problems and give them specific techniques to deal with the uncertainty. The students seemed to experience the expected frustrations of not having all the answers in these problems.

I thought it was interesting that when they taught a specific technique to the students (through lecture), the students still didn’t apply it, even amidst their frustrations. The paper gives an example of teaching students about Toulmin’s model of logical argumentation multiple times. Finally the instructor helped 1 student use it, and later that student offered to present it to the class. It wasn’t until this last step - the student explaining the concept and value - that the rest of the students really got it.

That’s probably pretty typical of learning in general, both in that they have to experience to understand it and peers can be very influential in teaching. In fact, one of our favorite training games is called Each Teach from Thiagi, where we split the class up and lecture them on different topics, then ask them to teach the topics to one another. We have had outstanding success in students’ perceived understanding and actual understanding of the topics.

I found it to be an interesting talk and had some questions that came out of it:

1. How does unknowable relate to the untestable in requirements? There was an INCOSE paper that talked about the idea some requirements cannot be written in a testable format, so you can do risk analysis on these to mitigate the issue. Similarly, you might identify the areas that seem most unknown in your requirements and focus more time on those specifically. Or weight your risks and priorities accordingly.


2. How do you document the unknown or unknowable? If you have an area that you know is still fully undiscovered or in some way vague, it should still be tracked. Perhaps in an RM tool, or even in an issue tracking list as things to be further discovered. And certainly a risk list, as per point 1 above. Ideally you would document as much as you do know and flag it in some way for both follow up and just as a warning.


3. Do other industries have this issue with the unknown? Surely it’s not just systems and software, so what do other industries do to deal with the unknown? Probably a lot around risk analysis, but this is just a guess.


4. In teaching something like this topic of uncertainty – both in awareness and the skill to navigate it - how much of it is something that just has to be experienced in order to learn it? There isn’t always a black and white answer to how to approach the unknown. My thought is it’s probably 95% experience, with 5% teaching them helpful tools to try out.


5. When doing the real world exercises, can you write scripts for the instructors to use in role playing on how to be vague? I haven’t really tried this formally, but it sounds fun. And hard! In fact, related to the unknown problem, how can you predict what the students will ask in order to have pre-scripted responses?


6. I think one of the most important things in an experiential exercise is to debrief afterwards. I’m not sure if they did this here, but it wouldn’t surprise me. You put students in what is probably a frustrating exercise, and afterwards you need to talk about the experience, let them explain what was hard, and have them explain what they learned.

RE'08 Follow-up:Questions About Reinforcement Pattern in Teaching Software Requirements

At REET08, Sascha Konrad presented “The Reinforcement Pedagogical Pattern for Industrial Training” by Brian Berenbach and Sascha Konrad from Siemens Corporate Research. They outline a pedagogical pattern called the “Reinforcement Pattern” in which you teach the students a concept (including any definitions), give them a couple of examples of the concept in context, do one or more exercises together, and then relate a set of concepts together using a team exercise.

Their paper talks about how this works well in industry requirements education.

The questions that this paper made me think about:

1. Can you use this pattern when you are not always with the students in person? This is something we are just beginning to develop more thoroughly, but I hope the answer is “yes”. I know of someone at DePaul University who does a distance learning course where many of her students are remote. She does her best to make the examples and exercises work for remote students. They seem happy with it as well. However, there probably is some impact to not all being physically in the same room. It’s harder to share the students’ practice work and teach from it if not everyone can see it. The team discussions students have will not be as easy if they cannot all just gather around a table for 3 minutes in person.

2. Is it more important that the instructor have experience at instruction or at requirements engineering? This is something we have long debated. Currently we put an emphasis on instructors having requirements engineering experience, and we teach them to be good instructors (or select the requirements engineers that are naturally good at it). However, a good instructor should be able to learn enough about the subject matter to facilitate a good learning experience even if they haven’t done it. My concern is they don’t have the stories from practice to relate to the students. But perhaps those can be learned.

3. Is customizing the exercises to be specific to the context of the students important? For example, if you are teaching students from a mobile phone group, should your examples relate to mobile phones specifically? We have courses that are taught in a public forum, so we cannot be specific to all students in your examples and exercises. Therefore it seems to work to use generic examples and exercises, but be ready to address how they can translate the practice in the course back to their job.

How to Deal with Conflicting Processes When You're Writing Software Requirements

As requirements experts, we are asked to gather requirements, using a variety of methods, from many sources. We are then expected to compile a comprehensive list from these sources.

On a recent project, I was asked to go into a customer’s manufacturing facility and observe the manufacturing technicians going through their daily activities to collect requirements for automating some of their activities. At the end of the observations, I was to present the customer with a documented process flow so that the development team could create the automation.

What do you do when every single one is different?

For several days, I was the guy following people around, making them nervous and asking a lot of "What did you just do" and "Why did you just do that" type of questions. Once all of the data was gathered and compiled, I found that of the four work shifts I had observed, each had its own way of doing some of the tasks. I needed to present the customer with one unified process.

Once the differences were identified, I needed to find a way of standardizing the process flows. These are the steps I took to combine the 4 into 1.

1) Does The Difference Really Matter?
The first thing was to determine if the difference between processes really mattered. Many of the steps were the same but executed in a different order. I spoke to the technicians that I had observed to ask why they did it one way and not the other. I also asked them what the impact would be if the steps were rearranged.

2)Move Low Impact Steps Around
For the steps that really did not matter, I made the decision on where to place them based on the feedback I had received. I created a process flow and asked the technicians to approve the “To Be” state. Once I had received their approval, I began to address the steps that remained.

3) Go With What You Have - And Get Feedback.
For the remaining steps I had to use a different process. First, I documented the difference as well as the technician’s reasons for the actions. Next, I presented the information to the management team and asked them to tell me how they wanted these activities to be completed.

When you're faced with multiple processes from every user, take a moment and break the information down to the steps that really matter. Once you've separated the wheat from the chaff you'll have a good idea of what to get approved and what to toss.