Last to last year I was introduced to the Agile world, in the beginning I really did not understand much. May be it was driven by rules or I could not find enough literature, I had hard time syncing my self with the scrum. However after doing some hands on work, ups and down, going from scrum to kanban to scrumban and finally becoming a certified scrum master, I now feel Scrum can be really helpful for a design team. Why ?, well in short here is why – Scrum is iterative and so is design. Scrum allows change of design at any time, which makes it more easy to manage as compared to typical waterfall approach. Scrum promotes aggressive communication, which is really important if you ‘are a global UX team. Scrum can get you closer to your customer/users sooner as compared to any other management model. (Though this is subject to some limitations). However, this still does not means that agile UX is better then waterfall in every aspect. No !, there are thing which are better in waterfall and really are help full for a design team, we will talk about them in detail below. Personally when I was introduced on this project, I did found out some blogs etc. on Agile UX, however very few in fact close to none, really talked about the actual stuff. Every one was talking about some 6 to 7 points on how UX can be integrated with Agile development, however problems like how and when to perform each UCD step, how extensive UI documentation can be trimmed and small but really important issues related to a UX team(work, commitment, collaboration) can be ironed out. So, here I am with all my thoughts based out of actual experience as a scrum master and being part of a UX team which has/had members in different geographies. Now, you may find something that you have read earlier and some which really does not make any sense(Even i am a human being !). It will be really great if you, after reading this post share your comments or better way of doing things. I am also assuming you have some basic understanding of Scrum framework and know who’s who and what’s what.
First things first – Sprint Zero or even -1/-2:
So, before we start anything or start giving out any tangible deliverable, we as UX professionals need to do our homework. This homework consists of but is not limited to Understanding stakeholder vision, User research and understanding the overall architecture, etc and actually this is also the first step of the UCD life cycle. To make sure that we have this done before the development starts, we have to start way before. So, to start ahead you need to have something like sprint zero or even sprint -1. This is time which you can utilize to do the above listed work and stay ahead of the game. Based on my understanding, usually this will be the time when the development architecture is being thought about, budget is being planned and/or teams are being formed etc etc. Key here is to start early, because once the development sprints start, you probably will not get that much of time for all these things. To share with you, when I joined this project; the development had already started and unfortunately we had very less of the homework in place. Till date, we have tried to get as much of the important material(stakeholder objectives, goals etc.) documented, however we are still behind things and that always haunted me and my team :(. Moral of the story – Start early !. If you get in a similar situation like I was, then prioritize the above work and get it done as soon as possible, you will need it every now and then.
Using Design Patterns:
One of the biggest problem of waterfall model is that all design work is done and sealed way before things get into development. Once things get into development, changing design at that point is pretty chaotic. Best thing about Agile is that it is iterative, what ever a designer will design will pretty soon go into development and that’s the time when the rubber hits the road. Here’s a problem, even in Agile no matter how well you considered all the scenarios, there could be times when in a particular development sprint you realize that the design does not fits well or a particular scenario was not covered. Ultimately making you go back to the drawing board. Fact is that this can happen in a next development sprint or can even happen after 3 or 4 sprints. Above all, design is ever evolving and will change for good. So, to avoid lot of rework in such scenarios, consider using basic set of UI patterns and further building other patterns on the basic set. In future, when ever a change is required or there is an issue, it will be easy to track the areas it will hit and finally solve the same. Other advantage of patterns is that they are easy to maintain from development perspective and also cut short the the development time.
Specifications and Standards:
I remember when i started on this project, me and my team were creating extensive documentation for every pattern etc., obviously we were really not following Agile and singing our own song. Slowly slowly we realized that by creating extensive documents, we were getting behind things and very less of our stuff was getting done each sprint. We also found out that there very less of the folks were really reading the things we created. Last but not least there were times when we signed off the documentation for the pattern done in a previous sprint and that’s when the product owners came back saying the pattern will need to be completely re-written considering the current scenario. I guess for all of the above reason and more, Agile seeks minimal documentation or the documentation which is really required. On the other hand good thing about waterfall is that everything is documented way before development starts. Now, lets get back to reality; as machines cant build products without specification, similarly development teams cant create screens without user interface specification or other artifacts. To add to this, If you work with different delivery teams across the globe, then you know it very well that survival without User Interface standards and specification is just not possible. So, you may consider doing this; Write standards/spec only for things which are necessary (I know you know that !). For interface specification, keep it short and simple. Like for example dont write a blog for a component. Instead keep it point to point, like what it does, context of use. Consider providing wire frames with light annotations which will augment user stories. Embed Visuals within the standards, instead of creating separate design specs for visuals and behavior. Try avoiding writing rational document for patterns, visuals etc. or consider that as a piece of work when the team is out of work or need some thing fresh.
Remember the Big picture:
I have read many blogs which keep saying one thing again and again i.e. just focus on small piece that you are currently working on. I somehow agree to that but the only thing that they miss, which is really important is that you don’t forget the big picture. To put it in simple words, as a designer you will be providing design solution every sprint and subsequently that will go into production in near future. So, obviously the focus has to be that small piece that you are working on but you do have to understand and design on the fact that how exactly this small piece will fit and impact the bigger picture. Regardless of being granular don’t forget who the user is of this particular piece is and what is the usage pattern.
Facilitate, Collaborate & Socialize:
In the Scrum world collaboration and working with a multi-skilled team is the key. Usability Expert has an important role of design facilitator. Not only you have to provide design solution, you also have to work with different teams to implement the desired solution. Ultimately you will find your self in a scenario where you not only have to facilitate the discussion but also take the whole group and come to one decision. The second most important piece is the collaboration and be as social as you can be. As discussed above, patterns will definitely help in change management. However, you have to be quick enough in broadcasting the changes to the team. The reason for that is, that there will be teams who could be working on a pattern or a component which just under went a design change. Somehow I feel that all of this change management is a crucial part of Agile UX. So, this is what you can do; get a blog for your UX group. When ever there is a change make sure it reaches all. ‘All’ here means every one on the project and just not the developers. Conducting sessions for different teams will also help overcome the panic of implementing new patterns/standards.
As with any process, everything depends on the team and the team members. In my personal experience, this is the biggest challenge you will face if you are leading a UX team. Challenge here is to change the way a typical designer works or had been working, i.e. make them go from water fall to iterative. Apart from this, we designers are hard working professional and by experience become more confident and stringent about following each and every process. (I wont blame this all on us, its partly also because most of the time people don’t understand design and so designers start taking their guard and then this becomes a habit). This stringent nature goes very much against the basic principles of scrum and agile, where every team member is expected to take up different role and be as flexible as they could be. Here is what you could do:
- Start with the Basic: Each and every team member needs to understand the scrum process and what’s what. Like what is scrum, how a team works in a scrum and what are the other roles in the whole Eco system. Yes, you will for sure face a situation where a team member really does not wants to change or simply thinks scrum is crap. I did had this experience and I am trying to put my thoughts together on how to solve this problem, will post something on this pretty soon.
- Follow the Scrum
- UX team Scrum Master has to be a UX professional: In my personal experience a scrum master for a scrum UX team has to be a UX professional. I mean you will need to have design knowledge to size something. Without the understanding of design process one will never be able to tweak the process or help align the team member who are not comfortable with scrum. Also, if the scrum master wont understand the process s/he will never be able to be a serving leader. You may want to get scrum master training if you will be leading a team in a scrum based development project.
- For offshore teams: Scrum asks for trust and more of personal interaction, which kind of becomes difficult when your team is sitting in another geography. To make sure you get ROI from a offshore center, definitely need to make sure that point 1. listed above is taken care of and you also have a scrum champion at that particular location. Trust me managing scrum team which is not in front of you can have may hardships related to trust, time and deliverable. If the offshore team members don’t understand the scrum model, they will quickly start taking scrum calls as micro management and scrum master to be a micro manager !
Testing in here is not that easy as people have said earlier. In my experience, till the time you are really not a big firm; Usability testing may not be possible after every sprint or couple of sprints. Reason for that some times could be budget and/or managing the testing process. What ever the case be, I think best way to avoid design disasters is by making sure that the basic patterns being used in first place are intuitive enough and have been used correctly. Obviously when the user sees the screen, they see it as a whole and so I also think showing small piece of work to a user after every sprint may not be helpful. Whatever the case may be, still nothing can replace a proper Usability test with an actual user. So, as we had sprint 0/-1, we got to have a testing sprint after every release cycle. Again, this is how I saw it working, you could tweak it based on your scenario.
By far I think, we in our team had to tweak lot of things in our process, before we actually started running with Scrum. However after working on so long, I think scrum is a process which we as designers have been following from long time. It just how exactly we adopt it and embed ourselves in it.
Thank you for reading the above thoughts!, please get back to me if something above hits you and/or can be improved.