User Stories: Currently user stories are written by our external agency (product owners), although we have a lot of internal project managers that are not part of this process. Obviously some miscommunication happens in the formulation of the user stories. One possble solution could be to transfer the responsibily of writing user stories to the internal project managers that act more as product owners, whereas the former external product owners act more as consultants.
PIG - The Process Innoation Group at XXXL Digital
At my department "XXXL Digital we are working on the eCommerce system for the three brands "Mömax", "Möbelix" and "XXXLutz" in Austria and several more European countries. The eCommerce ecosystem has grown for over fire years with hundreds of eCommerce members involved. Although the software development is agile, the phases before - requirements definition, prioritization and concept - are done in a waterfall manner. This has many reasons, but the major effect is that the output in the software is very often not the initial requirement of the stakeholder or the customer. This is the reason why some of my colleagues and myself are working on a solution that I want to share with you.
The first step to introduce a new solution was to create awareness in the whole department and especially on the top level. Therefore, we painted the current process with the current pain points, as for example mismatch between requirment and feature implementation, overall too long product development process from idea to solution, no transparency how and when a change request is implemented and so on. Along the process we positioned so-called development potentials, what we believe is a lever to reduce or remove pain points at the end of the process. Just to get a feeling for the term "development potential" here are some examples:
Waterfall Design vs. Agile Sprints: As mentioned the concept phase was done in waterfall mode and only at the end of this phase the developers are integrated in the process. This leads again to miscommunication when the developers don't understand the designs or worse the designs are not possible to implement cause of technical reasons. One potential solution could be to parallelize the development and the design sprints and integrate a cross-disciplinary team with designers and developers working towards the same shared solution.
Project End: Currently there is no defined end of a project or clear communication to internal team members or external stakeholders. Moreover, if there are any problems with the implemented feature there is no structured communication coming back from the stakeholder or customer that is unhappy to the project team. Mostly the developers and designers think that their work is done and they were successful. One potential solution would be to integrate a shared project retrospective at the end of each project with interal and external team members as well as the stakeholder.
The idea behind the development potentials was not to solve each of them, but to find a setting where all of these potentials could be addressed in a structured way. More concrete there should be a regular repeating meeting with specialists to work on solutions for this potentials and present them to the top level and the entire department. If the solution is agreed on it is implemented in the product development process. The working title was "PIG" which means "Process Innovation Group". We have set four ground rules that have to be considered to be successful at the end:
- Team-based: The setting has to be based on several team members instead of one person to decide each and everything.
- Process-based: The setting has to defined as a process and not in people. So, at each meeting there is a protocol, a document space for communicating and archiving the results, and changing roles in the meeting itself.
- Expert-based: Each sub department should choose a representative for the meetings who knows its processes best.
- Time-and-target-based: Each development potential has a specific time horizon to be solved, a value how important it is for the entire product development process and a responsible person to work on potential solutions.
The meeting started a few weeks after the concept was presented to the top level of the department. The members were forced to spend time for solving process inefficiencies and reflect their own processes and behaviours. At the end it is a very social process and a facilitator or agile coach is recommended to avoid too emotional discussions.
Gallery
Feedback
Back to top