Making of an ‘Agile design process’
We have so many guidelines, references and best practices out there nowadays (some linked at the end 😉), that in a way it can make it hard to gain clarity and direction. The truth is, there is not a single way or rule you or your team should follow. It’s under your best judgment and knowledge of your project, that you can apply some of these practices.
So, without any more hesitation, these are some of the tips I’ll like to share with you based on my experience in the field.
Yes, you are. What does this mean? Well, you have responsibilities to meet in every sprint and value to create together with your team. You should make sure you have a sprint goal clearly defined, and some tasks that lead you towards that. Also, depending on your role, you are responsible for supporting the rest of your team and understanding where everyone stands in the combined progress. For this purpose, attend your daily stand ups, refine often and closely with your developers and plan with your team. Never forget that the whole Delivery Team is responsible for the value added at the end of the sprint, so be involved. (Read this article for a summary of Agile)
This one should be pretty straight forward, but surprisingly it sometimes isn’t.
I’ve worked in multiple sized teams, together with the client’s designers and solo. Roles and responsibilities can easily become quite blurry in the process, which adds frustration to the process and makes you lose focus.
So, some suggestions would be to clearly communicate and create a RACI chart or Responsibility assignment matrix (Read more on the topic here). Take your time doing so at the very beginning, with everyone in the team involved. Make sure you all speak the same language and understand each other’s responsibilities.
I would say at this point, it should become easier for you to work together. If not, you can always refer back to this RACI and take a step backwards.
You now have a clear understanding of your Creative team and your role within. Next step, is to align together with your Product owner (PO) on the planning, the backlog and to start prioritizing these.
Sometimes, this is a hard thing to do and easy to say. The backlog is very limited and high level at the early stages, and as a Designer you will deal with this the most. However, it is your responsibility together with your PO to ‘Discover’ these backlog items and ideas. Take some items and a goal you know you can manage to deliver by the end of the sprint, and there you have it: priorities and a planning.
Many would argue that Design should be at least 1–2 sprints ahead of Development, meaning it is not realistic to share the same current sprint goal.
Well, that is ideal in my opinion. On the other hand, there are some other good recent talks on a different approach (Article on why UX should be aligned with the development sprints). I personally haven’t experienced the later and rarely work in a project so organized to be ahead of Development. So, what I can argue is that Designers should own their work and processes. They are the end responsible of their work, and as professionals they can best estimate their work and input with the Road Map. This mentioned Road Map, should reflect the POs vision and wishes for the product. So, by aligning with it and your PO, your planning of tasks will be pretty much clear. You will need to allow yourself some time to do some pre-work, like setting up a Design System if you are at the early stages of your project. Then, consider time to refine your work with the Dev team and getting all of those PO approvals and reviews. This will all need to be done to get the tasks and stories ‘Refined’ and ready to be picked up by development.
Well well… this is were everyone can have different opinions and points of view (if you want to read about the topic check this article). What I can say is that it helps the whole team to include Design or Refinement tasks in the backlog. Designers can own these and update and record their progress. This way, their efforts are documented, issues and blockers can easily be raised in daily stand ups and… you just feel more included in the team. Following this way of thinking, I would not consider pokering essential for such tasks. Some even agree that these don’t have the same treatment as User Stories, hence they should not be pokered and included to the team’s velocity.
In my team, we are not pokering our tasks, we are instead being very clear and transparent with the status and progress of such. If there are any issues or blockers, we deal with them. And eventually, great work will shine on its own.
So, these were some of my reflections and takes on this topic. My intention by no means, was to dictate any direction or practice. I’d like for us to share our experiences and learnings, failed approaches and tips in the field. I would love to hear your input and continue on growing in my practices.
Thanks for stopping by and reading my first Medium entry! *nervous laugh*
I am digital product designer (UI/UX) who also enjoys illustration, art, helping people and technology. Currently based in Amsterdam and part of the team at MOBGEN — Part of Accenture Interactive.
Feel free to chat over Twitter about your ideas on the topic, or anything really! and if you liked the illustrations on this article, maybe you want to see more of my art on Instagram.
Making of an ‘Agile design process’
Research & References of Making of an ‘Agile design process’|A&C Accounting And Tax Services
Source
0 Comments