On paper, customer-centric design and agile software development are a perfect match: agile teams thrive on creating customer and business value, and designers offer concrete methods for understanding customers and facilitating change. But even though dozens of frameworks and methodologies have been created to organize teamwork and streamline processes, the reality is far from a honeymoon. Teams are constantly facing the same challenges and people feel things could be better.
When we talked to 60 people in 30 different projects, we found that often:
- Designers feel burdened by the number of mixed tasks. Too little resources combined with poor coordination turns design into a bottleneck that threatens the agility of the whole team.
- Too little up-front design work causes hot fixes which stress everyone, break the flow of work, and lead to case-specific solutions that do not support the bigger picture.
- Business goals miss clarity and focus, leading to a constantly shifting direction which frustrates teams. They deliver features instead of value, which reduces autonomy, motivation, and commitment of the team.
- Customer-centricity is not embedded in the team culture. The responsibility for customer value is not shared amongst the whole team but falling on the shoulders of already exhausted product managers and designers.
- Agile is not deeply understood but just “acted out”. Teams try to adopt existing agile frameworks straight off-the-shelf even if they seldom fit for them. Following a framework without evolving together is not agile, really.
We can make design and agile work better together
There’s a lot of value to be grabbed here. People and teams could be happier and more committed (which by the way is the key to success). Organisations could create better products faster and get more value for their investment to design and development overall.
Instead of being on the outskirts of development teams, designers could facilitate the team and the surrounding organisation to improve. Better armed, they could create disproportionate impact. But just adding a designer in the team doesn’t guarantee you all the benefits: there needs to be both depth and width in design capability and customer centricity. And most importantly, design and development need to work toward the same goals and share processes, methodologies, tools, and team culture.
Free relationship therapy (in a book form)
We asked designers, developers, product managers and other agile folk about challenges in design collaboration in agile teams. Now we’ve collected the findings into a workbook. Through examples and tips, the workbook helps teams to understand their challenges and to improve their ways of working together. Hopefully it inspires you to develop the best approach for your team, so that you can create world-class products and services for your customers and stay happy and healthy doing so!
We’d also love to have a chat with you to share, care & learn more together. ?
“There are only two hard things in Computer Science: cache invalidation and naming things.” (Phil Karlton)
Let’s face it, devops is an incredibly bad name for what we are talking about. The origin and the development of devops has been mostly organic, which can cause problems when one tries to specify what something is and isn’t, especially when it comes to ways of thinking and how to approach problems. So, it is natural that something already hazy gives birth to even more haziness, in this case to DevXOps.
What the DevXOps assume, is that the devops is limited to the developers and ops personnel, and if we were to stay in the original idea to get the two, and ONLY the two, talking to each other, it would be absolutely right. For every additional field, there would then be yet another part added to the term and to include everything, the resulting term would be “DevQAUXSec… … Ops”. Whenever there would be only specific set in the team, there would be a different variation of it. Not only would this be impractical, it would also be highly confusing (which the current DevXOps terminology already can be).
Another interpretation is that the X represents what feature is emphasized in the overall process. This just raises more questions than it truly answers:
- why something needs to be emphasized over the others?
- does DevSecOps then mean that security goes above everything else, and quality assurance and user experience do not matter that much?
- is it necessary to use a different term rather than simply (and explicitly) state “devops with emphasis on security”?
- should the approach be changed from one to another, when the emphasis or the theme changes (e.g., from DevSecOps to DevQAOps or DevUXOps)?
The organic evolution of the devops also makes it much more difficult to understand, and it seems people are divided on what it contains and what it doesn’t. The thing is, devops does not really contain anything, but rather guides us to do things better. We need to remember that most of all, it is a way of thinking, a philosophy, and there can never be a product that could be counted, but it is possible to say that we follow the devops principles. But then, how to determine if something is or is not following the devops way of thinking?
Let’s take a look at my definition of devops from https://gofore.com/en/devops-101-pt-1-journey-to-enlightenment/:
“DevOps is an anthropocentric organizational and cultural movement, and a philosophy with a goal of improving organizational and SDO (software delivery and operations) performance, productivity and the quality of the service.”
I have defined devops by what it aims to achieve with two main constraints:
- People are at the center of it
- It is limited to software development
The first constraint aims towards sustainability. The intent is not to gain more by squeezing every possible ounce of will and energy out of employees, just to discard them afterwards. The second constraint limits the methods to the context of software development.
Now, to guide our thinking process, let’s ask some question:
- How can we improve the performance and the productivity…
- …of the organization?
- …of the teams and the individuals?
- How can we ensure the quality of the service or the product as it is perceived…
- …by the end users?
- …by the developers?
From these questions, we can design the following core mind map:
The next step would be to take some higher level aspects (culture, psychological safety, processes, security etc.) that we know to have an effect on the four objectives. By adding those to their right places (at least mostly), we get:
The goal matters
While the mind map is not all-encompassing, it should point out the key points, from which we can move towards the finer details and ask even more questions. In many cases on the performance and productivity side of things, the things to consider are applicable to other industries as well. However, as long as we keep in our minds on the why, we can say that they are part of devops philosophy as well.
A good example of when something belongs or doesn’t to the thought model is the automation. We can teach that it is a good practice to automate everything and that it reduces the amount of repetitive manual work, but alone, creating pipelines or tools is just plain old software automation. When we add the why to it so that we do it in order to leave more time for the developers to be productive, to make it repeatable, to reduce memory load and so on, then we can say it is practicing the devops way of thinking.
As an example, let’s add a few things to the mind map:
- Measurements (not strictly a process though)
- Culture of experimentation
- Culture of trust
- Well-being (see: https://gofore.com/en/devops-101-part-3-psychological-safety-and-recovery/)
- Stress and frustration (negative relation to well-being)
- Continuous Integration and Deployment
Yet again, not an all-encompassing view, but does give the idea how things are related and where everything could belong (notice that there are some shared aspects as well).
So… what now?
So now we can say that devops is everything and nothing. It is a software development-related phenomenon and a way of thinking aimed at being more productive through removal of silos, amongst many other things, while keeping the quality and the humans involved in a key role. The “need” for DevXOps might rise from the organic evolution of devops, the birth of folk models of the devops (more on this in https://gofore.com/en/devops-101-pt-1-journey-to-enlightenment/) and the bad name of it, but in the end, if we keep in mind what kind of problems the devops philosophy tries to solve and in what context, there is little that falls outside of it. This is the source of its inclusiveness. To understand the relations between all the different things, keep in mind the two constraints (anthropocentric phenomenon, software development) and the core questions:
How can we improve the performance and the productivity…
- …of the organization?
- …of the teams and the individuals?
How can we ensure the quality of the service or the product as it is perceived…
- …by the end users?
- …by the developers?
How to create High-Performance Teams?
Where to start? There are three things every team member can start doing immediately to foster team building:
1. Frame the work as a learning problem, not an execution problem.
2. Acknowledge your own fallibility.
3. Model curiosity and ask lots of questions.
This is a great place to start. If you are interested in more detailed and longer approach, continue reading.
Two perspectives to building high-performing teams
Google researchers believe people can do more working together than alone. Here is their proposal of the characteristics of a high performing team.
According to Patrick Lencioni there are 5 hierarchical levels of dysfunction that might be blocking the way of the team being high-performing. (Patrick Lencioni, 5 Dysfunction of a Team )
The levels are objects that prevent the team from reaching their full potential. In other words, by winning all of these barriers, teams are able to scale their performance almost infinitely and in a sustainable way!
In my experience fixing the absence of trust is “the 20% of work which you get 80% of results”.
Absence Of Trust, Level 1
We trust who we know.
How well do you know your work colleagues? Their hobbies, ambitions or personal background? Forming closer connections with your team members, leads to improved team collaboration. You’ll learn what fires their ambition and keeps them motivated.
– Personal Maps, Improving team collaboration
Absence of trust is the first of five significant factors which prevents teams from reaching their full potential and the high-performance state. It is caused by people are unable to show their weakness and true self in front of others.
Absence of trust causes:
- Time, resources and energy are wasted because of people are building “protective shields”.
- There is a huge barrier to ask or even give help inside the team.
- People feel the need to be invulnerable.
- Team meetings (all) are ineffective.
- People are trying to hide mistakes.
What happens when trust is achieved?
- Innovations are enabled! People aren’t afraid to speak their thoughts and there is no need to be afraid of being mocked by anyone on team.
- Cooperation improves radically.
- Psychological safety is reached.
- Failures and mistakes are shared openly and they are used as opportunities to learn.
How to reach mutual trust?
To practice vulnerability and to improve team spirit can be easily done with the Personal Map method. Personal Map helps team members to share experiences while everyone gets to know each other better (goals, passion, worries and so on). Psychological safety is prerequisite for teams to be proactive. Without trust and safety team members cannot trust that working for team goals also helps them to reach their own goals. Without trust and safety team members will set their own interest before teams interests when making decisions.
Trust is knowing that when a team member does push you, they’re doing it because they care about the team – Lencioni.
Here is how to create a Personal Map (Absence of Trust)
A) Personal map for the whole team
Use this in a team building or retrospectives. Any mind map tool can be used, but I prefer using tools like Miro or Mural. Here is a link to anonymous Mural login: team map. Please contact me, if there are any problems with the Mural.
You need to have an account to use Miro. If you prefer Miro over Mural, here is a team map for you.
Follow these steps when using the team map:
- Create copies of an empty Personal Map for every team member.
- Split the team into 2 person groups (or any other suitable group).
- Randomly give 2 team member names to teams where they are not part of.
- Fill Personal Maps for persons whose name you got.
- Time cap 20min (10min/person)
- Use Post-Its to fill Personal Maps.
- Fill everything you know about the target person in your group.
- Important thing is that in this phase target person is not allowed to participate in filling Personal Map information.
- After Personal Maps have been filled
- Group by group present your Personal Map to target person and rest of the team.
- Target person can fill “gaps” in a way he/she wants.
- Target person can reveal as much or as little information as he/she likes.
- Go through every Personal Map
- This will take time about 5-10min/person.
- That’s it!
- Main point in Personal Map is that it is first created by other team members (that way teams find out how little they know about other team members)
- After that anyone can reveal as much as they like from themselves.
Note! Save your team’s Personal Maps to a common place where anyone can access them if needed.
B) One Person at a time
This is useful when a new member joins the team. The same links and instructions work with this option. The most important thing is that target person is not allowed to participate filling of their own Personal Map. Other team members must do it first. After the Personal Map has been presented to the new member, they can fill in the gaps.
There are also other tools that you can utilize to create psychological safety. Check them out in here.
“A team feels psychologically safe to its members when they share the belief that within the team they will not be exposed to interpersonal or social threats to their self or identity, their status or standing and to their career or employment, when engaging in learning behaviors such as asking for help, seeking feedback, admitting errors or lack of knowledge, trying something new or voicing work-related dissenting views.” – Amy Edmondson
The Personal Map is a very easy method to implement with any team. It is suitable for introverts and extroverts as you can reveal as much as you like from yourself. Do you know how you can grow the feeling of relatedness in your team in order to achieve trust and flow state within a team?
Technical Project Manager (Scrum Master, Agile Coach)