It is sometimes beneficial to ramp up a large software step by step. This promises doing earlier business, reducing risk and gaining momentum. Just slicing a large development into arbitrary pieces will however not work well. Teams need a bit more strategy so that each delivery is useful and provides significant value. This article introduces business scenarios and 6 slicing patterns that help product owners and agile teams to align incremental product development with growing the business.Continue reading
5 approaches to integrate UX skills and professionals into organizations
Over the last years, many companies adopted user experience (UX) good practices and hired professionals. Some created centralized teams of UX consultants, other included designers into development teams, yet others created a team to contribute a design system or user research. This article is a collection of five approaches on how to include UX skills and UX professionals into organizations, open for discussion and refinement.Continue reading
From exciters to liabilities
Classifying customer expectations, Noriaki Kano created the well-known Kano model more than 40 years ago. I felt this model deserves a more in-depth presentation on stars to road for a couple of reasons: First, it helps to prioritize features over the lifetime of a product. Second, it points to typical issues you encounter during product development and provides hints how to improve. Third, it is not too difficult to assess the categories and they are easy to understand. Fourth and most important: you need good understanding of customers and markets to work with the model, a real indirect benefit! All in all, the Kano model is an important foundation in product development one should know.Continue reading
Iterations and increments
In software development, some functions can be discussed, implemented, tested and then shipped. Other functions need several iterations to really build the right thing in a good way. Incremental building and iterative development are completely different things and need different approaches to manage.Continue reading
The ten questions sheet for retrospectives
Retrospectives are great to improve collaboration in teams. To add to the many options available, here are ten or so questions you can use for you team retro. The questions follow up key success factors and have the potential to reveal blind spots of a team.Continue reading
Creating user experiences – an organizational view
Some companies take a quite structured approach to creating user experiences. Others create user experiences unwittingly. Looking back, I detected six principles in regards to creating user experiences.Continue reading
Requirements – an agile answer
Understanding what people need and require from a product is important. So requirements are important. But what is a requirements and what are “good” or “bad” ones? I set forth to find the ultimate answer and found 42. So lets add a bit more structure and talk about the problem, solution and the conversation side and conclude with a question: where should the development team invest their energy: into creating the specification or into discussing the best possible solution given the constraints?
The case of a relevant UX problem
This is not about a Sherlock Holmes mystery and no engineer lost a thumb over it. Even though the machinery involved could easily achieve the latter. It is about industrial robots and tons of machinery to fold metal sheets into origami swans. But mainly it is about a case where creating the right user experience solved the relevant problem.Continue reading
The purpose of …
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?Continue reading
Customers, users or fans?
The stuff I find most exciting is making something work for the users or to put it in more modern terms: people have a great experience when using something I helped create. So I focus on users and user experience. Some people rather talk about customers and customer experience. Whatever the name, it is basically the same isn’t it?Continue reading
UX in a burn-out system – UX Brunch in Zürich
At the UX Brunch in Zürich on December 6, 2019 Rahel and I held a presentation and some very engaged discussions on how we as UX professionals ourselves heat-up the burn-out systems we are caught in. Here is a summary including some of the slides of this session.
By Markus und Rahel *)Continue reading
Dialogue in a park
It’s quite easy to rush through creativity workshops enumerating, rating and selecting ideas to hand-over for later implementation. This article is however about a different kind of creativity, the creativity that comes from gaining deeper understanding – together in a workshop.
By Beatrice*) and MarkusContinue reading
Team disorder: Featuritis
Teams form an entity – and they can have disorders. There are a couple of team disorders worth looking at. One of them is Featuritis. And here is the not really serious medical guide to this disorder.Continue reading
Agile conversation or requirements engineering?!
Requirements engineering (RE) has a long and successful tradition. Different approaches always existed. Still it is optimized for an artifact driven setup: Individuals pass on documents. Agile practices are however geared for an interaction driven setup where individuals form one “super-brain”. The discussion about requirements is part of the agile conversation. And now, the proven approaches from RE suddenly create friction and bad smells. So, should we forget about requirements?Continue reading
Collaboration creates teams
Getting a performant team needs an investment into the team. Agile inspect and adapt is meant to do the trick. Instead of frantically or stoically pulling a cart with square wheels, a team should be able to spot the fault in the system and improve. Observation: teams surprisingly often do not do so.Continue reading
Burn-out machine game @ agile breakfast in Zürich
On March 6, I had the opportunity to play the burn-out machine game with about 40 agile consultants in Zürich. We spent two hours with engaged discussions and insights about the very serious and highly relevant topic burn-out. We even had a good time doing so.
The team wall – or agile knowledge management
Here’s the situation: A customer asked us to improve the quality of their core system so that they again can act on the demands of their users and customers in a timely manner. We had a team room at our disposal and we again made extensive use of the walls. It turned out that the team wall made the difference!Continue reading
Keep knowledge alive – living documentation
Keeping knowledge about a product alive is no easy task. Software teams struggle with manually mainting vast documentation in UML tools, text documents, wiki sites and more. We all know about the amount of effort and dedication needed to do this well given the amount of redundancy. There is a promising vision of a living documentation, i.e. a documentaiton automagically created from those things the teams create anyway, like automated and manual tests, backlog items, meeting protocols and more.
The Team Squeezer or the story of an agile transition
An important management tool to improve team performance is the Team Squeezer. It’s really simple: just use hierarchical power and exert pressure to make the development team hurry up. Usually the Team Squeezer backfires.Continue reading
The stars to road innovation framework wouldn’t be complete without the concept of stories. The story decides the fate of the innovation. It can prove to be very powerful.Continue reading