K.C. Jones-Evans, a User Experience Developer, Josh Lathery, a Full Stack Developer, and Sara Darrah, a User Experience Specialist, sat down recently to talk through our design and project development planning process that we implemented for part of a project. This exercise was to help improve our overall project development planning and create best practices moving forward. We coined the term the “Design Huddle” to describe the process of taking the feature from a high level (often one sentence request from our customer) to a working product in our software, improving project planning for software development.

We started the design huddle because the contract we were working on already had a software process that did not include User Experience (UX). We knew we needed to include UX, but weren’t sure how it would work given the fast paced (2-week sprint cycles) software process we were contractually obligated to follow. We needed to come up with a software design planning solution that allowed us to work efficiently and cohesively. The Design Huddle allowed us to do just that.

What does the design huddle mean to you?

Josh: Previously the technical lead would have all the design processes worked out prior to being assigned a ticket for development. The huddle meant that I had more ownership in the feature upfront. It was nice to understand via the design process what the product would be used for and why.

K.C.: The huddle was an opportunity to get our thoughts together on the full product before diving into development right away. In the past, we have developed too quickly and discovered major issues. Development early equated to too much ownership in the code, so changes were painful when something needed to be corrected.

Sara: The huddle for me meant the opportunity to meet with the developers early to get on the same page prior to development. That way when we had the final product, we could discuss details and make changes, but we were coming from the same starting point. I have been on other projects where I’m not brought in until after the development is finished- which

immediately strains the relationship between UX and Development due to big changes needed to finished code.

What does the design huddle look like?

  • The Team: UX Designer, at least one front-end or UX developer, a full-stack developer, the software tester, a graphic designer (as needed), and a Subject Matter Experts (as needed)
  • The Meeting: This took time to work out. As with any group, sometimes there were louder or more passionate individuals that seemed to overshadow the rest. At the end of the day the group worked better with order and consensus:
    • Agendas were key: The UX lead created the agendas for our meetings. Without an agenda it was too easy to go down a rabbit hole of code details. This also helped folks who were spread across multiple projects focus on the task at hand faster. We included time to report on action items, old business/review of any design items and set the stage of what you hope to cover as new design work.
    • Action Items: Create and assign actions to maintain in the task management system (JIRA). This was a good translation for developers and helped everyone understand their responsibility leaving the room. These also really helped with sprint planning and the ability to scope tasking.
    • The facilitator had to be assertive: Yes, we are all professionals and in the ideal world we could “King Arthur Round Table” these huddles. But the few times we tried this meeting were quickly off-track and down a rabbit hole. Many teammates would leave frustrated and feeling like we hadn’t made any progress. The facilitator was the UX specialist for our meetings, but we think the owner of the feature should facilitate. The facilitator needs to be willing to assert themselves during conversations, keep the meeting on track and force topics to be tabled for another time when needed.
    • Include everyone and know the crowd: The facilitator needs to quickly understand the team they are working with to figure out how to include everyone. One way we ensured this happen was to do an around the room at the end of each meeting.
    • Visual Aid that the whole team can see during the meeting: Choose the tool that works best for the topic at hand- a dry erase board, a wireframe, JIRA tickets, or a mock-up can help people stay on track and ensure common understanding.
    • Table tough items and know when to end the meeting: sometimes in the larger meetings we needed to call it quits on a debate to give more time for thinking, research, and discussions. Any member of the team could ask for something to be tabled. A tabled item was given a smaller group of individuals to work through the details in between the regular design huddle sessions.
    • Choose the team participants wisely: The first few meetings most likely will involve the entire team, but smaller huddles (team of 2 or 3) can often work through details of tabled items more efficiently.

What is the benefit?

  • Everyone felt ownership in the product by the end of the design. Sara’s favorite thing about this learning experience was when one of the developers I hadn’t worked with before said he loved the process. He had the opportunity to provide input early and often, and then by the time development started there weren’t really any questions left on how to implement. Josh- the process helped me feel like an engineer and not just a code monkey. K.C.-: In other projects, we have been handed mock-ups without context. This process helped the “gray area” be taken away.
  • Developers were able to tame the ideals of the UX designer by understanding the system, not just the User Interface. Developers could assist UX by asking questions, helping understand the existing system limitations, and raising concerns that the design solution was too complicated given the time we had.
  • The software tester was able to understand the flow of the new designs, ask questions and assist in writing acceptance criteria that was specific, measurable, attainable, realistic and testable (SMART).
  • She provided guidance when we needed to go from concept to reality and ensured we understood the design requirements.
  • It was critical to designing 1-2 sprints in front of expected development as part of Agile software development. It allowed for the best design to be used rather than forcing ourselves into something that could be completed in two weeks. Together we would know what our end goal was, then break down the concept into tiers. Each tier would have a viable product that was one sprint long, and always kept the end product design in mind.

The Design Huddle is a way for teams to collaborate early on a new feature or application. We feel it is a great way to work User Experience into the Agile software process and simplify project development planning. We have taken our lessons learned and applied to a new project the three of us are getting to tackle together and expanded the concept of the huddle to different members on the team. If you are struggling to incorporate proper design or feel frustration from teammates on an application task, this may be the software design planning solution for you!

AIS recently worked with the General Services Administration (GSA) Technology Transformation Services Division, better known as 18F.  The engagement involved working with 18F to digitize the Department of Labor’s Section 14(c) certification application process (part of the Fair Labor Standards Act). This is currently a paper-based process that 18F hoped to modernize as an intuitive, online application…and to do it using agile methodologies.

AIS was tasked with building the first version of the digital form within a 60-day period of performance – much shorter than typical federal contracts.  AIS pulled together a multi-disciplinary team comprised of user researchers, designers, and front- and back-end web developers to work closely with 18F and the Department of Labor (DOL) Product Owner. The team built the entire form with complex validation along with a registration and login and an administrative section to process the form applications. They performed multiple usability tests with actual end users, and followed 18F’s principles of working in the open using a public GitHub repository. All User Stories and discussion threads were thoroughly documented in that repository’s issues list.

AIS was able to work together with many divisions inside DOL to make this happen.  We addressed security concerns by the Chief Information Security Officer (CISO) and worked with the CIO office to coordinate delivery of the application and a testing and staging environment for deployment. We also set up a Continuous Integration/Continuous Deployment process so that multiple DOL stakeholders could stay abreast of what was happening and exercise the existing application state.  We were even able to address legal concerns with testing by external citizens by getting signed consent forms for testing and recording the sessions.

The collaboration was so successful that our client wrote their own blog post on the project, detailing exactly “how government and private industry can work together using agile methodologies to produce great results.” You can read it here. 

These types of successful, agile engagements break down the myths that software development for the government needs to take months (or even years). Government can and will move faster, and after every small win like this project, the traditional methods of building software and procuring software development are changing across the industry.  This bodes well not just for the citizens who need to interact with these digital services… but also for saving our tax dollars.

15498218 - search icon

Make no mistake, most organizations and government agencies are—at least in part—software companies. The backbone of the services and products they sell, the internal business processes they use, and the customer feedback mechanisms they rely on are all built on software. Even in the age of software as a service (SaaS) – a modern organization’s portfolio of applications and the specifics of how these apps are used influence its most important decisions.

So while it’s easy to understand that software is a foundational component to modern business, often the decision to invest in building or offering software to users must also be accompanied by a more specific, anticipated return on that investment. That process can go like this:
Read More…

DevOpsDevOps is the latest catchphrase that everyone claims to be doing.

Gartner recommends that “leaders wishing to create a significant, lasting impact on IT performance should look to move beyond the Bimodal paradigm in the space of months rather than years.” Leading and executing on this cultural change is very challenging in enterprise IT. The urgency is to ensure your line-of-business teams remain engaged with enterprise IT, rather than deepening the divide between infrastructure operations and application development teams. In today’s rich marketplace for cloud-based solutions including infrastructure, platform, and software as services, application teams and line-of-business customers have options beyond traditional enterprise IT operations for hosting their solutions. Read More…

Despite what you hear on the news, not all IT projects undertaken by the federal government are unsuccessful. Granted, there are challenges to overcome, but a talented development team with a clear vision can build bigger and better things. In Washington, D.C., the capital of the federal contracting world, a small IT company called AIS is making a big difference at the FBI using the Agile approach to deliver an application that is being used by the FBI every day.

Agile software development, at its core, is more about focusing on interactions between team members, collaborating with customers, actively involving users, and responding to change quickly…and less about focusing on preparing comprehensive documentation or following processes. However, the AIS team at the FBI uses a hybrid approach that is heavy on constant interaction with the customer and the user community, without losing the significance of processes and documentation. For our application, AIS uses a team of requirements analysts, programmers, infrastructure engineers, software testers and helpdesk support to form a strong software development team to accomplish these tasks. Read More…

Chemistry FlasksThe ability to inspect and adapt is what differentiates good software development teams from great software development teams. For agile teams, the retrospective is a key event to making that happen. Just as the daily scrum is a scheduled time each morning to plan an attack for the day, the retrospective is a scheduled time at the end of each sprint for the team to inspect how these daily attacks were executed and create an adjustment and improvement plan for the next sprint. If your team’s retrospectives have become stale and boring, or fail to generate concrete actions and experiments for the next sprint, then try some of the following adjustments. Read More…
Although AIS is proud to center their technology on Microsoft’s frameworks and technology stack, AIS is also adept at working with a broad range of other technologies to give clients solutions that are custom-tailored to their needs.

One such project is the recently released Web Report Editing Tool, or WebRET. WebRET was custom-built in the Ohio Development Center for the specific needs of our government client. In this instance, the client needed a back end that was compatible with the Java Runtime Environment, so we used JRuby on Rails to provide a modern yet JRE-compatible back end.

To learn more about the technologies used in WebRET, take a look at the whitepaper below.

Web Report Editing Tool Case Study (PDF)

Click here to read more about AIS’ custom application development service offerings and how they’ve helped our clients.

Some end-of-the-week reads from AIS employees’ personal blogs:

Windows Azure Planning: A Post-Decision Guide to Integrate Windows Azure in Your Environment: AIS’ CTO Vishwas Lele posted a complete planning guide on how to best adopt and integrate Windows Azure into your organization. (Fleeting Thoughts)

SharePoint Saturday Cincinnati Session: Clint Richardson (who wrote the excellent three-part series on The Best New Features of SQL Server 2012) presented a Voluntold admin session at last week’s SharePoint Saturday Cincinnati. His presentation, relevant links and PowerShell code are all available at his blog. (pointblankadmin)

Understanding and Using System.Transactions: Ash Tewari has compiled an excellent library of resources to help you understand and effectively use System.Transactions functionality in your .NET projects. (tewari.info)

Adaptive Problems Require Responding to Change Over Following a Plan: More deep thoughts on the Scrum framework and Agile values from Ryan Cromwell. (cromwellhaus)

Aliasing Multiple Properties in Knockout JS Bindings: David Benson figured out another handy use for Knockout JS’s “with” statement: you can emulate c# style “using” directives. (dben codes)

Teach Your Kid to Code: Steve Michelotti (and his 5th grade son!) will be co-presenting a great, fun session called Teach Your Kid to Code at the CMAP meeting next Tuesday evening in Columbia, MD. (Don’t forget to get out and vote early, too.) (Steve Michelotti)

Happy Friday! Here are some of the latest posts by AIS employees from around the web and their personal blogs:

Using Git-Tf: Suppress the TFS Warning When Loading a Solution: Using Git-TF? Getting annoying TFS warnings in Visual Studio? Senior Software Engineer Kip Streithorst can help. (It’s Null?)

Fight Clutter and Confusion in the Workplace. The Importance of Process Streamlining and How to Do It: Developer Terra Gilbert has discovered a natural knack for process streamlining and improving documentation. Here are her tips. (codeterra)

Recent Items in Windows 8: Oskar Austegard plays around with a new Windows 8 install and solves the case of the missing (or at least hard-to-find) Recent Items folder. (mo.notono.us)

KnockoutJS & ASP.NET Mvc Partial View Loading: How to dynamically load “partial views” bound to KnockoutJS view models. (Null != Steve)

Scrum Fundamentals Recording Available: In case you missed Ryan Cromwell‘s Scrum Fundamentals webinar, the presentation is available on his blog. (And be sure to check our Events page — we add new events every week!) (cromwellhaus)

dailyscrum

The Daily Scrum, sometimes referred to as the Daily Standup, is a simple activity most teams have adopted or experimented with at some point.  In most instances, the extent of their guidance is to limit the gathering to 15 minutes and to answer three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. What impediments do you have?

Most leaders will jump at a chance for their teams to share this type of information and communicate every day.  Fifteen minutes is a small price to pay for a bit of insight and the appearance of teamwork.

Read More…