atrify has been continuously developing the agile product development process over the last few years. Here we provide some insights into this process and how it has matured from the first stages, into our current customer-centric agile product cycle.
Two major aspects influence the content of our releases: the input received our strategic portfolio management and what we as product owners generate as ideas, and secondly the feedback received from the community and the active application users.
Feedback is the Key – quantitative and qualitative!
We are investing a ton of effort in to gain knowledge about what our users want.
Regular customer surveys provide us with quantitative feedback about their satisfaction and missing features. It is usually done in the form of questionnaires, which allow answers based on a scale as well as open questions about missing features.
We have been measuring the Net Promoter Score for the last two years and performing a system usability test. The Net Promoter Score is a recommendation rate, and that value should ideally increase with every new survey. The system usability test is carried out in the form of a standardized questionnaire to obtain quantitative feedback on the usability of the software.
We gather valuable quantitative feedback via business analytics or feature measurement with Google Analytics. We can see exactly how often particular features are used in our applications or collect information about aborts in the user journey.
This provides us with valuable information on how to improve specific processes and features, but on the other side, we know which features are not well received and where we should simplify and purify the software if necessary. It offers a tidy user interface with only useful features and pleases developers with less complicated software.
Simplicity — the art of maximizing the amount of work not done — is essential.
Based on the surveys mentioned above, we repeatedly respond to isolated feedback in the form of user interviews and seek personal contact with individual users.
Usually, these user interviews are based on negative feedback. It is often worth investigating what caused negative feedback and how the situation can be improved. Quite often, there are quick wins that can be implemented quickly and easily to improve.
We Listen
As a 100% subsidiary of GS1 Germany, we also work with GS1 organizations around the world. We operate our application in their countries and under their patronage as a service. In this case, these GS1 organizations act as multipliers in their markets. They have the best knowledge about retail and the industry, as well as the processes and expectations.
“We listen” is a unique format for these key customers. Those customers have the opportunity to exchange about the activities in their markets and let us know about their needs for change and wanted feature requests. It is not uncommon to emerge across various organizations due to similarities.
Not just the direct, but also the long line to the customer provides essential insights. We work closely with sales and potential customers, as well as with the support department and active customers. Support has the closest ear to the customer and knows most of the time, exactly how the customer works and how he uses the application. This is indispensable when it comes to discovering and clustering problems in the implementation of our software.
Strategic portfolio management
Anyone who has ever dealt with Dr. Klaus Leopold’s flight-level model will know how crucial strategic portfolio management is and how agile working methods must also establish themselves in the upper floors of a company.
Prioritizations for initiatives, features, and projects has to be discussed, and a holistic understanding for the things in work has to be created.
Goals that are supported by features in the applications, or that require broader and holistic adaptations of the software are just as much input from this board as paid customer adaptations or more significant initiatives which can affect several products at once.
Pre-prioritization of product ideas
Lots of ideas and features embrace the results from the first area with its various survey methods, as you can imagine. We, as product owners, can spend time on the most important things for the product instead of discussing features that won’t make it into the product soon anyway. We prioritize these ideas roughly in the first step.
At this point, a so-called MoSCoW matrix helps us. This matrix is elementary and offers four quadrants with the categories Must, Should, Could, and Won’t. While the Must section represents the essential things for the product, Should notes valuable features that are also worth implementing, but not necessarily with the next or after next release, because they don’t cause rejection by the user if they are not implemented.
Then there’s the Could section, which collects everything that makes sense when time and resources are left, and the Won’t section. And last but not least, the question of why to add a won’t section to the matrix if you don’t plan to do things anyway is undoubtedly justified. This serves the visualization that these topics are not considered meaningful by us, mainly because the board is reviewed regularly, and these topics are known to everyone then or can be discussed again.
Scaling@Atrify
We have several agile teams working in different areas. Some of them are divided up into products, but they are also subject to change when some major topics or initiatives need to be implemented. A current example of this is the conversion of software from Oracle persistence to PostGreSQL. Or a massive data quality initiative of our parent company.
The whole thing reminds a little of Less if you look at this visualization. Our Chief-PO coordinates dailies with the POs for the individual teams as well as bi-weekly in more detailed rounds.
Our teams usually work according to pure scrum. I.e., they have their daily scrums, review meetings, refinements, and planning.
Some of the review meetings are team-related, but it also happens that several teams present their results within a joint review meeting. The review dates are displayed on a board in our employee lounge, so everyone who wants can participate. Additionally, the video conference code is on a post-it due to the capacity limits of our meeting rooms.
Deliver often
We deliver a release every six weeks nowadays. That’s about eight releases a year, twice as much as in the past. Changes to the attribute model, code lists, or validations are even more frequent and often released on demand.
We started back then with a Quarterly Release, and at that time, every delivery felt like an adventure. Challenges for the rollout were, i.e., far-reaching code changes over more than twelve weeks, various underlying technologies coupled with adjustments to the data model.
The modifications that we now make within six weeks are mostly manageable. The more frequent deployment frequency also ensures that deployment becomes a routine rather than a challenge.
Deliver working software regularly within weeks or months and prefer a shorter period.
The six weeks have proven as useful best practices for delivery. Even shorter release cycles wouldn’t make much sense because we often have features that can’t be fully completed within one or two sprints. We also seem to be in prominent company with a six weeks cycle. Google, with their Chrome Browser or Mozilla with Firefox, deliver at the same frequency.
Development & Release Cycles
We develop three sprints at two weeks on a release, then go into a two-week code freeze phase in which the release is thoroughly rechecked before the customers also receive a two-week test phase. The release with the new features goes into production only after these two phases.
Pre-release notes, as well as a final version of the document (there will also be last-minute changes, which will then be explicitly re-tested), keep customers informed.
Hot requirement changes even late in the development process are welcome. Agile methods use changes for the customer’s competitive advantage.
Usually, the whole company is drummed together every two releases, and there is a product launch date. The new features in the software releases are presented to a broader audience by the product owners then, live on the systems and with support of marketing slides! This helps everyone in the company to keep updated regarding further product development. This helps especially our Support department to prepare for the new features and potential customer demands.
That's all, folks
That’s enough about our software development process for today. At some point, I started to visualize the process as such.
My head is already full of new ideas for further development in the future. In particular, drivers such as test automation and the future redesign of our product management will influence this.
But also the regular exchange with a robust and agile community in Cologne offers suggestions and brings new ideas to light.
About the author
Daniel Haupt is a certified Product Owner at atrify and responsible for the agile product development of solutions for industry and commerce. He always enjoys learning new approaches and methods in an agile environment and likes waterfalls only in the great outdoors.
