October 12, 2020

How to Rescue a Project

Have you ever joined a project that was far behind schedule, significantly over budget, or seemed like it wasn’t making forward progress? If you’re in the world of software, odds are you have at one time or another.

If you find yourself on a rescue mission, know that you’re not alone in the struggle. Rescue projects are some of the most difficult projects to join. They also have the potential to be some of the most rewarding or beneficial to your company.

In the next few paragraphs, I’ll be sharing four bits of advice to consider when trying to get the project ship from sinking. Ready to get that ship back sailing? Let’s do this!

Gather as much information as you can about the project

    After joining, it will quickly become apparent that there is confusion and disagreement about where and how to begin fixing things, what needs to be changed, what is the shortest path to delivering value, and even understanding the scope of what needs to be done. So how should a person or team approach a rescue project?

    Read any and all documentation the project has generated. Go through every page on any project website, public facing or internal. Talk to project members to gather documentation locations as projects typically have multiple locations where documentation is located. Even if the documentation is old and known to be out-of-date, it still provides good context on project history.

    When gathering information, keep in mind that there may be content that conflicts. As technology professionals, we value consistency and order and it may be frustrating to read conflicting content, especially if it’s unclear which is correct and/or up-to-date. Or maybe none of it is up-to-date. But keep in mind that all information about the project will provide either current state, previous state, or context about how the project has progressed. All this information will almost certainly be valuable at some point. Consider the last time you were in a meeting and someone brought up something you didn’t know existed on your own project. That’s expected in the beginning, but the sooner you can get past that stage the faster you’ll be able to be a valuable project resource.

    Assess

      Whether you’re just joining the project or you’ve been on the project for a while, take a step back and do an assessment. What are the strengths and weaknesses? What needs to be changed to result in the project delivering value faster? Are there any documents you think would be helpful but don’t exist? Take your own ego out of the equation. If you were in your client’s shoes, what would you expect or need?

      Even if you haven’t been asked to write an assessment document, create one anyway. Write up a background of the project to date, list the current state, list any future state vision, and enumerate the goals of the project. Then start listing the changes you would make and the reasoning. Pay close attention to staying objective when suggesting changes. After you’ve been on the project four to eight weeks and have a fairly mature assessment document, share it with your fellow project members and ask for feedback and/or corrections. It may start a discussion about what changes need to be made.

      While writing the assessment document, keep a list of documentation that doesn’t exist (or you just didn’t find yet) that would have helped you understand the project better. List in the assessment recommendations to create this documentation, which may help not only current project members but the next new project member get up to speed faster.

      Projects are People

        When talking about a rescue project, I’ve heard it said that “tech is easy.” It doesn't mean that fixing technical issues is always easy, but rather that fixing technical issues is easier than fixing team issues. Projects are collections of people who work together to accomplish a goal. By definition, a rescue project usually consists of a team or team members that are not working as well together as they could to accomplish their goals.

        Consider that, in small group communication, there are multiple phases the group must go through before it can work together effectively to accomplish goals. As new members join there will inevitably be a regression in the stages as new members assert themselves and the group adjusts to a different dynamic. Take this into consideration before making assumptions or assertions about past project members and roles.

        If there is conflict then that means that not everyone agrees on what is best or the way to go about achieving shared goals, but don’t assume that project members are being difficult just for the sake of being difficult. At the end of the day, with very few exceptions, everyone is doing what they think is best for the project.

        Change Takes Time

          As motivated workers, we want to start fixing the project right away. We want to see our progress reflected in the timeline or the budget. We want to make a difference! But realistically change takes time. And the amount of time that takes has some relation to how long the project has been in existence. So don’t get discouraged when weeks or even months go by without seeing the change you think should happen, or even when you see what looks like a regression. Continue to work hard and put in your best effort. Often change comes suddenly and unexpectedly, so just when you think it’s never going to change may be right before you get surprised.

          All Aboard

          Rescue projects are some of the most challenging and rewarding projects one can be assigned. Whether you wanted to be assigned to the rescue project or not, approaching it with a positive attitude and coming prepared will lead to outcomes you can be proud of. And you never know, you just might help the project sail off into the sunset.

          September 14, 2020

          Philanthropy Driven Development

          Philanthropy Driven Development

          Bringing the strengths of the nonprofit sector to software development.

          About a year ago, having spent the majority of my career studying and working in the nonprofit sector, I decided to take the plunge into the world of software development. With a year of experience in the tech space under my belt, I’ve found myself reflecting on all I’ve learned working in both sectors and what these two seemingly disparate worlds could teach the other.

          To be a bit more specific, the primary driver of the nonprofit sector is philanthropic, mission-driven thinking. In practice, this way of thinking is all about channeling our noble, empathetic inclinations strategically to bring about a greater good. Philanthropy, at its best, directs us to recognize needs, uncover their source, define remedial actions, and get to work.

          So what can this way of thinking offer the world of software development? Below are three primary ways tapping into the power of philanthropic thinking can drive development and bring a fresh perspective to your next project.

          Empathetically Identifying Gaps

          A primary goal of philanthropy is to account for the gaps where unmet needs are present in a unique context. In practice, both in a nonprofit and tech context, identifying gaps is often no small task, especially when we have become accustomed over time to tackling day-to-day operations in specific ways. In the words of Aristotle, to account for these gaps and address them “[T]o the right extent, at the right time, with the right motive, and in the right way,” is an elusive endeavor.

          Philanthropy, or the love of mankind, is at the heart of successful innovation in technology, not just because charitable giving improves public perception, but because it provides a uniquely empathetic mindset, that when channeled strategically, can drive adoption and usability, which in turn drives bottomline results.

          Consider, for example, how your users experience your product. How are you currently seeking to account for their contexts, backgrounds, affinities, joys, and frustrations? From the perspective of philanthropy, approaching customer experience philanthropically is an effective way to put yourself in their shoes; however, this should be done with an empathetic eye for even the most subtle gaps in their experience and a continually application of Aristotle’s four principles of addressing these gaps, namely, extent, timing, motivation, and approach.

          Uncovering Needs at Their Source

          As the old adage goes, “Give a man a fish and feed him for a day, but teach a man to fish and feed him for a lifetime.” Philanthropic thinking directs us to recognize needs and uncover their underlying sources. The primary goal of philanthropy from this perspective is to calibrate the trajectory of our actions to most effectively alleviate and bring about a better world.

          Consider how many products have been developed over the years that overwhelmingly missed the mark. If you boil it down, these products have often failed because the perceived need was misaligned with actual need in the market. Blackberry phones is an often cited example that comes to mind.

          Often needs we are quick to identify are merely symptoms of a larger issue. Steel Tycoon and philanthropist, Andrew Carnegie experienced this firsthand as a boy of humble origins living in Pittsburgh. Having been given access to the personal library of his employer as a young man, he attributed this opportunity for education, at least in part, to his success as a businessman and paid it forward by building free libraries. In essence, he recognized poverty as a symptom of lack of access to education and created a library system that still stands today helping address the source of this need.

          In the tech space, philanthropic thinking, at its best, can help to bring alignment between perception and reality by fostering conversation with observation. The primary idea here is to channel philanthropy’s inherent empathy in market research to identify and inventory the needs your product seeks to address, and verifying the source of those needs through end user observation. It provides the opportunity to capture impact metrics, again, through conversation and observation for the sake of continual improvement.

          Supporting Agile Team Dynamics

          Finally, philanthropic thinking provides the framework for building healthy and effective team dynamics and ungirds the servant leadership mentality essential to an Agile development context.

          Philanthropy, as a discipline, is all about recognizing the best in ourselves and leveraging those strengths for the good mankind. In an Agile context, a philanthropic mentality is at the heart of generous ideation, iterative development, conversation, sustainability, interdepartmental collaboration, and embracing change as it opens us up to being part of something bigger than ourselves.

          We part a great deal of emphasis on being iterative in our development, but often spend little time being iterative with our mindset. So as you approach your next project, consider what philanthropically driven development can offer you and your team. Take some time to consider what gaps may not yet be identified, seek out the source of the need you are seeking to address, and bring inspiration to your team.

          May 27, 2020

          Making Javascript a bit sweeter: Yarn berry(v2) and its usefulness.

          How'd we get here?

          In the 2019 not-so-official state of Javascript report, I heard the undertones of anguish and grumbling towards the javascript ecosystem, but whats new right? People have been complaining about Javascript since its three week incubation and subsequent birth. For good reason.

          Example, executing random type additions:

          > "" + {}
          > "[object Object]"
          > {} + ""
          > 0

          But…somehow, through all the pain and chaos, we have come together as a community and have made this language somewhat bearable to work with.

          In 2012, Typescript was born and all of a sudden you could add Types!.to!.Javascript! as ForSortaRealNow.

          In 2015 there were whispers of something called the webpack and react and all you had to was provide a small sacrificial offering, followed by installing the universe of npm modules to use them. Only then, would you be on your merry way.

          In 2016, 2017, 2018, and 2019 if you updated a package and something broke, there was usually at least one GitHub issue that would say something nonchalantly like “Breaking change, no take backs”, and then go on to explain why you would be spending the next three days upgrading all your dependencies and refactoring your whole application. By the way, if this was you, I personally want to say “You’re a hero”.

          Jokes aside, 2015-present has really been a journey of intense growing pain, but I personally believe we are on the brink of a new era of Javasc–cough Typescript. Yarn V2 just came out, and I am seriously more pumped about the ecosystem than ever. I would put this change on the same level of importance as the move to ECMAScript 6. Yep I said it. Let me explain why.

          Yarn V2

          Workspaces

          Workspaces were a concept in V1 of Yarn, they should be thought of like a module. You .NET devs can think of them like a project within a solution. They are a good solution for a monorepo, but in V1, a lot was left up to the developer to get all their dev tools (Typescript, Webpack, and VS Code, etc) all on the same page as to what was going on with those workspaces. I remember it took a week or two for me to just get file resolution sorted out between all of that, and I know for fact, that setup was custom…and not quite right. 🙂

          After you have gone through the migration to yarn berry, you can set up a more realistic and safe monorepo without worrying (too much) about how those workspaces are going to get resolved. Workspace resolution is treated as a class one citizen now. It even has its own protocol.

          Assume the following directory structure

          root
           - packages
               - web
                   - src
                       - data
                       - components
               - api
               - shared
          

          To reference another workspace from the web workspace, use the workspace protocol . Example:

          root/packages/web/package.json

          "@repo/shared": "workspace:packages/shared"
          
          example use:
          
          import SomeSharedThing from "@repo/shared/SomeSharedThing"
          


          Okay, but why was this a problem in V1 and why does it work better now?

          Plug’n’Play, Plugins, and File/Module Resolution

          The Problem: Resolvers.

          Here is an excerpt from the yarn docs linked above that explains it well:

          “Over the years that led to Plug’n’Play being designed and adopted as the main install strategy, various projects came up with their own implementation of the Node Resolution Algorithm - usually to circumvent shortcomings of the require.resolve API. Such projects can be Webpack (enhanced-resolve), Babel (resolve), Jest (jest-resolve), Metro (metro-resolver), …”

          This means that if you wanted to combine and use different technologies that use different file/module resolving strategies, you would likely be dealing with configurations to make sure files are being resolved correctly.

          But no more. No more tweaking aliases in configs. No more help from random third party resolvers, etc. No more.

          The Solution: Plug,'n’Play(pnp.js)

          Yarn V2 solves the file resolution issue through the use of the pnp.js file and their plugin strategy.

          • They introduced the concept of the pnp.js file (If you have ever used webpack stats, it is similar to that). Basically it’s a file that declares explicitly what dependencies/workspaces depend on and where those packages are all the way down the dependency tree. It then during runtime(think webpacking) can intercept calls to modules, and provide a virtual link to where yarn is keeping those modules now which by default are zipped within its cache folder. For developer tools like eslint, typescript and vs-code they wrote a pnpify module that basically fakes the existence of the node_modules folder for the same purpose. This is temporary until those tools can support pnp out of the box.
          • Yarn V2 is built primarily using a plugin strategy. Things like commands are even plugins(e.g yarn add). Along with commands, they have also built plugins to wrap how files get resolved from different mainstream file resolvers.

          Together with the pnp.js file, and plugins, they can look to see what module resolution a package depends on (via the dependency tree) and then tell Node exactly where to find that module/package.

          Zero Installs

          Yarn berry has some great documentation around this topic. Zero installs is not a feature specific to yarn berry, but it is by far more possible because of it. Since, node_modules are no longer a thing, and instead the yarn cache is maintained through compressed .zip files, It is much more feasible to commit these to your repository. Zero installs is configured purely through .gitignore. You can choose to do so or not. Read more about it here.

          I have decided to jump aboard, and have not regretted it one bit. It improves workflow all over the place, specifically around switching branches during the PR process and the build process itself.

          Constraints

          Yarn 2 has the option to provide constraints. Constraints are rules about your dependencies. Yarn has defined a few of their own constraints, but you can also create your own.

          The yarn maintainers are using a programming language called Prolog to create these constraints. Prolog is a fact based engine. Think of it as a database of facts that we can query against and determine if something is true or not.

          From what I understand…upon running yarn constraints yarn berry generates a database of facts using the projects workspaces, and dependencyTypes(dependencies, devDependencies, etc) and in plain english those sound something like

          “fact: the workspace someWorkspaceName depends on Lodash version 4.4.2 in devDependencies” -yarn docs.

          Then it gobbles that list of DB facts, the predefined rules yarn has provided, and the source file the end user provides for custom constraints(constraints.pro by default). After that it loops over a list of query results provided by tauProlog’s(JS wrapper around prolog) query method and generates an array of enforced Dependencies.

          Now constraints like Uncle Bobs dependency rule are much more possible and more importantly, enforceable.

          This rule says that: “source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.” - Uncle Bob

          Constraints are still in newborn status, but I plan on using them.

          To wrap up. I have a lot of hope for Yarn v2. The lead maintainer @arcanis is someone I have come to respect, and is someone who not only sees the issues of the JS ecosystem, but has solved those problems. IMO, Yarn V2 is the future of the JS/TS ecosystem. At least until Deno takes over.

          March 27, 2020

          Leadership in the time of COVID-19

          I think it’s reasonably safe to say that when I first started at DeveloperTown in 2014 I was not expecting the following two things to become a reality: that I’d last in a software development consulting firm with no software development knowledge and that I’d eventually write a blog post about leadership in the midst of a global pandemic.

          Both are true at the moment. I’ve come quite a ways from being clueless about what an API was or in the dark about things such as pull requests. (Quite naturally, as a 16 year old boy stuck in a now 33 year old’s body, I assumed a PR had to do with a rather gaseous bodily function and my index finger.)

          But here we are. Slightly more knowledgeable about software and spending most of my time indoors as our brave medical men and women, delivery drivers, teachers, grocery store clerks, and city employees are on the front lines. It’s a scary time. A time where I often wonder what should we be doing? Who is going to stand up and lead? How should they be doing it? And what about us that are not guaranteed a future? What about our jobs? How are we going to make it?

          These questions are undoubtedly floating through your head and the head of your bosses, coworkers, and employees.

          And if you find yourself in a place of leadership, now is the time to answer those questions.

          One of the many reasons I’ve stuck around at DeveloperTown is the fact that we have strong leaders. Leaders who are trying to answer those questions. Leaders who I trust will do the right thing, not only for the business but for their employees as well.

          But what does the right thing look like now? I have a few suggestions that come straight from the DT leadership playbook.

          1. As a leader, it’s more important than ever to communicate with honesty and empathy. People are going to create their own narratives if they don’t hear one from you. They may even create one if you share the truth over and over. But they deserve to know where the business stands and where you see it going. If you don’t know, that's okay too. Tell them what you do know. No sugar coating, no false hope, no unneeded dread.
          2. The best way to reduce anxiety is to start thinking about what your organization can do for others. How are your clients feeling at this time? Serve them with grace and care. Demonstrate this to your team. Vocalize it over and over. There’s never been a better time to revisit your mission statement and remind yourself and your team that now is the time to serve others. It’s really hard to worry about yourself while you’re helping someone else.
          3. Samuel Johnson was quoted as saying, “People need to be reminded more than they need to be instructed.” I happen to agree with him. Set up recurring touchpoints with your team to celebrate their wins and check in. Be available. A great example of this would be a now weekly virtual coffee social via Google Hangouts at DeveloperTown. An employee put it together and it’s been a highlight of this time in quarantine. It’s a weekly reminder that we’re in this together...and that some of us have very fun coffee mugs.

          Leadership in the time of COVID-19 doesn’t have to mean a monumental, solo effort for only those at the top. But for those who find themselves in or identify with a leadership role, now is the time to communicate, serve others, and regularly remind our teams that we’re in this together.

          When things get tough, it’s up to good people to stand up and do our part. Luckily, that means all of us get to help.

          Even those of us who start blog posts with a fart joke.

          March 17, 2020

          Tech Talent: How to How to Beat Your Competition in Today’s Talent War

          With the unemployment rate hovering below 4% nationally, companies all over are fighting to snag the best candidates on the market. To win the talent war, you've got to get creative on how you attract the talent your business needs to grow and succeed. But how can recruiters and talent management folk do just that? Well have no fear. We’re going to cover a few different tactics you need to be using to make the recruiting process as efficient and painless as possible.

          First, let’s talk communication. This sounds like a no-brainer but thorough communication and follow through can be your competitive advantage against your fellow recruiting peers. I can’t tell you how many times a candidate tells me about a bad experience they’ve had with a recruiter, and usually it's always focused around poor communication. From first look to first day, it’s imperative to set expectations as to how and when communication will occur. Sometimes, even text check-ins are sufficient, but whatever you and your candidate agree to, don’t let them fall into the forbidden resume black hole. Even if you simply check in to say that you don’t have an update, that will go a lot further than radio silence. It’s important to have empathy for your candidate, as you certainly wouldn’t want to be forgotten about.

          Next, let’s discuss candidate applications. Majority of candidates are applying to jobs from their mobile devices. Have you taken the time to test your company’s career page and apply to an open role via mobile? How long does the process take? Are there tons of questions/forms needing to be filled out? If the mobile application process takes over two minutes, it’s time for a change. Once you’ve simplified the mobile application process, look at the job description you or the hiring manager has written. Essentially, candidates want to know three main items: an overview of the company (culture), an idea as to how they’ll impact the business and the expertise needed for the role. Provide four to five bullets per section, no more is needed. Ideally, you are trying to cast a wider net, and if you have an abundance of “requirements” even some of the most qualified applicants may not feel they’re qualified for the role, thus won’t apply at all.

          Last, be ready to battle the dreaded counteroffer. Companies know how hard it is to find talent, and subsequently they don’t want to lose that talent. Educate your candidates on why accepting a counteroffer is never a good idea. I read a few years ago a study which said 80-90% of candidates who accept a counter offer from their employer end up leaving within the following twelve months. Currently, I’ve found money is not the most pressing factor for candidates to want to leave their organization. Career growth/opportunity and feeling of purpose are on the top of the list. Remind your candidates as to their motivating factors for wanting to leave, and why you started the conversation with them in the first place. Being their sounding board builds trust in the recruiting process, and proves you are truly their advocate.

          Winning the talent war doesn’t have to be a monumental task. With the right mindset and preparation, your organization can win the battle and set yourselves up for long term recruiting success.

          February 3, 2020

          Hiring Consultants 101: Hiring an Expert

          Hiring an Expert

          On our blog, we’ve talked about several aspects of what to look for when looking for delivery partners, and today we’re going to take some time to dig into what it means to “Hire an Expert”, and how to identify one. This is a critical skill that really needs to be sharpened if you’re going to be working with someone to facilitate and accelerate your projects. We’re going to look at why you should or shouldn’t hire an expert, and what makes an expert, well... an expert!

          We Need Help (Resources)

          You’ve decided that you need help with your project and that’s a huge step. The next phase is when it gets challenging. You have to find out WHO can help you. Do you need more resources to do more work or do you have bigger decisions to make? If you just need resources, you’re probably not looking for an expert. Don’t get me wrong, you may need very Sr-level resources with huge skill sets, but you’re looking for delivery and that means you’ll want to screen contractors or use a trusted partner to supply you with proven resources to get the job done.

          We Need More Than Just More Resources (An Expert)

          When more input is needed to your process than just solid delivery resources, you’re probably going to need an expert… at something. The What and When and Why of that decision is a topic for another post, right now we’re going to dive into what you’re looking for in an expert.

          An Expert Is...

          An expert is a thought leader, which means that they are well-equipped to engage in your process at levels broader than the nuts and bolts of delivery and can contribute meaningfully across a broad range of team activities. They also have three key characteristics that can make or break an effort:

          1. Experts can communicate with the team

            We specifically chose the word “communicate” instead of “talk” or “engage” because communication implies that the concepts that they are conveying are understood more or less intact by the team at all levels, so that aligning everyone happens naturally through the course of regular communication.

            Some teams are resistant to outside input, we’ve seen some pretty hairy conversations develop around hot project topics, but part of communication is wading into the mess and working to sort it out.

          2. Experts have opinions and rational, defensible reasons for them.

            An expert will present a cohesive vision for how delivery looks in their ideal world, be able to tell you why this is a good option for your business, and be able to answer the “Why” behind their vision.

            We’ve been in many situations in software development where someone has presented a path forward to me and given me options for two to three different implementation stacks, along with a nice list of pros and cons for each. That’s great, it really is, but doing research and pro/con lists for a tech stack is something we would expect one of our delivery people to be able to do.

          3. Experts will know (and tell you) when you don’t need them

            Sometimes the expertise doesn’t match the need or is at the wrong point in the process, or… whatever else. For some reason things just aren’t matched up right. An expert will come to you with these concerns and let you know when the fit isn’t right. In many cases they may even be able to recommend someone in their network who could be a better fit.

            This can be a hard pill to swallow on both sides, but it’s a matter of knowing where personal limits are and understanding that not everything can work out every time. When a mismatched relationship is forced, the stress eventually fractures the relationship, and oftentimes leaves the project in an uncertain state of success or failure. An expert will do everything they can to prevent that.

          There are many, many more characteristics that make experts valuable, but the core value around it all is that they will all be dedicated to your success because they know that’s how they achieve success as well.

          To Hire, or Not To Hire… That is the Question

          Whether or not you need an expert is a highly situational and business-driven decision that will need careful consideration whenever it comes up. It’s important to make sure that when you do engage, that you maximize the value of your expert by taking advantage of their skills and outsider perspective and be open to the ideas they bring to the table. They are opinionated, but flexible, and can shed invaluable light on parts of your process or plan or implementation that we in the trenches are often too close to see clearly.

          November 6, 2019

          SAP Fiori Design System for Figma

          SAP FIORI Design System for Figma

          Google has rolled out the newest update for Android. Android 10 update brings with it some big features including Live Caption, Smart Reply, Dark Mode and much more. The OS is available in general release now. We’ve created the Android 10 UI Kit to help designers crank out beautiful designs with the most up-to-date Android UI! UI Kits are now available for both SketchApp and Figma, and you can download them all below.

          WHAT'S IN THE KIT?

          As with our last kit (Wear OS), we have vector screen designs created based on extensive research of the OS, including a ton of reusable symbols. This kit includes all of the main updates in the new OS, as well as some default app screens, and vector app icons. You’ve got everything you need to show off your awesome new app designs!

          UI KIT REQUIREMENTS

          You'll need the latest version of Figma or SketchApp and Google's Android System fonts, Roboto and Roboto Condensed. You will also need Google’s Product Sans font (aka Google Sans), which we, unfortunately, cannot provide for you. You can find a copy of the font relatively easily online, or you can replace it with Avenir Next, which matches it very closely and is included in Mac OS.

          DOWNLOAD THE KIT

          Download the Android 10 UI Kit for Sketch here.

          Or for Figma, just go here: https://www.figma.com/file/sPtWiyISe38J78ydGdq4rN/Android-10-UI-Kit?node-id=0%3A1

          DISCLAIMER

          Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!

          WANT MORE UI KITS?

          Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!

          November 6, 2019

          Android 10 UI KIT

          ANDROID 10 UI KIT

          Google has rolled out the newest update for Android. Android 10 update brings with it some big features including Live Caption, Smart Reply, Dark Mode and much more. The OS is available in general release now. We’ve created the Android 10 UI Kit to help designers crank out beautiful designs with the most up-to-date Android UI! UI Kits are now available for both SketchApp and Figma, and you can download them all below.

          WHAT'S IN THE KIT?

          As with our last kit (Wear OS), we have vector screen designs created based on extensive research of the OS, including a ton of reusable symbols. This kit includes all of the main updates in the new OS, as well as some default app screens, and vector app icons. You’ve got everything you need to show off your awesome new app designs!

          UI KIT REQUIREMENTS

          You'll need the latest version of Figma or SketchApp and Google's Android System fonts, Roboto and Roboto Condensed. You will also need Google’s Product Sans font (aka Google Sans), which we, unfortunately, cannot provide for you. You can find a copy of the font relatively easily online, or you can replace it with Avenir Next, which matches it very closely and is included in Mac OS.

          DOWNLOAD THE KIT

          Download the Android 10 UI Kit for Sketch here.

          Or for Figma, just go here: https://www.figma.com/file/sPtWiyISe38J78ydGdq4rN/Android-10-UI-Kit?node-id=0%3A1

          WANT MORE UI KITS?

          Check out DeveloperTown's handcrafted Material Design 2 Kit and Apple TV UI Kit. You can also follow us on Dribbble!

          October 10, 2019

          Product Owners Need Sleep Too

          It’s not easy being a Product Owner. You are responsible for ensuring that your products provide real value to your business and most importantly, your users. You have deep knowledge of the business strategy and market in order to help outline the product requirements for the team. You are the point of contact for almost everyone involved or interested in the project, and that can be overwhelming. How can you stay engaged, support the development team, keep your stakeholders up to date, and ensure the success of the project while still having time for, you know, sleep and eating? That other important stuff.

          Well have no fear because we’ve got your back. Below, we’ll talk through a few tips and tricks that our busy product owners could use to make sure their time is maximized.

          1. Detail the “What” not the “How”

          With your limited time and energy, it’s more important to focus on defining “what to do” rather than “how to do it”. As a subject matter expert who knows the product, the team, and the business requirements, it’s understandable that you may want to help define how something should be done. Avoid giving in to this feeling. You have a team who will be doing the work and they need to be the ones to focus on how they’ll complete something. Your company hired them for a reason after all. By keeping your focus on what needs to be done, and allowing them to work through how it will be done, you empower the team while giving yourself the time you’ll need to deliver a complete backlog with effective prioritization. And maybe try that new taco joint you’ve been eyeing for months.

          2. Provide Detailed Acceptance Criteria

          Believe it or not but most people can’t read minds. As the rockstar Product Owner you are, you know this and should try to communicate as effectively as possible. The team needs to know what you require from each feature rather than making their own assumptions. (Didn’t someone say something about how assuming goes poorly?) If acceptance criteria are unclear, features may be implemented incorrectly, which never leads to good outcomes.

          How can you ensure you’re providing all the needed details? Here are a few thoughts

          • Ask to add acceptance criteria review to your planning meetings. Take time to talk through each feature and what you think it needs in order to be complete.
          • Ask the team for help because it’s often easier to define what you want if you’re able to hear their perspective. Don’t be shy to ask if they’re able to supply you with their suggestions for acceptance criteria for any features you’re having trouble defining.
          • Ask one of your QA folk to review the stories. They’ll be testing them and can often provide invaluable feedback on how to write and provide better acceptance criteria.

          3. Attend Scrum Ceremonies

          Attending Sprint Review, Sprint Planning, and daily standups with your team is necessary for you to fully understand and be aware of the project’s current state. You need to be in the room to communicate with the team that a feature is truly “done” so that the team moves on from completed work, and does not linger on completed features. You will also know what is happening with the project and be able to effectively communicate current status, priorities, and next steps to stakeholders.

          But what if you can’t attend every Scrum ceremony? It happens. In that case, here are some suggestions to make the best of your busy schedule:

          • Identify a “sub PO” and make them available to the team for day to day needs and to help get questions answered. Make sure you give this individual the authority to make decisions and the background to make sure those decisions align with your vision.
          • Ask your Scrum Master to group questions and needs from the team and set up a weekly meeting with you to review. Setting up a weekly time for you and the team to meet and review every week can make your life easier if attending the ceremonies just isn’t doable.

          4. Having Your Cake and Eating it too

          Product Owners are busy and with good reason. You’re responsible for ensuring the delivery of the right product at the right time, answering to the development team and to other key company stakeholders, while generally managing other responsibilities as well. In a perfect world, you would be available to your development teams at all times, but that is rarely possible. Life is busy and we’re all trying our best. But with a focus on attending scrum ceremonies, providing detailed acceptance criteria, and maintaining a clean backlog, you’ll be well on the way to ensuring the development team is provided with the information they need to help you deliver an outstanding product. And maybe even getting to finally take that vacation you deserve.

          August 23, 2019

          Is Outsourcing Right For You?

          In my last blog, Choosing the Right Software Development Partner, I talked about finding the right partnership when hiring contractors and consultants. I focused on the WHAT of that partnership. Today I’m going to dig into the WHY, and clarify some of the big questions around outsourcing to help you make a more informed decision about when it’s the right move.

          Doesn’t outsourcing cost more?

          This is an easy conclusion to jump to when simply comparing raw project costs in the ideal situation (you have all the resources needed and they have all the required time, skills, and availability to complete the project). Since reality is not often ideal, there are many reasons to consider an external delivery partner, and one of them is cost savings. Here are some examples of when a delivery partner can help save your bottom line:

          You have a project that needs completed, but your staff has no additional bandwidth.

          Projects like this are extremely common, and the cost of completion comes in 3 flavors with their T-shirt sized project cost beside them:

          1. Staff an FTE (full time equivalent) team to complete the project (S)
          2. Hire an outsourced team (L)
          3. Mixed team (M-L)

          Based on project cost, a full staff of FTEs may seem like the best option here. While all three options will get the job done, there’s more to consider than just the project’s delivery investment. Mixed and FTE teams come with ongoing expenses related to the new FTEs, which devour project cost savings very quickly. Additionally, these resources incur administrative overhead of mandated intake training/orientation that consultants and contractors are often not subject to. Once the initial phase of the project is complete, and you have evaluated the ongoing support needs, you will be able to more clearly gauge how many FTEs are required to keep things running smoothly.

          Project completion requires skills and experience your staff doesn’t currently have

          You can send your staff to training, and for something that is going to require ongoing work, you definitely should. However, when there’s a tight deadline, consultants and contractors offer a means of injecting your organization with the skills and manpower to bridge the gap as your team comes up to speed. In most cases, your delivery partner will provide shadowing and training opportunities to make the handoff to your team as smooth and painless as possible.

          You need a Proof of Concept to get organizational buy-in

          When the paper evidence just isn’t enough, building a proof of concept (POC) can make a very strong argument to fund a project. Unless you have the resources with time to burn sitting around looking for work, someone else is going to have to build it. Whether it’s a clickable prototype, process design framework, or any other kind of asset, outsourcing a POC can be a big win. This avoids the risk of hiring new staff with the skills to work on a project that may or may not get the green light. It has the added benefit of establishing a relationship with a resource who can be called on to produce the full product when the time comes.

          Won’t the consultants take too much knowledge with them when they leave?

          If you feel like this is substantial a risk, you have made the wrong choice in delivery partners. There is never a sure-fire way to get a 100% perfect hand-off every time, but truly excellent firms will work with you to transition as much knowledge and information to your in-house team as possible based on the long-term sustainability plan for your product or service offering. Depending on your deadlines and budgetary constraints, this may not be part of the initial Scope of Work (SOW), but is always something you should ask about and know what the plan is ahead of time to ensure everyone’s expectations are met. A couple different variants of this process exist:

          • Training sessions, provided by your partner, in the form of classes/seminars to get your in-house team up to speed and bridge knowledge gaps
          • Transition meetings where the focus is entirely on shifting current and ongoing delivery responsibilities to your team
          • On-demand support for your team. This option is typically in the form of a support contract, which is a whole different type of engagement, and not every firm is willing/able to commit resources to this kind of project

          No matter the approach, the most important aspect of maintaining the deliverables once your partner’s involvement has tapered down is to make sure that you have the resources in place during the transition to pick up the torch for your business and keep things moving. The earlier the better!

          How will I coordinate with outsourced resources?

          There is a wide variety of options when outsourcing work, but don’t take “Outsourced” and “Offshore” to be the same thing. Here are the three main kinds of outsourcing, and what makes each unique.

          Offshore

          For simplicity, offshore resources are generally teams based in India or other places abroad, typically not in the same hemisphere as your business (I chose India specifically because that’s where most of the offshore teams I’ve worked with are based). The advantage is usually clear here in the way of rates, as offshore resources tend to be much less expensive per hour than Nearshore or Local resources. The downside here is largely around logistics and communication. With a (literal) half a world between them and you, coordination can be a very big challenge, from meeting times to productive hours of the day, there’s challenges all around. Many delivery partners will provide a liaison to help bridge this gap.

          Local

          Local resources are generally within a timezone or two of your business, maybe in your town, and possibly even onsite at your location either regularly or on a prescribed cadence. Local resources tend to be more costly than offshore or nearshore, but are great for several reasons, one of which is the fact that they are the easiest to coordinate and integrate with your team. They will also usually not require an additional liaison to bridge time, communication, or cultural gaps in interactions.

          Nearshore

          Nearshore resources are a kind of hybrid of local and Offshore, and that’s reflected in their pricing as well. Working with a delivery partner with nearshore options can help ease the cost of projects as a whole, and will usually still involve a local liaison to ensure that delivery is timely and expectations are met on both sides. The primary difference between nearshore and offshore is that nearshore tend to be in the same hemisphere as you, so these resources have much less trouble aligning meetings to typical business hours or getting on a call at some time of day that works for your people too.

          So, is it right for me?

          Unfortunately there’s no magic answer that works in every situation, but here is a quick set of questions to kick-start the decision-making process:

          1. Can we complete this in-house today?
          2. Can we deliver this in-house in a timeframe that meets or exceeds the business goals for this project?
          3. Will this project require ongoing support/development?
          4. Will adding outsourced resources cause internal friction within our organization?

          If you answered “No” to all of these questions, there’s a good chance that an outsourced delivery partner could really reduce your delivery timeline and improve your ROI.

          At the end of the day, it still comes down to evaluating the risks and rewards. The decision to outsource all or even part of your delivery team is always a very financially, and culturally, dependent process. Knowing where your project is most affecting your bottom line, understanding the project’s ongoing needs, and selecting the right delivery partner can mean the difference between good enough and great, or even success and failure.