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

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.

Live from RE'08: Recreating Industry in an Academic Course

I wanted to spend a few minutes writing more about the first paper from this morning, again that was Requirements Engineering Education in the 21st Century, an Experiential Learning Approach, presented by Gil Regev. In his talk, he described the design of their Requirements Engineering masters course. This class effectively simulates an end-to-end practical project for the students. In the last 2 years, they increased the time spent in this project on the business, RE, and specification topics from 7 to 11 weeks of the course (out of 14 total weeks).

He goes on to explain that industry is full of “wicked problems”, where the problems are difficult to define for all stakeholders, there are no clear stopping rules, they have strong moral/political/professional dimensions which cannot be easily formalized, and there is often no objective measure of success. Their course design is a bit unconventional – which I love – the intent is to reflect industry realities by maximizing confusion, not giving the rules of the game out, and stating goals that are not the actual learning objectives. Also, they do not grade the experience in order to create an active fearless learning.

They give the students vague a problem statement around management believing sales are suffering because of customer support problems. The instructors play the part of subject matter experts, going as far as to dress in costume to clearly separate their role as non-professor. They point out this probably does requires business savvy instructors.

In the end, the students say they would have done better if they knew the rules, if they had theory about RE before they did the exercise, and the course is chaotic. If only! Though at least one student shared a retrospective in which she recognized after the course while working at a company, that this course was in fact simulating the real world.

This class is going to be very hard to replicate in industry (as a training), since it takes 14 weeks and 6 hours a week. And even for the instructors, it is very time consuming to teach it – partly because they play the role of subject matter experts, and partly because they need to do some amount of redesign every year on the scenario so that students don’t hear ahead about how to do the exercise – as it would take away from the learning.

All that said, I like it. I like that they are trying to recreate an industry problem and teach it in academia. And sure, they can’t simulate it exactly, but this is one of the better attempts I’ve seen at it.

Live from RE'08: Learning Research

This morning, Mike and I attended the Learning Research track where we heard 3 research papers presented on the topic of learning.

The first paper was Requirements Engineering Education in the 21st Century, an Experiential Learning Approach by Gil Regev, Don Gause, and Alain Wegmann. I’ll talk more about this one in my next post.

We also saw Gameplay to Introduce and Reinforce Requirements Engineering Practices presented by Renel Smith and Olly Gotel from Pace University. This is based on Renel’s research which lead him to develop a game called RE-O-Poly, to be used to train students on some basic requirements knowledge. In case it’s not obvious from the name, it is based on the game Monopoly. I've been watching Renel's progress on this over the last year and it's nice to see the game growing. I'm certainly a big fan of using games to train, so I think there is some interesting work here.

Finally, Thomas Alspaugh presented Marginal Notes on Amethodical Requirements Engineering: What Experts Learned from Experience by himself, Susan Sim, and Ban Al-Ani. This talk was based on interviews and survey they did in 2006 of various RE’s – what their most important skills were, experience levels, etc. The 5 themes that came out of their feedback were: spanning bridges, communication, selective process, doing less, and business value.

Live from RE’08: Learning Days for Us

Yesterday was the Requirements Engineering Education and Training (REET08) workshop and today was the beginning of the main conference. So when I say they were “learning days”, I mean more than 2 days of us learning - I also mean that most of the talks we heard were about learning, a topic near and dear to my heart.

Mike summarized the workshop well, however he neglected to mention the talk he gave during the workshop. He presented our paper titled “Effective Design and Use of Training Games”. This talk was about specific games we designed for our Req101 training course. Given the nature of the workshop, he was able to actually play one of the games with the participants, and they absolutely loved it. In fact, some of the participants are looking to use the game ideas in their own training programs. One of the neat things about this year’s workshop is we spent end of the day sharing classroom activities with one another for reuse. I had co-chaired this workshop with Jane Cleland-Huang from Depaul University in Chicago and Didar Zowghi from University of Technology, Sydney Australia - so it was really exciting to see it finally come together and have so much participation (25 people!).

Today’s first session was “Training & Lessons Learned”, with the first paper presented by Brian Berenbach on a survey he did of a requirements engineering training program he did at Siemens. He was able to survey the students quite awhile after they took the course, which in itself is a neat thing – to find out what the students found most useful to them from the training course. This would be great data in order to influence the design of your courses in the future. The last talk of the session was by Sascha Konrad, also of Siemens and was about the challenges and solutions of doing requirements engineering on large-scale systems. The challenges they face at Siemens are certainly common to many large organizations – for example, there are many requirements to be managed, their customers’ expectations can be hard to manage, and the teams are globally distributed. And the talk in the middle was actually my talk, based on a paper I wrote with Mike, titled “Games-Based Requirements Engineering Training: An Initial Experience Report”, in which we describe the learning theory behind using games in training and talk about specific games and experiences from our visualization course. The talk seemed to go over well, and I got some interesting questions.

• If you have large teams in your activities, how do you deal with the problem of some people checking email or wandering out of the room and letting the rest of the team do the work? The short answer is that you talk to them individually if it happens. But at the core of it, we are using games in our training in order to avoid this exact problem – we want the students to be so engaged that they want to be there.

• Have you used the games internationally, how well does that work? We have not done much internationally. One of our courses uses Jeopardy, and we did teach it internationally. They understood it but were not as excited by that particular game. However, over the next few months we’ll be internationalizing our courses, so we will have more to say shortly.

• Have you thought to use different types of members of the audience to play different roles in games (i.e. RE vs developer)? We have not. We do have different types of audience members, but typically they are all there so they can learn to speak the same language about requirements, not to use the content differently per se. That said, there is a possibility to do this, but I would have to give it more thought. And we do one exercise in our Req101 class that does actually put the students in the role of a developer.

• What is Jeopardy? (this was a follow-on to our discussion about using games internationally from someone non-American) We laughed at his question, as it made exactly the point about international audiences not understanding USA game references. Most of our games are not actually based on US games, though some are and will need altered. But to answer this, I did explain Jeopardy.

The final session of the day was the panel on “Transforming the RE Classroom Experience”, with Jane Cleland-Huang, Don Gause, Olly Gotel, Zhi Jin, Pete Sawyer and Didar Zowghi. They each presented a snip-it of information about their university courses and then opened it for discussion to the group. My favorite question was (and this is biased since I asked it), how did Jane change her classroom activities for her distance learning (DL) students to be able to do them. She records the courses and they watch it online the day after the in-course stuff. And it turns out she does let the DL students watch the activity performed by the local class, so that they can learn from the local experiences. She then asks them to do the activity on their own. Her feedback has been only positive from the DL students in how this works. There was also a good discussion around whether universities should teach current industry practices or new ideas from research – the consensus is that it’s mostly 80% current practices with a little bit of new to send out into industry.

All in all it was a fun-filled day!

Live from RE'08: Requirements Engineers are smarter than Rocket Scientists

Did you know that you're smarter than a rocket scientist? Seriously! In a presentation at the Requirements Engineering Education and Training (REET08) workshop today, one of the presenters talked about his experiences with teaching Requirements Engineering (RE) techniques to European space agency employees, most of whom had PhD's in math and/or physics -- actual rocket scientists! As part of the presentation, he said that those scientists said that they weren't able to do RE, and that it should be left to people who had those skills. So kudos, RE community -- you're smarter than rocket scientists!

In other (and only slightly less exciting) news from today's workshop, we heard a lot of great ideas from academics and industry professionals who teach the next wave of Requirements Engineers. Tony Gorschek presented his current conundrum in teaching RE, namely that he has only 5 weeks of instruction time to deliver the only RE course in his school's program. Which topics are most important? Do you teach students to write clear, concise, testable requirements, or do you teach them to be great product managers who understand business realities and can plan product releases accordingly? Yes, we did suggest that he teach both, but time constraints won't allow it. And appropriately enough, time constraints in the workshop kept us from discovering the answer!

Several presenters explained that they teach their programs' RE courses at or near the end of students' educational programs. The rationale for the placement of the classes is that students must understand how to be good software engineers before they can understand, apply and appreciate RE skills and practices. At first I thought this was the right order, but as the day went on and we heard about more and more challenges of this approach, I began to wonder if placing RE education at the end of software engineering education sends the right message. If something is as fundamental as we believe RE to be, then shouldn't we make it a fundamental (rather than a capstone) element of RE education? Would the answer be different if the RE courses were part of a different degree program, like Industrial Engineering or Information Systems?

Finally, we talked quite a bit about the disconnect between industry's needs and education's focus, including training both in academia and in industry. Education in RE seems to provide controlled, well-formed, somewhat artificial problems for students to solve. Unfortunately, most of the projects we deal with in industry are subject to political forces, impacted by fickle market conditions, and just plain messy. How can academia best provide Requirements Engineers with both the problem-solving skills and the ability to deal with messes needed to do their jobs well.

Clearly, we identified more issues than definitive answers, but also we came up with a number of great ideas and new tools to help teach Requirements Engineers (and improve our own work on projects). All in all, it was a very educational day.

It's been a great first two days at RE08 -- stay tuned for more exciting adventures of the Seilevel team!