My teacher from Helsinki University, Department of Computer Science, has worked on combining human-centered design and agile software engineering at Reaktor since 2005, the beginning of that work. Also the product owner of a project I participated works now there as principal business consultant. I invited them to discuss how business customer requirements are taken into account in Reaktor processes, and we met for lunch. This issue feels currently relevant because customer requirements management is a challenge in our current project where scrum is applied. We met for lunch, and I also learned more when I participated a tutorial that my teacher and other Reaktor functionality architects led at the NordiCHI’14 conference month after the lunch meeting.

Four product management related patterns provoked thoughts:

1. Customer as Product Owner
2. One Epic at at Time
3. Facilitator and Coach
4. Customer Tells Organizational Goals

The first three were recognized based on the lunch discussions, the fourth on answers my university teacher gave to questions I presented at the NordiCHI’14 tutorial.

Customer as Product Owner. There is no internal product owner in Reaktor software teams. A customer representative takes care of product owner tasks instead. The most important thing s/he does is sorting implementation and design queu tasks by importance. Column Next green Post-It notes represent the priority queu of implementation work (figure below). The most important epic, which is ready by design and thus ready for implementation, is topmost in the list. Some epics still need interaction design before proceeding to the implementation work queu. Such are represented as red Post-It notes in the column Next. If there are several organizations as customers in one project, the product owner role can be taken care of by a committee of customer representatives. The epic considered most important by the customer(s) proceeds first to implementation, which is represented by the column In Progress in the Kanban board.

One Epic at a Time. Having roots in Kanban, all SW team members work together on a single epic at a time in the process model. The epic is represented by a green Post-It note that is in the column In Progress. Smaller, yellow notes next to the green note represent tasks that constitute the epic. To implement a epic takes typically four days calendar time, sometimes only a day, sometimes two weeks maybe. Epics are not pushed to a standard size of sprint because that would require overly precise work amount estimates. Estimates are considered ineffective because it has appeared that producing them costs more than it saves time.

Facilitator and Coach. At Reaktor, development teams take care of many decisions needed in software work. According to organizational psychology studies, tensions tend to accumulate in weakly managed teams because roles are often unclear and professional viewpoints diverse in decision making. Reaktor’s aim is to have a Facilitator and Coach person present in every software team. Her main task is to help participants whose viewpoints of a topic conflict to a shared understanding (“make it happen”). S/he leads discussion, but does not participate the actual development or design work, neither makes decisions herself in leader mode. Reaktor work takes normally place in Kanban, not Scrum, and Facilitator and Coach replaces Scrum Master in her way.

Customer Tells Organizational Goals. The “dream product owner” of my teacher has a clear idea what epics are essential for business and organizational goals, a service model vision. It does not make sense for a product owner to compete with Reaktor interaction designers in who knows users best because gathering user understanding is part of Reaktor service, and they do it very systematically and well.

In a Reaktor example project, prioritization played a stimulating role after product launch. The contexts of users’ and customers’ activities change when a new product is deployed. Also functional requirements change then. These changes are taken into account in cyclical service development processes (figure above). After the product had been launched in the example project, three epics were first prioritized over other epics. These epics prevented the organizational goal Extensive Utililization of New Software from being fulfilled. Launch had been monitored in Reaktor field studies. In the studies, parties who had not deployed the service yet were interviewed. After implementing the three epics, other epics that contributed to users’ goals were given top priority.

I will review the Reaktor patterns presented above and evaluate if they would be beneficial in my current work environment. My interest in product management has awoken when repeatedly ending up doing design of “every software project stage” simultaneously when working in agile projects. Such heavy multi-tasking increases stress and, in the long run, decreases productivity and well-being at work. For example, on a two days time period I was getting involved in long-term planning of team work, collected implementation tasks in a usability evaluation feedback meeting, implemented a javascript prototype, designed improvements for an online questionnaire and wrote a request for proposals of a user study. My tasks were about and around human-centered design, but little actual design was included in the example days.

When communicating priorities, the Customer as Product Owner pattern seems to prevent  “Chinese whispers” effects effectively. It also helps a software company to keep positive image in situations where implementing a customer’s wish is skipped. The diversity of customer wishes gets less, you needs less time for pondering feature requests and spare more time for the actual implementation of epics. The pattern seems to simplify also interaction design work. However, in order to really ease interaction design, such product ownership would need to be present in everyday customer requirements management, at least on a weekly basis. It seems unrealistic to expect so active participation in my current project. Although a steering group of customer representatives could be a workable solution in the project, several such committees and groups are already present, and have proved too laborious for active product management.

The patterns One Epic at a Time and Facilitator and Coach apparently ease interaction design work in agile and software development projects. With “less balls in the air” in a project, designers will also have less simultaneous work tasks. A Facilitator and Coach who knows human-centered design would ease especially concept level design because that work is combining requirements and needs that conflict, but also detailed design where negotiation with developers is typical.

Prioritization of epics is a starting point in the patterns One Epic at at Time, Customer Tells Organizational Goals and Customer as Product Owner. However, often an unattached service request, that concerns details of features that have already been implemented, needs to be implemented quickly. It seems that you cannot avoid implementing such single tasks when you further develop a service that has been brought to production earlier. These single maintenance tasks could be presented as small, orange Kanban board notes, that would have dedicated handling practices.

The pattern Customer Tells Organizational Goals connects the view points of Viability, Desirability and Feasibility effectively. This pattern would ease human-centered design activities also in my current project. A customer representative expresses their organizational goals in free form. However, when s/he represents a solution, you do not focus on her words, but try to “hear” functional needs, that the solution could serve, “behind words”. In this way, the approaches of user research, human-centered design and service thinking can be applied to customer understanding, not only to understanding users. Proposals that serve same or similar needs, but have different origins, can be covered with less functionality and higher quality. Although there is less to implement, software becomes more viable for customers and desirable for users.