Stable? Fragile? Agile! Attractive but reasonable

Topic of interest

An organization that is just converting to an agile approach is faced with many challenges. General parameters have to be rethought, responsibilities and roles have to be critically reflected and job profiles might rotate by almost 180 degrees. How does that affect the role of the requirements engineer? How does my life as a requirements engineer look like, when my organization is operating agile? Unfortunately, these questions are not that easy to answer as they depend strongly on various factors. In this article, we are presenting some of these factors. What further comes to our minds as agile-enthusiastic analysts is the question of how we can efficiently and effectively support a company in the process of transformation.

To begin with: Is your organization actually appropriate for a transition?

Unfortunately, a transition to agile methodologies does not work universally and, hence, is not always successful. In our view, the first step an organization should take is to pose the question: do agile methodologies actually fit to its corporate culture? Being a requirements engineer, you occupy an intermediary role between management, specialist departments and IT and thus have a clear appreciation of the nature of your company’s corporate culture. That is why you should be involved in evaluating a team’s, or the company’s, readiness for change. When it comes to assessing your company, we recommend you to have a closer look at Schneider’s Culture Model to be able to identify your own culture more accurately ^[1]. Depending on your initial cultural situation, the possibilities for introducing agile methodologies are more or less restricted.

If you are situated in a culture of collaboration or cultivation, no major cultural changes are needed. Depending on the culture’s focus, some modifications regarding aspects affecting collaboration might be needed. The Agile Manifesto or Scrum offer excellent starting points within these cultures.

As a requirements engineer, you should stabilize the process by living the values which some team members might not yet be familiar with. At best, you, as an analyst, should use your communication skills and your effective empathy to have a positive impact on the new changes.

If you find yourself situated in a culture of control, you will have to leave most of your old culture behind. A transition entails a great challenge, will only advance in small steps and may take a long time. Staff changes, both on the administrative as well as on the management level, will be necessary. Also you need support from the Human Resources Department. This includes staffing the positions with people that are able and willing to live these new values. Although this might sound quite rough, keep in mind that there is no space for people who are not ready for adopting agile values.

The entrepreneurial value “control” has to be replaced by “trust”. You should, however, back away from only postulating these new values. The only route to success is authentically living these values. Moreover, employees need to be encouraged to take on responsibility.

You, as a requirements engineer, are in contact with many people and teams. You can help spreading the agile values with your particular communication skills. The large number of contact points allow you to set an example of living these agile values. Likewise, you can use your moderation skills when supporting the process of transition. Your ability to resolve conflicts will equally be in demand – e.g. when encouraging the management to reduce its need for control and, in return, establish a culture of mutual trust.

In cultures of competence, a transition will also not be easy. Above all, a common understanding of “the team” has to be established. Integrating under-achievers in the team will pose the greatest challenge. High-performers might enjoy more attention. It is important to cleverly take advantage of already existing expertise. Here again, the Human Resources department and the management have to do more than merely supporting the process. An authentic team spirit has to be put in the foreground and rivalry has to be prevented ^[2].

For you as a requirements engineer, it should go without saying that besides possessing specialist expertise and analytical skills, qualities such as empathy, the ability to handle conflicts and moderation skills are of even higher significance in an analyst’s life within an agile surrounding. Hence, you might support the process of change as a role model ^[3].

In a nutshell: The first step is to reflect on your company’s already existing values. Be honest with yourself! It might be that your culture simply does not fit in the agile world. If this is the case, only two possibilities remain: radically transforming your organization or not getting agile!

Career perspectives for requirements engineers in an agile world

Your organization should develop a strategy to reconcile classical career perspectives and staff development plans with a transition towards agility. The Human Resources Department and the management face the challenges of putting aside former vertical career aspirations and motivating a rather more horizontal development. This is not going to be easy! In the scope of this article, we consider some examples of changes in the career of a requirements engineer.

In traditional process models, an analyst’s vertical career looked like this: You have started your career as a junior analyst. In this phase you have supported an experienced analyst in rather uncritical projects. As an experienced analyst, you have handled your own projects and have ventured into more critical projects. As a senior consultant, you have been involved in making strategic choices, for example on the introduction of new methods in whole departments or the training of other analysts. Being leader of the Requirements Engineering Team could constitute a further jump in your career. In this position, you have been responsible for the company’s alignment regarding requirements engineering and you have been responsible for employees and projects; the reason for your promotion lies in experience in various projects, training and certifications.

At this point, the question comes up, what could be an appropriate goal for your career as a requirements engineer in an agile context. In the following, we will focus on Scrum as an example due to the limited extent of this paper.

Why don’t you have a look at the characteristics that a requirements engineer should possess (see figure 2). You will detect many characteristics that also mark out a Product Owner, a Scrum Master and a good team member in the Development Team.

How about the role ‘Product Owner’?

Besides your competence in eliciting, consolidating and describing/imparting knowledge, it is especially important to also have a high level of expertise in a Business environment. This is necessary, for example, for being able to assess the investment of a story or for prioritizing a story’s significance or urgency. However, also in classical projects, the analyst usually has a profound knowledge of specialist matters – what he anyway does is to continually question and document exactly these. This career opportunity entails not only having to take responsibility for the system with regard to the later users. You also have to acquire the economical perspective in order to be able to value the Return on Investment. The Development Team sees you as the person who makes the specialist decisions.

Career path: As a start, have yourself certified as a Product Owner. As a requirements engineer, it will be worthwhile for your career to first assist a Product Owner in a project (this will most probably also benefit the Product Owner). Practical experience and profound theoretical knowledge (e.g. by getting a certification) build a thorough basis for your career path as a product owner.

How about the career opportunity to be an important member of the Development Team (an IT-allrounder)?

What is relevant in this position - besides profound requirements engineering know-how - is sound knowledge of other disciplines, such as architecture, test and implementation. Thereby you do not opt for people responsibility, but rather aim at being the conciliator in the team. With your skills in communicating, mediating and documenting, you, as a requirements engineer, will probably be a powerful conciliator in the Development Team. This career opportunity suits best those analysts who enjoy working in a team and do not necessarily want to hold a position with people responsibility outside the team.

Career path: Take profit from a profound training in Scrum basics. This helps in creating a solid foundation. On this basis you can start exploring one new field after the other. You can, for example, enter the field of blackbox testing, continue with a closer look at architecture and then consider intensively acquainting yourself with implementation (if your plan is to have a very broad basis).

How about becoming a Scrum Master?

As an analyst, you do not have a personal specialist interest in the alignment of a system – you are neutral. You are constantly in contact with lots of people, you are busy with moderating, solving problems, motivating and imparting knowledge. Doesn’t this remind you of the tasks a Scrum Master has to cope with in agile projects? If you chose to be a requirements engineer because it involves intensive contact with people and if the complexity of group dynamic processes has always interested you more than the intricacy of the specialist fields, then, becoming Scrum Master might be your perfect career vision.

Career path: Get trained as a Scrum Master and get certified. This certification training will address topics like psychology, group dynamics and the like although it will give you only basic know-how. It is vital that you get additional training in these fields (e.g. group dynamics/transaction analysis, change management and conflict management).

These are three options that could be open to you. At this point, given the abundance of options for certifications, Human Resources is in demand again – a good personnel Human Resources manager should be able to help you with the choice.

Or why don’t you just stay a requirements engineer?

Agile projects do not all operate the same – and above all they do not all strictly follow the Scrum rulebook. We know lots of projects which basically proceed agile. There is a Product Owner, a Scrum Master and a Development Team. But at the same time, there are requirements engineers, who, depending on team and approach, have many different functions.

Some teams place a requirements engineer at the side of their Product Owner (the role that is subject to the most pressure). The requirements engineer assists the Product Owner in eliciting, cutting and documenting stories. He solves conflicts. He ensures that specialist knowledge is excellently documented in the form of stories or possibly more detailed documents.

In other teams, one member of the Development team is focused on requirements engineering and documentation (user documentation). Verifying and documenting knowledge are the tasks that are most likely to be postponed or forgotten by other team members. It’s the requirements engineer’s job to prevent that.

It’s not necessarily that easy to start in the new agile world. Have a look at the next subchapter on agile recruiting. It’s the teams turn now to decide which role it considers suitable for you and which not.

Staffing

If you have now decided on transitioning to agile approach, a further, and fundamental, factor of success is good staffing

With regards to staffing, management and the Human Resources Department are in great demand again. Just an incidental note: Please take employment law matters on a national level into account as well. If you don’t, problems might easily come up and they might make your whole intention falter. In case you have a workers’ council please do not forget to include them. This mainly accounts for the European area. Of course you should consider the specific local conditions concerning employment law in companies that have a more global scope.

Back to staffing: The corporate organization has to understand which skills are vital from now on. Without grasping this, successful staffing is nipped in the bud. But how should you proceed?

In the same way as, for example, Scrum entails a new way of understanding values in the context of teamwork, why don’t you have a try at agile recruiting:

Create a job description together with your team, so that the whole team’s interests are represented. The whole team is made responsible for the selection process. You will be the ones working with the new team member, that is why you should have a say, too. Human Resources plays an accompanying and supporting role in this process. You can find first reports by companies who part with their external recruiters, develop their own common understanding of agile methods and e.g. involve the whole Scrum Team in making a personnel decision. Members of the team may also vote against a candidate – with a veto power – but only when they have a valid argumentation ^[5]. This then leads to a high individual responsibility and brings along a team decision that is supported by everybody.

Performance review and bonus schemes

A transition to agile methodologies involves a lot of further changes besides the new career paths for requirements engineers. From the perspective of the Human Resources Department and the management, one of the biggest challenges in terms of an agile transformation lies in the traditional compensation systems with their connection to performance review and bonus schemes. So, what does it look like when performance reviews and bonus schemes are placed under an agile framework?

In the agile scene, there is a huge debate about bonus schemes in general. In our view, there are three reasonable ways for giving out bonus under an agile framework:

• On the basis of clearly measurable performances (e.g. the consultant’s billable working hours for the customer; or the number of ascertained, consolidated and documented requirements by a requirements engineer in a classical team)
• On the basis of profound assessment (e.g. 360-degree feedback)
• On the basis of a decision taken by the whole team

It will be harder to grasp bonuses on the basis of clearly measurable performance, as the work steps intertwine in the context of teamwork. What might be more suitable are bonuses based on profound feedback. Especially Scrum’s focus on transparency makes the performance of a team immediately visible. Potential for optimization in the next sprint becomes clear very quickly. At best, the evaluation of the individual employees takes place in the context of the team. Since the team members work together intensely throughout the sprints, it is obvious that they can estimate best how they assess the performance of the other team members.

Against this background, the 360-degree feedback seems most appropriate. 360-degree feedback is suitable for conceiving competencies, achievements and the behavior of employees from different perspectives. In other words, selected people, such as colleagues, customers, peers from other departments, who have worked with this particular employee, receive a questionnaire and are asked to give feedback for the employee.

Or how about paying bonuses based on the team’s decision? New ideas exist for giving out bonuses in an agile and fair way. For instance, teams are provided with the grand total of the bonus and then have to distribute this sum autonomously. The approaches range from investments in new hard- and software, to team events, to distributing bonus by a transparent and disclosed assessment of one’s own performance. However, you should only go that way if you work with an established team. Do not forget about group dynamics – especially in the context of financial matters. So, why not dare to let your self-determined teams distribute the bonus by themselves? And if this does not work out – why don’t you jump onto the moving train and abandon the bonus! Unfortunately, there will never be the perfect way to distribute bonuses that is truly fair.

In an agile scope, classical performance reviews and bonus schemes are not intended or needed any more. That is why classical bonus schemes virtually become obsolete ^[6]. Does that mean that no bonus is distributed anymore? No, not necessarily. For one thing, you should not underestimate the labour law-related implications in this context. Benefits can easily become company practice or be dependent on the stock market law. For another thing, the workers’ council might have a say in these matters. Yet, with reasonable cooperation, a constructive solution will surely be found.

Conclusion

For many different IT-related fields, but also for whole organizations, a transition to agile methodologies entails major changes.
As has been considered in this article, the role of the requirements engineer alters in an agile context. New career paths evolve, which bring along exciting opportunities, but possibly also obstacles and limitations. Let yourself be accompanied by a profound management and professional Human Resources department.
As a requirements engineer, all doors are open. There are good impulses for learning and training in agile working methods, delegation of responsibilities and self-determination in a playful way. Why don’t you check out Jurgen Appelo’s Delegation Poker? In your role as a moderator, you can use the Delegation Poker to clarify who has the power to decide what matters and where the competence of the team starts. This is exactly what creates confidence! Get to know your team even better with the help of Moving Motivators! They playfully show which values are important to which member of the team and give the organization a proper chance to adopt new agile values.^[7]
We wish you much success in your agile future!

References and Literature

• [1] Schneider, William. The Reengineering Alternative: A plan for making your current culture work. McGraw-Hill Education, 1st edition, 1999. ISBN-13: 978-0071359818
• [2] Sahota, Michael. An Agile Adoption and Transformation Survival Guide: Working with OrganizationalCulture.
 www.infoq.com/minibooks/agile-adoption-transformation
• [3] Rupp, Chris und die SOPHISTen: Requirements-Engineering und –Management. 6., aktualisierte und erweiterte Auflage. Hanser: München 2014. ISBN 978-446-43893-4.
• [4] IREB Certified Professional for Requirements Engineering – Elicitation and Consolidation, Advanced Level – Syllabus. www.ireb.org/content/downloads/7-syllabus-advanced-level-requirements-elicitation-and-consolidation/ireb_cpre_elicitation_and_consolidation_syllabus_version_1.pdf
• [5] Brandes, Ulf, et.al. Management Y. Agile, Scrum, Design Thinking & Co.: So gelingt der Wandel zur attraktiven und zukunftsfähigen Organisation. Campus Verlag, 1.Auflage, 2014. ISBN-10: 978-3-593-50158-1.
• [6] Agil Anpassen! Häussling, et.al. www.haufe.de/download/personalmagazin-ausgabe-112014-personalmagazin-278212.pdf
• [7] Appelo, Jurgen. Management 3.0: Leading Agile Developers, Developing Agile Leaders. Addison-Wesley , 1. Auflage, 2010. ISBN-10: 9780321712479.