| User Centered Design
|
1. Understand what people need
Regardless of whether we are building a responsive website, building an app, or optimizing a website for search; one of the first things we always do is identify and segment the target audience. Then, we practice empathy to put ourselves in their place and understand their needs. When possible, we interview prospective users to verify the User Stories that we have developed to ensure our understanding is clear and a Definition of Done (DoD) is specified. This is the basis of User Centered Design (UCD). Scrum relies on User Stories and the team has no choice but to understand the requirements from the User perspective. The User Story, written from the perspective of the people intended to use the system, if the foundation of how we approach work. |
| UX Research
|
2. Address the whole experience, from start to finish
It is logical for engineers to model the process of a particular User Goal or task to be accomplished. It is important to understand the workflow and think it through from start to finish. But, it is also important to know and understand that people may not necessarily enter a process at the beginning – or what you consider to be the beginning. People may not use the browser or device that you would expect them to use. And, they may not have the time, materials, or information to complete the process and might have to come back later. It is important to consider all these possible Use Cases and User Stories to ensure that the User Experience (UX) is thorough, satisfying, and durable. |
| Don’t Make Me Think
|
3. Make it simple and intuitive
One of the best books out there on Usability is called, “Don’t Make Me Think” by Steve Krug and we consider this one of the most important publications on the subject of Usability and User Centered Design (UCD). We have somewhat of an obsession with making websites and applications simple and intuitive. There are hundreds of little things, like adding instructions and hints so people don’t have to read our minds to know what we want them to do and how they are supposed to do things. So, “Don’t make me read your mind,” would be a good sequel to Don’t make me think. We also use the Proximity Principle to ensure that like things (similar things) are clumped together. Buttons should be where the button should be. Links should look like links. If it is not a link, don’t make it look like a link. Do the obvious, state the obvious, be obvious, not clever. |
| Agile Delivery
|
4. Build the service using agile and iterative practices
Well, we don’t call ourselves Agileana for nothing. Since before it was called “agile” we have known and believed that the best way to build a product, particularly web or software, is to rapidly prototype, get it into the hands of customers, solicit their feedback, and iteratively improve the user experience (UX). The old way is to spend months (if not years) gathering requirements and performing studies followed by months of analyzing the requirements followed by months of engineering a solution followed by months of testing and debugging only to discover, years after inception, that the world has evolved while the product was in development and it is no longer relevant. Think about it. New versions of mobile phones are released every few months. New versions of web browsers are released every few weeks. The world changes so quickly and the way people use technology is changing so rapidly, that you can’t wait months or years to deploy. Products needs to evolve rapidly and iteratively through agile delivery. |
| Agile Contracting
|
5. Structure budgets and contracts to support delivery
This is one area where the government is trying to catch up and Agileana is coaching its clients. Most customers want a firm fixed price (FFP) to go along with a detailed Scope of Work (SOW). This doesn’t work. Why? Because of the three simple truths of Agile: 1) It is impossible to gather all requirements and know all details of a project in the beginning, 2) Whatever requirements and details are known at the beginning are guaranteed to change over time, and 3) There will never be enough time or money to do everything we want. Our response to this conundrum is to coach clients to understand that there are three primary variables with project management: 1) Cost, 2) Scope of Work, and 3) Definition of Done. If any one of these variables are fixed, i.e., Cost, then the other two variables must be fluid or variable. It’s okay to have firm, fixed price budgets as long as we are flexible in the Scope and Acceptance Standard (Definition of Done). |
| Accountability
|
6. Assign one leader and hold that person accountable
Accountability derives from the word “count”. One person must count. Somebody needs to count the Story Points in a User Story, track the Burn Rate, calculate the Velocity, and keep the customer informed of Key Performance Indicators (KPI). Responsibility derives from the word “response”. One person must be responsible. Somebody needs to be designated to respond to customers when asked or tasked or questioned. |
| Seasoned Veterans
|
7. Bring in experienced teams
Some say a fool learns from their own mistakes but smart people learn from other’s mistakes. We learn from experience and so experienced teams will bring lessons learned from their own stupid mistakes as well as those from others. But, I have to say two three things about this, which somewhat contradict the 18F/USDS guidance (sorry for disagreeing on this point). First, people who have been at it a while sometimes get stuck in their way of doing things are are not always open to change. I would rather coach a group of super smart high school kids with no baggage than to try to coach 30-40 year old guys who think they know everything. Second, the first time I ever conducted a hackathon was sensational and its success certainly was not from prior experience or past performance. It was from excellent project management and planning, not my (absent) experience in conducting hackathons. So, just because you have experience doesn’t mean things will work out and just because you don’t have experience doesn’t mean things won’t work out. Finally, how do we build experienced teams? Yes, experience counts. Yes, we need smart leaders who are responsible, accountable, and proactive. But, we also need people to mentor and coach so we can start building the next generation of leaders. So, you can’t just show up with a team exclusively comprised of senior level experts. You need to bring in open-minded protégés who might actually teach us a thing or two. |
| Lean Forward
|
8. Choose a modern technology stack
As higher programming languages evolve, they make it easier and faster to develop products. You can write in one line of Python code, for example, what might take several lines of code in some slightly more classic language. Examples of modern technologies would be Python, Java, NodeJS, Ruby, Redis, MySQL, Postgres, MongoDB, Bootstrap, AngularJS, React, Varnish, Apache Solr, NGINX, Linux, Ubuntu, Ruby on Rails, and Django. Modern technologies will attract open-minded developers eager to learn and practice. |
| Cloud on Demand
|
9. Deploy in a flexible hosting environment
Dedicated servers that cost thousands of dollars per month regardless of how much they are used are old school. Hosting your website in a box in your office is insane and risky. The better way is through services like Amazon Web Service (AWS), which has a variety of options to scale quickly when you need it, pay for only what you need or use, serving static assets (like images or PDFs) from a content delivery network (CDN), and caching code in a distributed, regional environment so it is closer to your target audience. Containers, like Docker, also help with deployment. |
| Quality Assurance
|
10. Automate testing and deployments
When changes and enhancements are built, it is important to get them into the hands of users as quickly as possible. But pushing new code into production too quickly, without proper vetting or testing, could backfire and produce unintended negative side effects or even crash the system. |
| Cyber Security
|
11. Manage security and privacy through reusable processes
This play is actually two plays in one. Our general approach is to only collect the information necessary to perform the task or User Story and to avoid soliciting or collecting personally identifiable information (PII) unless it is actually necessary. We will also use automated scripts and modular functionality to test, evaluate, and deliver relevant information or indicators. |
| Decision Science
|
12. Use data to drive decisions
Leveraging data and decision science helps reduce bias, emotion, and subjectivity in order to produce better results. It is interesting to compare the performance of stock trading apps versus their human counterparts. More often than not, the data-driven stock trading apps prove to be correct more often than not. We also believe that correct use of data results in better decisions and have built decision science systems to support this effort. |
| Open Government
|
13. Default to open
Agileana is, generally speaking, an open source shop. We strive to create and leverage open APIs, open data, and open source software. We contribute to the open source movement and refrain from using and reselling proprietary tools and products. Likewise, if the government has already paid for something to be built, we should make best use of taxpayer dollars by reusing and repurposing this code rather than needlessly and wastefully reinventing. |
