Being agile is cool. You do it because, hey, everybody is agile now – or at least they seem to be. I guess you’ve got familiar with the fun procedures, read three articles, convinced your team members and BOOM! You’re doing it. Or, are you?
I had a beer with one of my project manager friends recently. As the topic of work came up, she started complaining about her company’s Scrum method. She said it was too inflexible and had been causing more frustration than benefits. I had asked how they used it and she replied:
“We adopted it from a book.”
Adopting a process is not the best way to do things. Try to adapt it instead. Dig deep and find your challenges. Set up a research plan to reveal pain points. Involve stakeholders, interview your team members, and continuously improve how you manage projects. These are just a few things that can be missed along the way.
Let’s go back to the beginning. First things first, I recommend researching the crap out of the challenges. Feels too basic? Yes, but it is necessary to set a purpose for a new process created from scratch. And it helps focus on intents, as Abby Fichtner states in her article.
So, break down every thought until you find your main challenges. Here’s a silly little example:
Do interviews with team members. Ask more than one “why”. Empathize with them to learn what their pain points are, what they’re good at and what they hate the most. Learn how they do certain tasks they have problems with. And report everything you find.
If your company is far too big to talk to everyone, talk to the key people with the most pieces of information. Find their incentives and invite them to take part in the ideation process. Finding the purpose of agile together could help kickstart the collaboration.
Hard to convince C-level? You might want to know what each stakeholder’s desires are. Try to hire an agile professional who explains the benefits to them. Straightforward communication is also a key here.
Also, collect what you already have to form a foundation. Why change something that works? This way it’s easier to find what the missing parts are.
Here comes the fun part. As you are now aware of what you have and what you want to achieve, you can start looking for tools to reach your goals. If they match your statements, try to adapt them for your team. Don’t worry: none of them are as hard as they look.
Using our example above:
It is important to do everything as a team. It’s not a one-man workshop: you can only change your organization’s processes if you do it together. Sit down with everyone responsible for the change and let them be part of the work.
If you have the opportunity to experiment with your team, do it as soon as possible. I’d suggest remaining modular: if something seems to be working, do it. If something causes more pain than gain after a few months, get rid of it. Hola Loranger says that the process gradually gets more perfect with practice. You’ll gain experience along the way after the risky start.
The biggest thing I’ve learned from my failures is that I need to write down everything. Yes, even that little half-thought! Then I structure and map my thoughts and show them to others.
A good framework starts with collaboration after the first thoughts are born. At our UX company, we use internal “How We Work” meetings to develop our processes. We take a poll with topics to decide which we want to deal with. After choosing the topic, we divide into smaller groups and ideate. At the end, we share it with each other and decide on the next steps. Sometimes we organize an education session or more How We Work meetings if needed.
Write a handy document of your process, even if it only consists of three bullet points at the beginning. If you have the same three points a few months later, well, you’re a superhero then! This way, there’s always a document to rely on in case you forget something. And it’s also handy if a new member joins the team.
What is a good framework like?
What are the elements of an agile product management framework?
We at UX Studio, use our own design process, adapted to each project, and fine-tuned for the product itself. We’ve built it on several agile processes, but we’ve changed it fundamentally so that it works best with small project teams. We iterate once a week, and research in every phase from the beginning. And I can tell it saves more time and money than you can imagine.
It wouldn’t be bulletproof unless we frequently measured and revised it. If you feel that your process is still chaotic but you can see the “grid of thoughts”, that’s absolutely okay. In my opinion, that’s the sign of continuous monitoring and change. So, yes, it’s worth the time.
As a tiny takeaway:
UX studio has successfully handled 250+ collaborations with the clients worldwide.
Is there anything we can do for you at this moment? Get in touch with us and let’s discuss your current challenges.
Our experts would be happy to assist with the UX strategy, product and user research, UX/UI design.
It's hard to find any product designers nowadays who don't use or at least don't…
As we step into 2024, the significance of investing in user experience (UX) and user…
Are you interested in how eye-tracking in UX research can be leveraged to gather reliable…
In this episode, we have a conversation with Sándor Zelenka and Benedek Göbölös as they…
Current generative AI tools can come up with videos and images within minutes. We still…
Even if you are far from being a football fan, I’m sure you’ve heard of…