Adapt, not adopt

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.

‘Computer define: Challenges’

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:

• What pains does your team have?
• They do a lot of overtime
• How come?
• Our clients say we don’t work enough.
• Why do they say that?
• They haven’t received any outcome for months.
• What are you going to do about it?
• I want my team to provide deliverables on a weekly basis.

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.

Design your own agile process

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:

• If regular deliverables are important to you, try to use story points from Scrum. This way you can slice up your tasks.
• If you deliver new features regularly, but usage statistics do not get better, try to focus more on product discovery and solve people’s real problems instead of fast feature building.
• Weekly client meetings can help demonstrate your presence. “Hey, we’re here! Here are the things we’ve done since last week.”
• Daily standups could be also useful to track your team’s progress and difficulties.
• A five-hour weekly sprint planning seems to be overkill if you want to focus on fast deliverables.

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.

Set a framework

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?

• Simple and easy to use
• Defined jointly with the team
• Written down with concise wording and bullet points
• Everyone knows it and uses it naturally
• Always available for everyone in the team
• Improved and refined regularly
• May contain pieces of best practices from other organizations
• Explained and shared with new team members

What are the elements of an agile product management framework?

• Product discovery: How do you explore the pains and needs of your customers systematically? What do you do with the findings?
• Team structure and task break-down: Who works together, and how do you distribute the tasks and responsibilities between your team? How will different people work together (for example, devs and designers)?
• Strategy and roadmaps: When do you refresh your product strategy? How do you involve others in this process? How do you share the results with everyone?
• Measure: How will you measure the team’s and the product’s performance? What qualitative and quantitative methods will you use?
• Learn: How will your team learn from its experience? How and when will you update your methods together?
• Stakeholders: How will you share your efforts with shareholders and involve them in strategic decisions?

Is it worth it?

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:

1. Research your team thoroughly
2. Establish statements
3. Find the best tools
4. Write down what you do
5. Refine continuously

Take the next step to improve your website’s UX

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.