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.

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.

Hiring consultants or contractors is a challenging process, and choosing the right partner for your needs is critical. In this article I’ll explore some key areas of partner selection, and how to determine the fit of a consultancy with your business.

Consultants or Contractors?

This is the very first decision you need to make to select the right partner. Many people use the words interchangeably, but these are two completely different kinds of resources. Choosing consultants when you need contractors can mean spending more money than you need to, and choosing contractors when you need consultants may leave you feeling like your money was not well spent.

So what’s the difference:

Contractor:

• Skilled in production
• Focused on task completion
• Expects an environment where work is directed by managers
• Does not need to understand your business

Consultant:

• Works to understand your business
• Treats your business like their own (Has the best interest of your business forefront in all recommendations and actions)
• Focused on solving problems
• Able to step back and see the big picture
• Skilled in facilitating
• Skilled in production
• Committed to finding the right solution

There are a lot of differences between these two roles, and this acts more like a spectrum with most individuals falling into some balance between these two types.

Culture Fit

Finding the right cultural fit for your team is critical to the success of any hiring process, whether it’s the right FTE, contractor, or consultant. There are several important points to consider when weighing the options to add an outsourced team or supplement your own (apart from the price tag). Having the technical ability to do the work shouldn’t be the only consideration when making a hiring decision.

Consider these “non-production” factors when selecting a partner:

For Remote Resources

• What is the onsite expectation (if any)?
• What communication tools do you use to facilitate remote work?
• If resources are in different time zones, what availability is needed during your business hours?

For Onsite Resources

• What is the dress code in the office?
• Is participation in corporate events expected?
• Where will they sit?

Talented individuals and groups exist in a wide variety of ecosystems, and while these questions may seem somewhat basic, finding the right cultural fit with your partner will build a much stronger, more sustainable relationship for the long term while keeping both sides of the partnership positively engaged throughout the project.

Business Needs

A surprising number of partnerships end badly because of a mismatch between offerings and needs. You may have a referral from someone who thinks XYZ Agency “does great work”, but being an awesome consultancy or contractor doesn’t automatically make them the right fit for your business needs. Going into initial meetings with an open mind is essential on both sides of the equation. Look at the offerings from the potential partner and ask yourself the following questions:

What does success look like?

Have in mind what a successful outcome of your project looks like. Your partner will help flesh this out in the upcoming meetings, but the more clear picture you have going into the initial meetings, the more likely you are to find the right fit.

Can they do the work I need done?

This is a matter of competency. Does the partner have the necessary technical/delivery skills required to help reach your business goals?

Do their offerings align with and support my goals?

Even if the partner is incredibly qualified to deliver what you’re looking for, that doesn’t necessarily mean they have an offering to support you. Some partners have a process that they are invested in, and may not be willing to sell a subset of services to you. In most cases this is not due to a lack of flexibility by the partner, but a commitment to a process of proven success and a desire to deliver success on every project.

Wrapping Up

There are a lot of factors involved in selecting the right partner for your organization. Contractors or consultants? Individuals or teams? Project work or staff aug? And of course, cost. Always think beyond the needs of the moment, taking the time to understand the values and capabilities of your partner will make sure your choice sets you up for long term success. Make sure you understand the value your partner will be delivering, and how that fits with your organization and business goals.

Forcing Nuget Package Usage in Visual Studio/MSBuild

In this post I’ll discuss a technical issue we came across during a client’s CI/CD implementation for their web site’s deployment. We discovered the core issue was a version difference between development environments, and the machines building deployment artifacts that resulted in the build process failing remotely while succeeding wonderfully on our local machines. What follows is a recap of our discovery of the issue, and the steps taken to resolve it.

NOTE: While this is written in the context of TeamCity, the scenario described can (and almost certainly does) happen outside that environment.

Recently, while working on a .Net project for a client, we ran into an interesting issue with an older version of TeamCity. The TeamCity version in use supported up to Visual Studio 2015, but our project was being developed in Visual Studio 2017. From a framework perspective this doesn’t matter at all, either environment would work equally well when built and run locally. The problem that surfaced during the TeamCity Build was something like this:

The imported project “<ApplicationInstallationRoot>MSBuildMicrosoftVisualStudiov14.0WebApplicationsMicrosoft.WebApplication.targets” was not found. Confirm that the path in the declaration is correct, and that the file exists on disk

Essentially, the MSBuild agent couldn’t find the correct assembly in the “VisualStudiov14.0” folder because that location is the Visual Studio 2017 folder, and Visual Studio 2017 was not present on the server.

A little bit of searching suggested that installing the Microsoft.WebApplication.targets package from Nuget would resolve the issue, so we installed this package:

Eventually it does solve the problem, but there are a few things to know about this solution:

1. Depending on the version of TeamCity, we configured a Nuget Restore step to make sure that the package is restored to the build location prior to the build.
2. Build the application
3. In our case, do an OctopusDeploy: Create Release

Our final process in TeamCity looked like this:

With everything configured and the appropriate Nuget package in the project, all should be well.

Except it wasn’t.

We re-ran the build and got the exact same error we had seen before. This seemed strange, because we could see the package get pulled in the package restore, and the version we were looking for should have been available.

After struggling with a good number of suggestions online, we came across something regarding the .csproj file that looked like it could be a solution. Realizing that editing the .csproj file is not anyone’s idea of a good time, but in dire need of an actual solution, we rolled up our sleeves and dug in.

What we found was interesting.

In the imports section (per some suggestions from googling) we found this line:

<Import
Project="$(VSToolsPath)WebApplicationsMicrosoft.WebApplication.target"
Condition="$(VSToolsPath) != ''" />

This is where the problem originates. The project’s variable $(VSToolsPath) was grabbing the location of the Visual Studio 2015 install, which didn’t have our version of the WebApplication.targets package. That would have been in the Visual Studio 2017 install directory.

Interestingly enough, there was another line underneath it, with an absolute path to where the Nuget package would live, but with a Condition=”’false’” attribute that causes that import to be ignored.

By changing the condition to “true”, the second import was enabled, but a second import gets ignored during build, so we commented out the first.

At this point, it should be noted that the package location here is where Visual Studio thought the package should be on the development machine, so the path for this ends up not being exactly right either. We were able to get the absolute path working by trial and error, but that solution is not ideal, because it leaves you with a solution that is now potentially very tightly coupled to the build environment and its file structure.

In the end, we were able to build an import that both:

• Forces the use of the Nuget package
• Verifies the package is there before importing, so an absence of the package will kill the build very quickly

The final import looks like this:

<Import Project="..packagesMSBuiId.Microsoft.VisualStudio.Web.targets.14.0.0 toolsVSToolsPathWebApplicationsMicrosoft.WebApplication targets" Condition="Exists('..packagesMSBuiId.Microsoft.VisualStudio.Web.targets.14.0.0 toolsVSToolsPathWebApplicationsMicrosoft.WebApplication.targets')" />

This import defines the path as the relative path to the Nuget package, and applies a condition for import that the package is actually present in the folder before allowing the import to happen.

With that in place, the TeamCity build goes off without a hitch, and OctopusDeploy gets its artifact.

It would be possible to provide fallback options for packages by inverting the condition, but in our case we wanted the build to fail outright if the package was not in the expected location.

There are a couple lessons learned here:

1. If it’s at all possible, try and ensure your build machines are running the same versions of things as your development environments.
2. Failing that, it IS possible to force a build to use a packaged version of newer dlls than what is available in your build machine’s GAC… as long as you’re willing to hack around in the project files to make it happen.

Working in client environments can present unique challenges, but with the right tooling, and the willingness to work “off the beaten path” a little, a solution that’s workable and sustainable is (almost) always possible.