{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "news",
    "type" : "single",
    "title" : "Managing Custom Software Development in Government When You're Not a Software Engineer |Digital.gov",
    "description": "Managing Custom Software Development in Government When You're Not a Software Engineer",
    "home_page_url" : "/preview/gsa/digitalgov.gov/cm-topics-button-component/","feed_url" : "/preview/gsa/digitalgov.gov/cm-topics-button-component/2017/09/21/managing-custom-software-development-in-government-when-youre-not-a-software-engineer/index.json","item" : [
    {"title" :"Managing Custom Software Development in Government When You're Not a Software Engineer","summary" : "As custom software development becomes integral to accomplishing any program&rsquo;s mission, many managers in government find themselves faced with handling the unfamiliar: overseeing the design and implementation of a digital product that is functional, user-friendly, and necessary for realizing your program’s mission.","date" : "2017-09-21T16:10:00-04:00","date_modified" : "2024-04-02T09:45:13-04:00","authors" : {"kaitlin-devine" : "Kaitlin Devine"},"topics" : {
        
            "content-strategy" : "Content Strategy",
            "human-centered-design" : "Human centered design",
            "product-and-project-management" : "Product and project management",
            "software-engineering" : "Software Engineering"
            },"primary_image" : { "uid" : "software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006", "alt" :
  "A developer touches an augmented reality screen of technology icons.", "width" :
  "1200", "height" :
  "630", "credit" :
  "", "caption" :
  "NicoElNino/iStock via Getty Images", "format" :
  "png" },"featured_image" : { "uid" :
  "featured-18f-new-logo-black-bg", "alt" :
  "18F logo" },"branch" : "cm-topics-button-component",
      "filename" :"2017-09-21-managing-custom-software-development-in-government-when-youre-not-a-software-engineer.md",
      
      "filepath" :"news/2017/09/2017-09-21-managing-custom-software-development-in-government-when-youre-not-a-software-engineer.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/cm-topics-button-component/content/news/2017/09/2017-09-21-managing-custom-software-development-in-government-when-youre-not-a-software-engineer.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/cm-topics-button-component/content/news/2017/09/2017-09-21-managing-custom-software-development-in-government-when-youre-not-a-software-engineer.md","slug" : "managing-custom-software-development-in-government-when-youre-not-a-software-engineer","url" : "/preview/gsa/digitalgov.gov/cm-topics-button-component/2017/09/21/managing-custom-software-development-in-government-when-youre-not-a-software-engineer/","content" :"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003eThis post was originally published on the \u003ca href=\"https://18f.gsa.gov/2017/09/20/managing-custom-software-development-in-government-when-youre-not-a-software-engineer/\"\u003e18F blog\u003c/a\u003e. It is the first in a series that will share effective and efficient ways to manage software development, even if one doesn’t have a background in software engineering.\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eAs custom software development becomes integral to accomplishing any program’s mission, many managers in government find themselves faced with handling the unfamiliar: overseeing the design and implementation of a digital product that is functional, user-friendly, and necessary for realizing your program’s mission.\u003c/p\u003e\n\u003cp\u003eRunning a program in government is already tough; taking on software development to the pile of responsibilities can make the day-to-day chaotic. Adding to the complexity, all program-specific software must be aligned with the other program and policy work being done to accomplish your goals. \u003cstrong\u003eLeadership and management for that alignment cannot be outsourced.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis post is part of a series that will introduce you to the things you need to think about to manage software development effectively, even if you don’t have a background in software engineering. Future posts will cover issues such as: how to convince your peers in government to use agile methods; getting through the security and assessment process with your product; battling procurement constraints; melding agile with other government processes; and building a high-functioning development team.\u003c/p\u003e\n\u003cdiv\n  class=\"image\"\n\u003e\u003cimg\n      src=\"https://s3.amazonaws.com/digitalgov/software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006_w800.png\"\n      \n        alt=\"A developer touches an augmented reality screen of technology icons.\"\n        srcset=\"https://s3.amazonaws.com/digitalgov/software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006_bu.jpg 48w,https://s3.amazonaws.com/digitalgov/software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006_w1200.png 1200w,https://s3.amazonaws.com/digitalgov/software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006_w800.png 800w,https://s3.amazonaws.com/digitalgov/software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006_w600.png 600w,https://s3.amazonaws.com/digitalgov/software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006_w400.png 400w,https://s3.amazonaws.com/digitalgov/software-developer-augemented-reality-screen-nicoelnino-istock-gettyimages-844536006_w200.png 200w\"\n\n      sizes=\"(max-width: 800px) 100vw, 800px\"\n    /\u003e\u003cp\u003eNicoElNino/iStock via Getty Images\u003c/p\u003e\u003c/div\u003e\n\n\n\u003cp\u003eYou might think to yourself, “My job is policy, not software. I can outsource this technology stuff.” Or, “I don’t need to spend a lot of time and attention on developing a great software product to enable my mission.” Every failed project I’ve seen has started with such attitudes. Focusing your attention on building a great product lets the software get out of the way of your team’s work.\u003c/p\u003e\n\u003cp\u003eThis series is designed to guide you in managing your necessary IT needs as a product, rather than as a physical item you buy off the shelf. Software development is more like creative writing: You start with an outline, a rough draft, a first draft, many more drafts, and then you have a draft that’s not embarrassing to publish — not because it’s perfect, but because you’ve run out of time and need to get a working version out there. For most civil servants, the shift from buying software as a commodity to an iterative service may require a significant change in your mental model, but one that can be achieved in small steps, and with practice (for a guide on what not to do, please read Dan Sheldon’s \u003ca href=\"https://medium.com/@sheldonline/the-government-it-self-harm-playbook-6537d3920f65#.ab2mvocaz\"\u003eThe Government IT Self-Harm Playbook\u003c/a\u003e).\u003c/p\u003e\n\u003cp\u003eThere are two implementation strategies that will serve you well when embarking on a new project as a new product owner: agile development and user-centered design. Both of these terms can mean different things to different people, but ultimately every flavor of these methodologies should rely on just a few fundamental principles that are more common sense than anyone cares to admit.\u003c/p\u003e\n\u003ch2 id=\"agile-development\"\u003eAgile development\u003c/h2\u003e\n\u003cp\u003eAgile development really just means continuous and incremental improvement. Don’t try to plot the three-year path of your product in one sitting. Instead, focus on steady and demonstrable progress on individual features rather than detailing every possible requirement up front. This refers not just to the product itself, but also to the team working on it. You need to regularly and honestly assess what is and isn’t working in your team, and continuously improve it (referred to as a “retro” in agile speak). Honest retros are so important that, in fact, I would hire someone with no discernible skills beyond active and constructive participation in retros over a “superstar coder” any day.\u003c/p\u003e\n\u003cp\u003eIf you can, start off targeting the simplest possible version of your product that works \u003ca href=\"https://18f.gsa.gov/2017/01/11/the-best-way-to-build-big-is-to-start-small/\"\u003eend to end\u003c/a\u003e, even if that just means a site that displays the text “Hello” but is actually functioning live on the internet somewhere. Deploying software is almost always the most difficult part of the whole process. By deploying something basic at the beginning, you not only save yourself a lot of future pain, but you’ve already got a live, demo-able product! This will come in handy very soon, when you inevitably need to convince your peers that this is an acceptable way of working in government.\u003c/p\u003e\n\u003cp\u003eThere are a million resources out there [i.e., \u003ca href=\"https://modularcontracting.18f.gov/agile-development/\"\u003eAgile Development Processes\u003c/a\u003e, \u003ca href=\"https://www.youtube.com/watch?v=FpBjClJTVQ0\"\u003eHow to Run an Agile Project\u003c/a\u003e, \u003ca href=\"https://18f.gsa.gov/2015/02/11/a-story-of-an-agile-workshop/\"\u003eA Story of an Agile Workshop\u003c/a\u003e, and \u003ca href=\"https://18f.gsa.gov/2015/08/31/how-playing-with-legos-taught-executives-agile/\"\u003eHow 90 Minutes With Lego Bricks Taught These Executives Agile\u003c/a\u003e] to understand agile software development, and there are many different ways to do it. But I often see projects in government missing the very basics, while still having a very elaborate and self-described agile process. At a minimum, you must:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eHave frequent (measured in weeks not months) demos of working software. Showing documents and spreadsheets to the team is not a demo.\u003c/li\u003e\n\u003cli\u003eHave regular retrospectives. A dedicated time on a regular basis (usually right after the demos) for your team to think critically about how to improve your team and product going forward.\u003c/li\u003e\n\u003cli\u003ePrioritize features \u003cem\u003eruthlessly\u003c/em\u003e. If everything is a priority, then nothing is.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eOne thing you \u003cem\u003edon’t\u003c/em\u003e need is an agile certification — to quote my colleague Robert Read, “You can’t learn \u003ca href=\"http://agilemanifesto.org/\"\u003eagile software development\u003c/a\u003e from a book any more than you can learn to perform a one-handed jump shot without repeatedly tossing a basketball in the hoop.” Since agile development is more a mindset of continuous improvement and not a rote process that can be disseminated as step-by-step instructions, you have to practice at it. Even better, find a high-functioning team where you can observe actual practitioners.\u003c/p\u003e\n\u003ch2 id=\"user-centered-design\"\u003eUser-centered design\u003c/h2\u003e\n\u003ch3 id=\"or-am-i-building-something-that-anybody-even-wants-to-use\"\u003eOr: Am I building something that anybody even wants to use?\u003c/h3\u003e\n\u003cp\u003eMany people in charge of a software product make the mistake of thinking they’re a good proxy for what their users want. Don’t make this mistake! Especially when usability testing with actual users is relatively cheap when compared to the cost of the added software development time you’ll spend on a feature. That cost is only compounded when you find out nobody wants the feature or can figure out how to use it.\u003c/p\u003e\n\u003cp\u003eWhat is usability testing? Simply put: You put something (a sketch, a wireframe, a prototype) in front of people who will actually be using your product at some point in the future and collect feedback, as soon as possible. Don’t be afraid to show users something that seems unfinished. You don’t need to act on every piece of feedback, but look for common themes, and if the theme repeats enough times, turn it into a feature. Add this feature into the next versions of your sketches or wireframes, or into the product itself.\u003c/p\u003e\n\u003cp\u003eIf you can, avoid building things that are completely untested. It’s fine to stand in as a proxy for your users when building a cheap \u003ca href=\"https://www.usability.gov/how-to-and-tools/methods/wireframing.html\"\u003ewireframe\u003c/a\u003e or first sketch of the page, but make sure you test the wireframe with actual users before building out the software version. As a product owner, you’ll need to help surface real users that your team can talk to, and not just other stakeholders or “proxy” users. The \u003ca href=\"https://18f.gsa.gov/2015/08/10/18f-design-methods/\"\u003e18F Method Cards\u003c/a\u003e are a good place to start if you’re looking for actual testing techniques.\u003c/p\u003e\n\u003cdiv\n  class=\"image\"\n\u003e\u003cimg\n      src=\"https://s3.amazonaws.com/digitalgov/18f-method-cards-banner_w800.jpg\"\n      \n        alt=\"Various 18F Method Cards in a pile\"\n        srcset=\"https://s3.amazonaws.com/digitalgov/18f-method-cards-banner_bu.jpg 48w,https://s3.amazonaws.com/digitalgov/18f-method-cards-banner_w600.jpg 600w,https://s3.amazonaws.com/digitalgov/18f-method-cards-banner_w400.jpg 400w,https://s3.amazonaws.com/digitalgov/18f-method-cards-banner_w200.jpg 200w\"\n\n      sizes=\"(max-width: 800px) 100vw, 800px\"\n    /\u003e\u003c/div\u003e\n\n\n\u003cp\u003eYou’ll also need to learn to let go of what you think are “must-haves” (and convince your higher-ups to do the same). It doesn’t do any good to do usability testing if you’re going to ignore the results. Think long and hard about what makes these desired features or content so critical. If it’s just confusing your users, it’s doing more harm than doing nothing at all. If another stakeholder is demanding a feature, present the evidence to them. Incorporate their feature into a wireframe and test both versions. You can even invite them to the test, if they agree not to interfere. In my experience this is very effective at quelling the problem of “design by committee.” You might call it “evidence-based designing.”\u003c/p\u003e\n\u003ch2 id=\"whats-next\"\u003eWhat’s next?\u003c/h2\u003e\n\u003cp\u003eWatch for the next post to learn about how to demonstrate the value of these practices to other stakeholders and executives in your organization and how to get their buy-in for working differently.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cstrong\u003eDisclaimer\u003c/strong\u003e: Any references to specific brands, products, or companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.\u003c/p\u003e\n"}
  ]
}
