Applying Agile Philosophies to Work
Last updated
Last updated
You're either agile or you're not agile. And you can be agile anything. You could be an agile developer. You can be an agile researcher. You can be an agile car builder. You can be an agile accountant. You can be an agile vacation taker. You can do chores with Agile. Literally anything can apply to the Agile manifesto.
When you're working with a team, your team's going to exist on a spectrum, a scale. How much does your team apply the Agile principles? Spoiler alert, it's never going to be 100%. It could be 0%. You could be waterfall as anything. You could be a mix. You could be operating with a mix of waterfall principles and Agile principles.
Over time, your team's agility, notice the adjective there, your team's agility is going to evolve the way that you all carry out the Agile manifesto, the way that you carry yourselves in your philosophy of your approach, the ways that you interact with individuals, the ways that you build working UX, the ways that you respond to change, that's going to change over time. That's why every single team that gets together is different. The way that you all agree how you're going to work together is actually defined by you.
Everybody comes into the field looking for specific answers.
What do I do?
When do I do this?
How do I do it?
What should I not do?
There is no one answer to that. There's no right way of doing that. There's only the way that you, the team, agree. to do it. That's what makes Agile complicated.
It's not going to be a concrete answer because Agile team work is an agreement that you make across roles across your team.
Some of the principles of Agile, the things that you'll say when you carry out this work:
Progress over process.
Deliver early and often.
Build fast, fail fast.
Let the team experiment with new ways of work.
You don't need all the requirements up front, you just need the most important ones up front.
Do what makes sense in the context of your team.
Show your progress.
Pivot.
Number one rule is to build fast fail paths, which means that you're not just failing. If you're just failing, you're just a giant mess. If you're not improving what you've done, based on the lessons that you've learned in failing, You're never going to progress. So in Agile, what you do is you build fast, which means get it into the hands of users quickly. And you learn that you're not headed in the right direction quickly, failing fast.
And then you change your plan quickly. Learn fast, adjust fast. The key word there is fast. Not fail, but fast. You have to build fast, fail fast. In the context of research, that means that you have to deliver research fast. and learn that you're headed in the right direction or not headed in the right direction fast.
âNumber two, don't talk about it endlessly. Just start doing it. You don't need to come up with a perfect process. You don't need to perfect it and talk about all the what ifs, what ifs, what ifs. Just start doing it. Start collaborating with your teammates, collaborating with customers, collaborating with users, and figure it out.
â Do what makes sense in the context of your team. If some theory is telling you, you have to do this, but the team context prevents you from doing that, You're not going to be able to fit that thing into the context of your team very well. You can't force the thing that you learn in a book on a team.
You have to be able to build malleability and flexibility around how you apply that thing to the team.
âYou always need to work on the most important thing, the riskiest assumptions. the highest priority items at any given time. If you're not doing that, and you're delivering the things that are nice to have, you're not really delivering a lot of value because you're moving toward things that are nice to have, but you're not vetting the most important things at any given time.
If you do that, that will also lead to adjustments and pivots a lot more, but it will lead to a stronger product in the end. And you always want to deliver something usable after one iteration. An iteration is just a chunk of work. You will deliver research in one week.
You will deliver designs that are validated in one week. One week's time. What you're used to in training is you have all the time in the world. You have the whole semester. You have six months. You have two months. Not the case.
âYou always want to make sure that the thing that you build in the end isn't just a chunk Isn't just a part of it, but it's something that you can put into the hands of users validate test determine the direction of quickly.
What this means for UX teams: you are delivering smaller rounds of research and design every week or every couple of weeks. You're not producing the entire finished result at once: you are delivering it in usable chunks that you can validate and provide prioritized value.
Learn how Agile teams build products into the world with Agile in the next lesson.
