Sometimes we do stuff without actually understanding the purpose behind it. We write user stories because we do and we miss the gist of it. Why are we doing it? Or to be more precise: what for?
Requirements Engineering
Requirements engineering, even though modern agile development teams do not know this term anymore, is something really worthwhile to understand. Requirements engineering really talks about one of the most important issue in developing software:
Requirements Engineering answers the following question: For what purpose is something so important, that we actually want to build it, given the costs and the constraints we face?
I don’t want to suggest that a requirements engineer should write requirements specifications for developers to read later like people did fifteen years ago (and still do nowadays with user stories). I propose that the development team should invest their creativity and critical thinking in answering this question. They should engage with the stakeholders and lead the conversation. By the way, the modern slang is continuous discovery.
Product Management
Lean start-up and agile methods added an interesting viewpoint on product management.
Product Management is about the following question:
What is the relevant problem of our customers and users where we can offer a really great solution they love to use and are willing to pay for?
Obviously there are important things like creating a business plan, making sure that the organisation can produce and deliver the product, that the country specific legal requirements are met and much more to do for a product manager. But what is all that good for, if customers and users don’t want the product or do not want to pay for it?
Meeting with users
I recently wrote an article in a great book about fifty things Zühlke engineers are passionate about. As a UX professional, my topic is meeting with users. I asked myself the question, why do we meet with users when we create products? My conclusion was inspired by Bill Buxton’s book “sketching user experiences”.
Meeting with users is about the following question:
How will the product we deliver change the world and thus how should that product be so it fits this coming world?
We desperately need more feedback from users and customers about what we are building. As an answer, companies started to collect a fantastic amount of data about what people do. Still, in the end, these things are just puzzle pieces that help us understand, how the future world will be. If we are a bit cleverer about how we meet with users, we can get a glimpse of this future and design our products accordingly.
Agility
Finally, almost twenty years after agile movement has reached Europe, it has also reached the management of many companies in my context. SAFe achieved this. Ok, agile has been tamed. It is reduced to the max: a well groomed backlog so companies can deliver software at a higher speed. At least this is where agile consultants as well as the most prominent frameworks like Scrum and SAFe seem to put their focus on. If we go back to the agile manifesto, then agile is about something completely different:
“A man with a tape recorder up his nose”
Sorry, automatic reaction, the circus flew over.
Agile is about the following question:
How can we change our collaboration so that we deliver the product as great as we can make it.
Scrum and SAFe can be good starting points for teams and organisation who strive to improve their collaboration towards creating great products. For all other organisation, they provide a well oiled garbage in garbage out machine. What a waste of energy in the second case.
Quality Assurance
An important topic: Makeing sure that the quality of a product or service delivered to the market is appropriate. Given all those insights stemming from the lean idea, it seems to me that quality assurance has one key purpose:
Quality assurance is about the following question:
How can we induce a culture of delivering the required quality into an organsation and a team.
It is important to test and even mandatory to have good regression testing. It is also great to investigate defects and to remove the cause of defects, so an organisation delivers better quality. All in all: a culture to deliver quality is what organisations need, rather than a culture to deliver features fast.
User Stories
User stories, epics, features, themes, capabilities and whatever name people invent for it, they clog our backlogs. Clever people take a lot of trouble to fill tools with masses of these things and describe them to the latest detail. And they miss the forest for all the trees. So lets stop this for a second and think back what user stories are and what their purpose is: My conclusion goes back to a presentation from Mike Cohn about effective user stories more than ten years ago: “The story text we write on cards is less important than the conversations we have.”
User stories are about the following question:
What functionality do we still need to talk about so we can deliver a valuable product to our customers?
User stories are a promise to lead a conversation about value yet to realize. If you want to create a specification, go fifteen years back to the use case method. This is an excellent tool for a written specification. User stories are just to lead the conversation, nothing more.
UI Prototype
Project teams nowadays create astonishing things with all those great tools like Figma, Axure RP, Adobe XD, Sketch and all the others around. But why do they do it? Is it the UX designer’s task to specify every detail of the UI with a high fidelity, interactive prototypes?
UI prototypes are a fantastic tool:
They provide a cheap way to enumerate options and to decide which one to take.
The good news is that one clever UX desinger can create a whole product in a few months without the need to involve any developer. The bad news is that the product the UX designer created doesn’t work, has conceptual flaws and specifies a product companies are not willing to pay the development costs. The energy wasted on high-fidelity interactive prototypes is just amazing.
Sprint
It seems that sprints are used for many different purposes. Having spent loads of time pondering about burn-out systems, sprints gained a completely different meaning to me.
For me, sprints are all about the following: A sprint creates rest areas where we slow down, take a deep breath, look around us, with an open mind, bewildered, lightly amused and reflect on what we achieved, what is still to come and what our next step should be.
Especially for organisations who think that agile is all about speed, slowing down is what you need. Get out of the rat race created by means of dark scrum, let your mind wander and ask yourself, why in the world are we doing it this way?
Roles
With this one, I’m treading on thin ice, I must admit. However, I constantly meet people who demand that we must define the roles for our team so everybody knows exactly what is their piece to work on and where they should keep their fingers off. Others want clear roles so they have the single-wringable neck they can twist. Both notions do not appeal to me.
Looking at what psychologist worked out, roles are important social constructs we create.
We assume roles so we can take our places in a social context.
In any social context we need to find our spot. We also need to find one in a software team. Sadly, the perfect spot never exists. Many of us also want diversity and potential to develop and the situation we are in and the team we are part of changes. Therefore, we copy roles, adapt them, test them and negotiate them with the people around us.
Talking about roles is part of this negotiation and necessary. Some of us need clear demarcation: this is for me, this is for your. A stable, clear system of roles. Others need freedom to change roles every day.
Agile teams favor people who are willing to make things happen rather than those who create their personal gardens. Keeping roles fuzzy and fluent is, in my opinion, the challenge for an agile team so it stays adaptive and team members can grow (or shrink if they wish) as well.
More purpose?
Many of the collaboration patterns we use when creating innovations have been developed with a specific purpose and setting in mind. And they have been optimized accordingly. To my regret, the real value is lost to many who apply the patterns and they try to achieve a different purpose or even just do it because it is the modern thing to do or someone told them to do so.
Quite often, nothing bad happens. The pattern works and the team benefits from applying it. Then again applying the pattern for the wrong reason backfires, the team becomes slower, less effective and they blame the pattern.
Given this, I probably have to come up with more purpose.