Delivering Business Value with Agile Approaches to Requirements, continued

This post is a continuation of a previous post found here.

Changes Dave believes are coming with respect to agile-run projects and my own commentary on these:

• Requirements engineers make decisions, they are not just documenters. Expect to see that product owners are the BAs. They will less often be called systems analysts, and more often called product owners. A few years ago, we shifted from calling our requirements team members “Business Analysts” and started calling them “Product Managers” because that’s really what they have to do – own the product, even if it’s just an internal IT system.


• BAs/Product Owners will be empowered to make decisions and not just sit around waiting on sign-off. They must be experts in the business. They must work with development, not just document for them. Once they do this, they can start to make very smart decisions about what should or should not make it in the product.


• Agile is not a fad, even NASA is doing it. That said, we will see variations on agile as it grows and evolves.


• The development team can add value about requirements, so collaborate with them. They don’t all just want to gold-plate scope or push back on what’s in or out – they love to build products, so use that to your advantage.


• The business is not always right, so you still need to ask questions. BAs/Product Owners must push back when something doesn’t make sense.


• Agile is actually seen to increase the value of requirements – just make them more solution focused, and not just about doing lots of documentation.

And finally, Dave made my favorite quote from RE’09: The difference between UML 1 and UML 3 is that we moved the stick hands from being straight out to angled downwards. He can make jokes like this since he actually worked on it!

Delivering Business Value with Agile Approaches to Requirements

I attended a keynote at RE’09 in Atlanta that I wanted to go back and post a summary of and my thoughts on. And just to be completely honest, this is a rarity. For whatever reason, I really tend not to get much value out of keynote talks – either they are too technical, the speaker isn’t great at well, speaking, or they are so out there I cannot engage in it. Today was different though, it was captivating for me. This one was given by Dave West of Forrester Research. The talk was titled “Developing Business Value with Agile Approaches to Requirements”.


To be fair, he had my attention at the first slide – it was a picture of a dog doing agility. When I talk about agile, I use such a picture too since I personally do agility with my dog! Anyway, the content of the talk proved to be interesting. Some will say it wasn’t anything new. Others will argue with what he said. But for me, his ideas were very tightly aligned with our experiences and ideas about agile and requirements so I like that it built on what I already knew and gave me new ideas to think about. The great thing is he has a much larger pool of resources to survey and confirm his ideas. Here are a few of the points of interest.


He talked to what is being adopted with respect to agile and among those things: Agile itself is being adopted. Scrum practices are as well. He also sees engineering practices such as early testing, integrated builds, and re-factoring. But most of note, he is most commonly seeing a hybrid of approaches– more of an agile than an Agile approach. I think this is relevant as I hear company after company say “agile didn’t work for us”. In reality for many companies it probably doesn’t in its purest of form. Or perhaps it requires trying it more than once, learning from mistakes (do we really think Waterfall worked the first time either?!?!).


Some really positive things he believes we are seeing now include frequent delivery, increased business involvement with more collaboration, and changes in team organization towards smaller teams and more of a team focus in general. His thought on when agile is best used: Complex projects where there are problems to be solved and the solution is unknown.


Dave spoke to the common friction points between traditional requirements approaches and agile:

• Delivers requirements vs collaboration on the product
• Where in the process you engage vs. iterative
• Requirements that are out of date, long/hard to read, solution focused, take way too long vs. collaborative and timely requirements

Some of the issues that you must be careful about with agile: Often the customer has no time because they are doing their day-job (the one you are trying to help in some way with software!). There are often many customers to involve in the requirements efforts, not just one or two to quickly jot down stories with. The customers are often distributed so you have to bake in time to work with all of them alone and together. Agile is reliant on good communication but stereotypically, developers don’t communicate well. We cannot ignore analysis - processes require analysis and solutions require thought - so take time to do these.


I will continue this post in a day or so with thoughts on changes that Dave thinks we are starting to see, as well as my personal thoughts on his thoughts!

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 RE’09: Taking Distance Requirements Training to a New Level

Didar Zowghi gave one of the most interesting talks at REET'09 I’ve heard in awhile titled Teaching Requirements Engineering to the Baha’I Students in Iran Who Are Denied of Higher Education. She was asked to teach a distance learning course on requirements engineering to these students from Australia to Iran.

She basically runs the course by teaching lectures using audio and displaying the lecture slides using Skype or LiveMeeting. However, they ran into issues with everything from bad audio connections, students who couldn’t see the visual slides, and even power outages. One improvement made eventually was to record her lectures so students could download them to play if they couldn’t hear for some reason during the live presentation. As a bonus, Didar said she learned of things she could work on by listening to herself lecture for the first time!

She had assignments for the students as well, but specifically she had a project where they had to interview a stakeholder to elicit and document requirements. She had a Teaching Assistant located in Iran who played the role of stakeholder – sometimes in person, sometimes by phone. She had the students use Karl Wieger’s templates since those were also easily downloadable.

Didar also makes time to chat with students – they might Skype her for example to find a time to chat verbally. I like to think of these as virtual office hours!

I found Didar’s talk to be so interesting based on the circumstances behind it – a great culture lesson that I thank her for. But I also find it quite relevant as we work to roll out global training programs. I am sometimes overwhelmed by the idea of how we will possibly have successful training with people on the other side of the world, but the reality is – you just make it work.

Live from RE'09: Contextual Requirements Experiences within the Software Enterprise

Kevin Gary from Arizona State University presented Contextual Requirements within the Software Enterprise at REET’09. He discussed their approach in having a multi-year project-based engineering course sequence, allowing for iterative exposure to all concepts - but particularly of interest: requirements engineering. This very much fits with popular learning theory – the idea we need to put concepts in front of students repetitively for them to really learn them. For their projects, they reach out to industry to find candidate projects so the students get to work with real subject experts to solve real problems, ultimately producing real deliverables. What I like about his style is that he is less interested in whether the company gets their perfect solution out of this work and instead he is more interested in whether the student is learning the concepts. But in reality, it sounds like the companies are getting a lot of value out of it!

One of the challenges Kevin spoke to involves how you assess students in courses like these. One thing I do like that I haven’t seen often is that he tries to check in with industry managers that hire his students to see if they are coming out of the ASU program more prepared.

So what I like about Kevin’s discussion first of all is that assessment of students is hard! We see that too and it was a big topic in an REET panel later in the week at RE’09. But I really think it’s great to see universities with programs really aimed at setting the students up for success in industry after graduation. And the final point I’ll make is that he’s absolutely right about needing students to practice the lessons lectured and hear them more than once. I think this is a major flaw in much of the requirements training offered to industry right now. We send students in for a class and then expect them to get it all - typically without revisiting the materials again.

REET’09 Went Off Without a Hitch!

Monday was the Requirements Engineering Education and Training (REET) workshop that I co-chaired with Ljerka Beus-Dukic. I’m always nervous about how these things will go – there are so many unknowns with the environment, the presentations, and the timing. However, I’m absolutely thrilled with the end result! We had 6 papers presented and it varies from a normal conference in that we had big blocks of discussion to really dive into some of the commonly shared issues in this field.

We had a lengthy discussion mid-afternoon around how do you really teach anything about requirements to students in a semester long class (or less!) and where does requirements training fit in the overall teaching of the software lifecycle at a university level. The thought is that most people learning about requirements in industry aren’t brand new to software development, they already understand a bit about coding and verification, so they understand the value and context for requirements. Yet trying to teach it to a freshman class would leave the students thinking “why do I need to know this?”

Another key point that is important at all levels is repetition in the lessons they receive. It came up again in the context of academia, where they may teach it to freshmen, and then they need to re-teach it throughout in other classes. This isn’t specific to requirements certainly, just a basic principle of good training.

We also talked quite a bit about how you assess the students in and after training. This is a long standing BIG problem across academia and industry. One issue with assessing whether any behaviors changed in an academic environment is that you teach it and they may use it on a project, but then you never see the students again. One participant actually tries to talk to industry contacts who hire the students to see if they see better results from his students. In industry, it’s very hard to isolate whether results are attributed to training. We can look for modified behavior, but this requires a dedicated resource to do so. I’ll probably talk about this more in a day or so, since we have a panel related to this on Thursday!

We then ended the day with 3 different sets of training activities presented with the intent on getting any participant feedback on the activities, but also leaving the workshop participants with the opportunity to take the exercises back and reuse them. At the very end, we played one of our Seilevel training games: Bet on Yourself Pictionary – it was fun because I was working with a group of people who are already familiar with requirements models in some form and so they could play our game – which basically enlists 2 “students” to act as analysts drawing requirements models for a specified scenario, trying to get the rest of the class to elicit the requirements from them. Oh and they had to do all of this without speaking. It was great fun and if nothing else, a lively way to end the day!

Live postings from RE'09 next week!

It's one of my favorite times of year, time for the IEEE Requirements Engineering conference! RE'09 is just around the corner, starting next week in Atlanta, GA.

I'll be co-charining the Requirements Engineering Education and Training (REET'09) workshop on Monday and then attending the main conference the rest of the week, with 2 panel appearances that should prove to be interesting.

And as always, I'll be blogging LIVE from RE'09! I hope to see some of you there, find me if you are attending this year!

Register now for REET09 and RE09!! Early registration ends Monday

Please join us for an interactive discussion at the Fourth International Workshop on Requirements Engineering Education and Training (REET'09) in conjunction with the 17th International Requirements Engineering Conference (RE’09). The workshop will be held in Atlanta, Georgia, USA on August 31, 2009.

If you have any interest in training and education in the fields of requirements engineering, business analysis, or product management - this will be an exciting day to learn about new ideas in the field!

Following the success of the first, second, and third International Workshop on Requirements Engineering Education and Training (REET 2005, 2007, and 2008), this workshop will address issues related to RE education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching skills needed by an effective requirements engineer.

REET'09 Workshop - Call for Papers - Due June 29

This is just a reminder that the REET09 workshop, held in conjunction with IEEE's Requirements Engineering 09 conference, is in Atlanta this year on August 31!

I'd like to encourage all of you to submit papers or training activities related to educating people on requirements! If you don't feel like you have enough to do a paper, you could even just submit a fun activity you've done to teach people about them. Here is the workshop site with more details, but the important one is that papers are due June 29.

http://users.cscs.wmin.ac.uk/REET09/

If you aren't interested in this workshop, the greater RE'09 workshop should be a big one being based in the US this year, so I hope to see lots of you there!

REET'09 Workshop - Call for Papers

Hey everyone, I'm co-chairing the REET09 workshop again this year. It's held in conjunction with IEEE's Requirements Engineering 09 conference in Atlanta this year. I'd like to encourage all of you to submit papers or training activities related to educating people on requirements! If you don't feel like you have enough to do a paper, you could even just submit a fun activity you've done to teach people about them. Here is the formal call for papers:

The 4th International Workshop on Requirements Engineering Education and Training (REET09)
Held in conjunction with the 17th International Requirements Engineering Conference (RE09). The workshop will be held in Atlanta, Georgia, USA on August 31, 2009.
http://users.cscs.wmin.ac.uk/REET09/

PAPERS DUE ON MONDAY 29 JUNE

This workshop will address issues related to RE education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching skills needed by an effective requirements engineer.

Papers are solicited in any of the following areas or in any other area related to Requirements Engineering education or training:
* Curriculum design for undergraduate and graduate courses. Incorporation of RE topics into more general SE and CS courses. Curriculum for industrial training programs.
* Techniques for teaching specific RE related skills such as stakeholder identification, requirements elicitation, negotiation and consensus building, requirements writing, and other critical RE skills. Specific examples of educational tools, exercises, and assignments.
* Reports on surveys and other studies conducted into the effectiveness of various teaching methods. Assessment methods and practices of RE knowledge and skills. Strategies for assessing of learning soft skills. Methods of objectively measuring assessments.

Papers will be accepted in either of the following formats:
* Position papers (3-5 pages) - Short papers stating the position of the author(s) on any of the topics within the scope of the workshop. For example, positions papers could describe experiences with a particular method for teaching an RE related skill, or could describe an innovative approach to incorporating RE education into the degree curriculum. Position papers will be evaluated based on their potential for generating discussion, and on the originality of the positions expressed.
* Full papers (8-10 pages) - Full papers describing requirements engineering educational techniques, survey results, or experiential reports. For example, a full paper might describe a specific technique for teaching an RE skill and include a case study describing its implementation and evaluation of its effectiveness as well as lessons learnt. As another example, a full paper might describe a mature tool for supporting RE training.
* Pedagogical activity papers (2-4 pages + supporting documentation) - Pedagogical papers will describe a teaching activity and provide all of the materials needed to reproduce that activity in the classroom. Authors of full and position papers, plus anyone else interested in attending the workshop are encouraged to also submit a pedagogical activity. Teaching activities will be documented using a predefined format, and will focus on one or more RE skill, define target audience and learning goals, provide step-by-step guidelines for conducting the activity, include student hand-outs or associated slides, describe the context of the activity, and briefly comment on its prior use in the classroom.

Submissions will be reviewed by at least two members of the program committee for relevance to the workshop topics of interest. Accepted submissions will be archived in a workshop proceeding in IEEE Xplore. Papers must be formatted to conformto the IEEE Computer Society proceeding guidelines and submitted electronically in Adobe PDF to the EasyChair service:
http://www.easychair.org/conferences/?conf=reet09

Workshop format:
The format of REET09 will be an interactive one focusing on practical ideas and approaches for teaching RE skills and for constructing effective RE curricular. Paper presentations will be used to foster discussion. Demonstrations of specific teaching techniques and materials will be encouraged. The workshop will conclude with break-out groups working on specific topics such as the initiative for sharing RE resources or discussing RE curriculum and developing appropriate templates.
We encourage the following to submit papers and/or to participate in the workshop:
* Educators currently teaching or planning on teaching RE courses
* Academics intending to integrate RE content into existing more generalized courses
* Practitioners interested in developing or improving RE training in the workplace

Important Dates for you to remember:
* June 29, 2009 - Paper Submission
* July 20, 2009 - Author notification
* August 3, 2009 - Camera ready
* August 31, 2009 REET09 Workshop

Workshop co-chairs:
Joy Beatty joy.beatty@seilevel.com
Ljerka Beus-Dukic l.beus-dukic@wmin.ac.uk

Program Committee:
Ban Al-Ani University of California, Irvine, USA
Ian Alexander Scenario Plus Ltd., UK
Dan Berry University of Waterloo, Canada
Al Davis University of Colorado at Colorado Springs, USA
Don Gause Binghamton University of the State University of New York, USA
Vincenzo Gervasi Dipartimento di Informatica, Universita di Pisa, Italy
Martin Glinz University of Zurich, Switzerland
Olly Gotel Pace University, NYC, USA
Ellen Gottesdiener EBG Consulting, Inc, USA
William Heaven Imperial College, London, USA
Ivy Hooks Compliance Automation, Inc., USA
Soren Lauesen University of Copenhagen, Denmark
Emmanuel Letier University College London, UK
Lemai Nguyen Deakin University, Australia
David Randall Requirementeering, Australia
Lucia Rapanotti The Open University, UK