Live from RE'09: New Ideas for Requirements Activities in Distributed Teams

Olly Gotel from Pace University presented work she has done with colleagues from around the world in a paper titled Distributing Responsibilities to Engineer Better Requirements: Leveraging Knowledge and Perspectives for Students to Learn a Key Skill. Olly started this talk by telling us that she had done something crazy with this project, and then went on to explain how they had essentially five different teams working on a project from five locations around the world. They were each supposed to write requirements for a software development competition, with requirements teaching and coaching help along the way from professors and experienced students. As she went on to describe the experience, many of us from industry chuckled with her out of empathy – her experience is so similar to our worlds today where the teams are distributed worldwide and chaos ensues!

There are a couple concepts from Olly’s course design that I think would be great to replicate in industry – either from a training perspective or project execution. The first one is related to creating competition to improve results. In past iterations of this learning experience, Olly explained they had issues with the students not understanding the value of producing quality requirements, which naturally resulted in poor results. So this time they had the teams compete with one another by creating the same deliverables and having the client choose which solution was best. As expected, the competition significantly increased the quality of their work products. We have done this with our training courses – introduced friendly competition through game playing and I’ve been pleased with the level of engagement. However I think there is something interesting to think about here with respect to injecting a different type of friendly competition into project execution in industry. Fundamentally the big turn-off to this idea in industry is that there are five times the costs to create the single project – so it's a lot of throw-away work. But, if we think outside the box a bit, perhaps we can divide projects into chunks (or just use multiple projects) and have the requirements sub-teams compete on quality of specifications, requirements issue resolution speeds, project success rates, etc.

In this course, they used an apprentice model with coaches who were students that had previously completed the requirements engineering classes. Now I think this is something that absolutely applies as-is! You can just have mentors who are more experienced people mentoring the more junior resources in requirements activities – ideally pairing them up on the same projects.

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