Reddit reviews Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous (Voices That Matter)

/u/bil4l has good advice if you have a product that has incremental releases.

I worked in DoD as well and it was really... dumb. I got out and I hope I never have to go back. This is not going to be strict UX advice, its more a mix of context for DoD, job security, and mental health. I will warn you that I am exceptionally jaded from the whole thing. If anything here is useful to you then I will feel better.


More often than not though the politics play out that:

• We have to get as much in this release is possible and feedback is not as important as x,y,z features. This is typically because of getting funded again and needing to check off X,Y,Z checkboxes to be able to get funding. Typically UX is not one of those checkboxes. If it is, then use it like a sword.
  
• You can try to design for end users but if it puts you at political odds with the director then you may have trouble staying on the project or getting future work on other associated projects if you stay in DoD.
  
• Are you government worker or a contractor? This makes a HUGE difference in how much political leeway you have. Government people are very very hard to fire, you are more likely to get a promotion to get you off the project than be fired. If you are a contractor a government stakeholder can tell your company they want you gone or they can switch contractors and you are without a job.
  
• All of DoD work is based on politics and funding. Someone thought they needed a UX person on the project, WHY? Find out because it is important to understand who thought your job was important. You might just be a checkbox for the project if you don't have support from the top stakeholders. In that case you may want to look at just designing for the director until you can get a better job. It feels dirty but then you have people giving you recommendations on your way out the door.
  
  Something to consider is that your recommendation for user testing might be at odds with a major stakeholder's political leanings in that if your research finds something that they may lose face or their plans may lose merit. I cannot stress enough how important it is to try to get your stakeholder to think its their idea so they don't lose face, especially government stakeholders.
  
  Here are some ideas, not all of them are great but they might give you some food for thought:
  
  Agile Scrum and the Government If you are masochistic and your group is trying to bastardize some version of Agile you can start pulling themes from the methodology to try to get some of the feedback you want. You can say you need to take the designs through a validation cycle before it goes to development or call it a research spike. This can go very badly though since most of the government's version of agile is really poorly thought out and because there is no predefined role for UX in Agile Scrum. You could use a resource like Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous to help make your case or make friends with the scrum masters and product owners to help you make the case.
  
  Take the director into the details until he stops designing Depending on what the arguments are over such as feature design vs UX details.
  
  
• 508 compliance - Does the director love lime green as a background color for all screens with text? If its not within proper contrast ratios he is designing something that can make the government liable. This gives you some framework to argue about one of the dumbest arguments in all government software design... color. There are lots of other good bits here too but stakeholders want THEIR color and this gives you a easy way to say... sorry that would make this or that unreadable. We need icons/text along with the color for the colorblind. Etc
  
• Get supporting research that stakeholders have to disprove NNG or even UX Stack Exchange to find logical arguments and source material.
  
• Undercover user testing - UsabilityHub is freeTypically in government work if you test your designs publicly then someone will shit a security brick but if you test elements of your design out of context you can prove that certain designs have merit from a "The user can distinguish this and use it faster than the other design." Some things are not going to be publicly testable but typically you have 1-20 subject matter experts on a project or available to the project. Do really REALLY short tests with the SMEs. So that no one can claim you are wasting their time. Use the results to get a clearer understanding of why who thinks what and you may be able to use them to settle arguments over what would be most relevant, clear, or contextual.
  
  Features There are a lot of fights over what features are more relevant than others. Many times the UX person gets pulled into these discussions. My best advice is to make whatever case you need to and then leave it alone. Keep it in your back pocket until something changes and it can be offered again. There are no good ways to winning these arguments outside of research and playing a mix of poker and chess.
  
  I'm sure lots of UX purists who have never worked in DoD work are going to be horrified by this advice. They should, its terrible, but government work is terrible. Its not about doing things that are productive its about getting funding the following project and CYA. Not CYA in that something has to be working or useful but in that no one can lose face or be targeted for making one wrong decision because there are a million wrong decisions. Its backward and painful.
  
  edit:formatting.

It's definitely a contentious topic! There are many ways to implement it and it really depends on what type of organisation you are. A 20-30 people service agency will need a different kind of agile to a large Enterprise company with hundreds of production members.

If your org is committed to it, it's absolutely worth getting an Agile specialist in to do Agile training with not only the production team, but the managers and stakeholders too. The number one cause for failure (in my experience anyway) is when people with authority break the rules to achieve some goal. This is generally down to a lack of understanding of the purpose and benefits of Agile, so training definitely helps.

For some cheaper, more tangible resources - Lean UX is an essential read from a product perspective. Agile Experience Design is really good too!