Loading

HR|Fin|Marketing

For most organizations, agile is confined to technology development and delivery - but it should not be. As the agile industry matures, innovative companies are taking advantage of the same agile values, principles, and practices that have transformed software development. Now, they are successfully deploying this way-of-work in other business units, from marketing to human resources to finance. When companies implement agile across their entire organization, ways of working improves dramatically. Agile methods are more collaborative, creative, effective, and can be more efficient than other business models. These agile methods such as Scrum, Scrumban, and Kanban are embraced in the Agile Axiom Framework. But companies must first understand why their current business structures needs to change.

Human Resources

Can agile software development principles be applied to the development of human talent? A growing number of HR professionals are exploring the possibilities and looking at ways to manage volatility, enhance adaptability, and strengthen the organization by applying Agile methodologies to their talent-management processes.

Business Drivers for Agile Adoption in Human Resources

  • Improve Predictability and Cohesiveness
    • Collaborate and deliver on promises with "no surprises" in timing or quality.
    • Deliver a cohesive set of products and services across a global employment landscape.
  • Improve Capabilities and Responsiveness
    • Prioritize work to yield the most benefit to stakeholders.
    • Respond quickly to high priorities.
  • Act as "One HR"
    • Align across departments to manage expectations, priorities, decision-making and success.
    • Model collaboration and empowered decision-making to the rest of the organization.

With these goals in mind, agree to embark on a journey to bring Agile practices and tools into the HR Business teams to better manage their products and services. We started by assessing their readiness as an organization to adopt a new set of principles and behaviors in support of Agile. With a clear set of objectives and reasons to experiment with Agile in the business operations, the team made a commitment to undertake an Agile Transformation initiative across both the Business and IT organizations. With goals established, commitment made, and a transformation roadmap in hand, we were ready.

Establishing a Governance Structure to Manage the Focus on Value

The Human Resources organization at Principal is supported by a robust Business Architecture discipline with a well-defined capability map that also includes understanding around how each capability is performing, where there are gaps, and a scoring algorithm to help identify which capability gaps are most in need of attention for various reasons such as size of gap, risk associated with the gap, value to consumers, etc. This advanced view of HR from a Capability perspective makes it easy to identify a governing structure to align with coordinating and managing the work across all the HR departments and supporting IT platforms.

Bringing together departments that aligned around:

  • Talent: The People of the company (finding, hiring, training, developing, coaching).
  • Rewards: The Products of HR offered to the People of the company (compensation packages, benefits, pay and leave).
  • OneHR: The Services of HR that allowed the People to interact with HR (communications, data management, research, etc.).

In conclusion, implement an Agile HR pilot and inspect and adapt.

Finance

Companies can sometimes make the budgeting and forecasting process more difficult than it already is by accepting their laborious, tedious and often frustrating manual processes as status quo. Technology teams have spent decades evolving the way software is developed, and today largely apply principles of agile development methodology to quickly complete critical releases, and generally operate more efficiently. The success of agile approaches by IT teams has led other departments to borrow these methods to make their own teams more nimble. Finance teams, which commonly rely on cumbersome spreadsheet templates, email and intranet-based processes – not to mention long delivery cycles – can perhaps benefit the most from applying agile approaches to planning technology investments.

Companies that have agile Technology budgeting and forecasting processes will have the competitive edge when it comes to quickly responding to changing business needs and market dynamics. Achieving new levels of agility requires new ways of thinking about Technology budgeting and forecasting and new approaches to these critical processes. So consider taking a moment to evaluate how you can apply some of these concepts to become more efficient and productive. (Review Agile VS & Budget, and Agile Contracts form the A2F Framework for more details on Agile budgeting).

Capitalization

Per accounting regulations, project expenses are divided into two taxable categories: operating expense, and capital expense. Operating expenses are those ongoing costs related to running the business, such as administrative personnel, rent, supplies and maintenance, training, sales and marketing. Capital expense are those expenses related to investment in expanding the business somehow, and in a research and development-type business enterprise, projects incur both types of expenses.

Capitalization is allowable at the point at which the project becomes technically feasible, management has provided written approval to fund development and committed necessary resources, and expressed confidence that the product will be successfully produced and delivered. While this clears dividing line is compatible with a waterfall, or sequenced type development which demonstrates a clear shift in project focus (usually a key approval) that satisfies the criteria for capitalization.

Agile program portfolios can base their capitalization on value streams and agile program portfolios; program authorities select projects for capitalization from a Kanban backlog and set them in motion. From there on out, the effort to produce a feature or product must be accounted for, in order to be identified for potential capitalization.

There are three basic ways to capture and account for the work related to feature development: recording actual time spent, by using story point estimates for each task or contributing line of work, and by using story count estimates for each completed program portfolio timebox.

Using actual time spent is a good way to be precise when calculating capital expenses, but it also reduces the speed of delivery and such precision is not usually necessary. Using actual time spent might be a good way to establish baselines upon which to create estimates for future use however, in order to estimate the "story point" value for each effort. Story points are increments of work that define value in a relative way, enabling one to calculate capitalized efforts as a percentage of overall, without bogging down into the details of actual times spent. However, in some Agile program portfolios, there may be literally hundreds of tasks or lines of work meaning that it is a great deal of work to capture even a moderate level of detail for capitalization treatment. At this scale, it may be as effective to simply count the number of capitalization-eligible tasks, lines of work, or "stories" required to complete the project in order to make a calculation of the percentage of efforts eligible for capitalization treatment. This approach is subject to occasional audit to ensure sufficient accuracy, but does allow the team to focus their efforts on tasks that deliver value.

Generally, capitalization is indicated for those expenses (including labor and subcontractor expenses) related to the implementation of a specific product (or improvement of an existing product). This includes designers, developers, subject matter experts, testers and other team members involved in refining and implementing projects. Other team members, such as Product Owners and Scrum Masters, are also directly involved in implementation and value delivery, possibly making some of their efforts appropriate for capitalization as well.

Marketing

At its core, Agile marketing is a tactical marketing approach in which teams identify and focus their collective efforts on high value products and services, complete those products and services cooperatively, measure their impact, and then continuously and incrementally improve the results over time.

The Learn-Build-Measure-Learn Cycle

To re-state the objective of Lean development, it is a kind of race to produce a minimally viable product and show returns before we run out of resources. It's a cycle of building, measuring the response, learning from the measurements, and changing what we build based on the new knowledge in order to try again. Here are some basic principles for ensuring that your cycle churns along in an efficient way:

Be Scientific.

Experimentation and questioning our customer leads to building a product that people want to buy. Learning about our customers is important. Doing the right thing at the right time, asking the relevant questions, scaling on-time instead of ahead of time… are all necessary to make sure that the effort and resources you expend are used efficiently and wisely. Focused effort is important.

The goals of the Lean process and the scientific method are the same: to discover cause and effect relationships by formulating a falsifiable hypothesis (a question that can be proven or disproven), carefully gathering and examining the evidence, and seeing if all the available information verifies our hypothesis.

In order to use the scientific method in the development process, we generate our hypothesis ahead of time. Then in order to answer the question, we will identify what is useful to measure the response to our question (the metric), in order to create tests that will generate evidence for us to examine.

If you're building something new, your challenge is to build the simplest thing you possibly can to test your theories; when you understand what the biggest risks are, you may not even have to create a product to test your theories. For example, if the biggest risk in your plan is the customer channel, you can build something else to test market penetration. The rise of crowdfunding should be proof that it is not necessary to have a product before making an impact.

For example, if we'd like to answer the question about which customer channels are most effective, we'd start with a hypothesis to test: "Publishing a guest editorial in Business Journal will generate 1000 unique visitors and 100 signups in two months." Then, we can identify that we want to measure how many click-through to the website come from Business Journal, and how many of those potential customers eventually sign up.

The best hypotheses follow the SMART goals outline: Specific, Measurable, Achievable, Relevant, and Time-bound. Even if you don't reach your goal, the mere process of defining the goal helps you to test your expectations against reality and helps refine the approach to future goals.

To ensure that the scientific method gathers accurate data, we need to ensure that an experiment runs the same way every time. Limit the number of changes you test at one time; it's hard to link cause and effect when there are multiple potential causes. The scientific method is useful with qualitative data as well as quantitative data; in order to ensure uniform quality, use an interview script and ask questions in the same way.

Qualitative vs. Quantitative Evidence

Both qualitative and quantitative evidence have their place in Lean development. The secret is to use them at the appropriate time. In the initial stages of development, before product/market fit is achieved, there is a lot you don't know. The good news is that you don't have to gather a lot of information in order to do a significant amount of learning.

"If you have a lot of uncertainty now, you don't need much data to reduce uncertainty significantly. When you have a lot of certainty already, then you need a lot of data to reduce uncertainty significantly"

- Douglas Hubbard

Developing your qualitative knowledge through customer interviews, sometimes as few as five customers, is a way to confirm or deny whether your hypothesis is on the right track. A strongly negative indication from your customers will tell you that you are on the wrong track, whereas a positive indication will signal you to move forward with quantitative testing.

 

Communicate Your Learning

Use an Accessible Dashboard

Testing our hypotheses can result in being proven wrong, which can be scary. A dashboard forces accountability to the objectivity of our work. It asks you to answer for the results of your hard work, and to format the outcomes of your experiments in a way that you can share with others regularly, at occasions ranging from the weekly team meeting to the monthly investor meeting.

The dashboard starts by naming a single goal, and then summarizes your process of learning: describing the hypothesis, what the results of the test actually were (outcomes and insights), and what you're going to do next (future experiments).

The learning is prioritized by using a lifecycle view of your customer process, and by staying grounded in the business model assumptions.

By sharing your dashboard widely, your collaborators can help you move quickly toward a plan that works. Keep in mind that although you will be able to work through risks quickly, you will still need to tackle several levels of qualitative learning. Some teams get discouraged when their initial hypotheses are not validated immediately, or conversely they fall into Innovator's Bias when their initial learning yields a positive response.

Anticipate that each window of your canvas may need a couple of adjustments before yielding positive responses, and that it will take several stages to systematically test each box of your canvas:

First, uncover the problem worth solving. Test the problem you have identified, whether you have identified the right customer, and how the problem is solved today.

Based on what you've learned, attempt to define your solution. Create a demonstration to help your customer visualize your solution, and test it to find out if it will work, who will be your early adopters, and whether customers accept your pricing model.

When your demonstration generates enthusiasm, you can build the minimally viable product and soft-launch it to early adopting customers. The test is to see whether they connect with the unique value proposition you've offered, as well as test how you will find enough early adopters to support learning. At this point, a big source of validation will be whether customers are paying.

You can then launch your product to a larger audience and test quantitatively whether you have created something that people want, as well as whether you can reach customers at scale in order to have a viable business.

What about your Unfair Advantage? This isn't addressed in the testing because it can't be tested absent competition, which you likely won't attract until you've achieved product/market fit much later.

Start Learning

The process of eliminating risk requires talking with customers directly, and often. Although it might seem more efficient to run a focus group or send out surveys, the interview process allows for more learning about the unknown-unknowns.

In general, the survey is a constraint to this learning process. Although the interview process starts with a script, clarifying questions are sometimes necessary and they are impossible to ask in a survey. An interviewer can learn which questions aren't being asked but should be asked.When offered answers, a customer has less opportunity to give a genuine or nuanced answer, and when the answer isn't offered, the generic "other" is the correct answer but it is not precise.

Focus groups are also problematic for the learning process because they also deprive customers of the opportunity to give nuanced or genuine answers; instead, the focus group often devolves into groupthink.

This is not to say that surveys aren't useful at all: surveys are very useful, however they are more appropriate for quantitative validation and demonstrating scalability of the qualitative findings.

Talking to People is Hard

Yes, talking to people can be hard, but it is essential. With that said, there are a couple of considerations that might help make it easier:

The point is not to sell anything. Not now, at least. The point at this stage is learning, which means you don't even have to talk that much because people love to talk about themselves, their preferences, their challenges and their successes. When there's a sales pitch involved, the sales pitch occupies most of the time, and people may tune out or say whatever they think will end the interaction faster.

Actions speak more truth than words. The interview conversation is not the only way to gather effective data. Often, people will give false information verbally either because they aren't really self-aware and don't know the answer, or because they want to be polite. Because of this, the interview isn't the end of a successful conversation: find a way to validate the verbal information you receive with direct observation of the customer's processes.

Preparation makes it easier. The successful interview process will have specific learning goals (the hypotheses being tested) and therefore the interview process needs structure: a script. The script doesn't mean there isn't room for learning about the unknown unknowns, but it will ensure a repeatable and scientific process for gathering data to test your hypotheses.

Other preparations that will improve the process include: choosing a neutral space and scheduling enough time for the interview. A neutral space removes any pressure to buy what you're selling and scheduling plenty of time upfront means that you will have time to gather all the relevant information without pressure or being disrespectful of your customers' time.

A buddy makes it better. The interview process works better with someone else in the room to help. The other person's job is to make sure nothing is missed, and also to keep the observations objective. Having another person present means a recording device is unnecessary – this kind of tool may have the unintended effect of making people self-conscious, resulting in less accurate data being gathered. Together you can document the interview results immediately afterward, filling in each other's gaps.

People want to help. In-person interviews generate goodwill and trust, and people love to talk about themselves. Start with people you already know who fit the (assumed) target customer profile, and ask them for referrals: warm leads are easier to talk to. The referrals don't necessarily have to fit the early adopter customer profile, because that profile is just a hypothesis until you meet with people and validate that assumption. A monetary incentive is unnecessary and sets up future expectations – you want to find customers who pay you, not the other way around.

Prepare to have interviewed around 30 to 60 people by the end of the iteration cycle. The interview process is done when interviews no longer yield new insights, or when you can predict what a customer is going to say by asking just a few questions.

How do I find enough customers to interview?

There are a few effective ways to go about this, but it will make your path forward easier if you choose a method that will eventually lead to a channel you can use for acquiring future customers.

First-Degree Contacts

As mentioned previously, first talk to first-degree contacts that fit your customer demographic. They may have some valuable insight, but be aware also that there may be inherent bias in their feedback. First-degree contacts may color their feedback with enthusiasm for your efforts because they are yours. However, your first-degree contacts are a great source of introductions to other people who meet your targeted demographic. Do your best to make it easy for your first-degree contacts to make introductions – give them something they can use to attract others who can help. An email template or business card may serve this purpose.

As you write your template or create your business card, give a thought to including your location. Sometimes the fact that you are based in the same community in which your customers live, is an incentive for customers to be more responsive and even purchase the product because they believe in "buying local."

As more customers are interviewed, more contacts can be generated simply by asking your interviewees to spread the message.

Teaser WebPage

If the internet is a possible channel for your product, you can feasibly set up a teaser website that can use a signup to generate new contacts. Although you don't know if your new contacts fit the profile of your targeted demographic, they were sufficiently motivated by the product's unique value to drop by and sign up. From these people you can even test whether your targeted demographic hypothesis was accurate. You can conduct interviews by phone, if you need to!

Cold Calling

Use social media, telephone calls, and emailing to solicit customer participation. This is the most expensive method, and not always the most effective, so it's last on the list.

Testing Your Problem, Market, and Customer Assumptions Before Development:

In order to develop a product that someone will pay for is to find a large enough customer base to support the product viability, understanding those customers and their problems (and how they currently solve those problems), and learning how you can access those customers efficiently.

The first set of interviews will test the problem hypotheses: whether your customers are who you think they are (customer segment), whether they have the problem you think they have (problem), and discovering the existing solutions.

The second set of interviews will define the solution: testing whether the early adopter customer segment has been identified accurately, whether the solution will work for them, and whether the pricing is agreeable.

To do so, turn your assumptions into falsifiable hypotheses (in the form of a question you can prove or disprove) and then, as Steve Blank said, "Get out of the building!"

Sometimes the customers are already coming to you, and that's also a great opportunity for learning. Lean Canvas inventor Ash Maurya connected a 1-800 number for customers to call in and chat for free, in order to consult with them about their problems, and eventually through this medium, came to understand his customers' problems in an intimate way, which eventually helped him to write a best-selling book that effectively scaled his consultancy.

Ask the Right Questions

When talking to customers, transparency and humility are essential. The customers that you reach are a valuable resource, and easily lost if they believe they are being tricked in order to make a sale or if you try to dictate to them what they should think, feel, or need.

With that in mind, the first round of interviews should take about 30 minutes to follow a basic structure:

  • Welcome – Setting the stage (including introductions to your interview partner), helping the customer understand why they're needed and what they'll be asked, and telling them about the basic structure of the interview. Underscore that the purpose of the interview is not to sell anything, but to learn.
  • Customer risk questions – These questions will collect the basic information assumed about your customers. In the first round, of interviews, these questions will be focused on learning who your customers are. Later rounds of customer hypothesis questions will hone in on which of the customers might be early adopters, and then the channels through which customers may be reached. Use questions that will prove or disprove your hypotheses about who the customer is.
  • Product risk questions – Tell the customer a story to illustrate the top problems that the product will attempt to solve, and in the first interview, ask the customer if any of those problems resonate specifically. If they do, ask the customer to rank the problems. Ask if there were any problems/pet peeves that the story did not highlight (the unknown-unknowns). This part of the interview is an open-ended exploration of the problems that the customer has indicated resonate with them.
    Questions may be necessary to clarify the answers, but honesty and humility demand that the interviewer does not lead the customer or try to convince them of anything. Here, the customer's body language, time spent in discussion, and tone will indicate how the problems rate: must-have, nice to have, or unnecessary. This part of the interview can yield clues about the Unique Value Proposition that customers are seeking. In later interviews, questions will identify the basic features necessary in order to launch a minimally viable product. Explore any new problems uncovered along the way, in the same manner.
  • Market risk questions – These questions discover how the customer currently solves their problems, what pricing the market will bear, and whether you will have enough customers to support your product. These questions help clarify how the product will be judged: for example, if the current alternative is free, then the product will need to provide enough value to stand out in the market and overcome this fact.
  • Prop open the door – At the end of each interview, although the details of the solution aren't ready yet, the concept is. You can use your high-concept pitch here to ask permission to follow up with the customer, to keep involving them in development (and eventually become a customer,) seek referrals, and ask for early commitment. Here's a general script for this part of the conversation:

    "As I mentioned at the beginning, our product isn't finished yet, but we are building a product that can ____. The best way to describe the concept might be "___ is like ____ but ___.
    Based on what we talked about today, would you be interested in seeing the product when it's ready? Also, we would like to interview other people like you. Could you introduce us to your friends who also ____?"

  • Document the results – Take a minute to record the results of this interview experiment to capture the important details while they're still fresh in mind. Use your script to create a template that the interview team can use to record the responses immediately afterward, and then use those forms to debrief the interview sessions later.

Debrief Weekly

When reviewing the results of customer interviews, do it in batches by week to summarize the key takeaways as well as to identify and make any necessary changes to the interview script. In order to maintain the ability to analyze results in a somewhat scientific fashion, make no changes to the interview during the week.

Make adjustments to the scripts during the weekly debrief process, based on the kinds of hypotheses being tested and the strength of response from interviewees. As the interviews proceed, each weekly batch should result in stronger and more consistent positive response.

Each stage of the interview process is complete when a) at least 10 interviews have been conducted, and b) when the customer's response can be predicted within just a couple of questions.

Yes, You really Do Need to Talk to Customers in Person

At this point, it may seem that there are ways to avoid the interview processes while still learning what you need to know, or that the interview process is useless because customers don't really know what they want… but the interview process truly is the most efficient and accurate way to understand the customer in order to build something they will pay for.

It's true that customers don't know what they want. However, it's not the point to discover what people think they want, but to understand the problems they have so you can develop a product that delivers on what people didn't know they wanted or needed – unique value.

But what if you are your own customer? Well, it does help to have an insider's view of a problem, however the product will eventually need to be sold to someone else in order to be viable for the business, so regardless of whether the problem seems compelling to you, the opinion of paying customers matters more than your own. You may think the problem is obvious, but who is to say that the problem you experience is at all universal?

Also, there are questions that are not relevant to the developer with the problem, such as pricing. (It may seem that pricing can be adjusted at the end of the process, because you can churn out a product quickly and then manipulate the price. However, if no one wants to buy what you've developed, at any price, it's more efficient to learn this sooner than when the product is ostensibly complete. It's pretty expensive to waste time developing something no one else wants.)

Although it may seem that a survey would be better suited to contacting a massive number of customers, it really isn't necessary to do so. If 10 out of 10 people are giving the same feedback about the product/ idea, or pricing, doesn't it seem like they make a compelling point?

There might be some worry that customers won't buy what is being sold, or that someone will steal the idea. However as stated before, the initial problem interviews are for learning about the customer and problem, not for selling the product or even presenting a product. In the first rounds of interviewing, the focus is on the customer, not the product.

These customer-focused interviews are helpful for all kinds of products or ideas – even if it seems the product is not designed to solve a problem, such as a video game or movie. Understanding the customer can still lead to understanding what they desire in a movie or video game, and to producing a product that the customer is willing to pay for.

There's no product to show the customer yet… and that's OK. A mock-up or other demonstration product is a very effective tool for measuring response, because it is focused solely on the learning objective. For example, a teaser landing page or Google ad can be effective for testing the attractiveness of the Unique Value Proposition because that is all it offers.

References

Katko, N. (2015, March 3). Lean Accounting and Generally Accepted Accounting Principles. Retrieved from BMA Inc. The Lean Accounting Leaders: http://blog.maskell.com/?p=1813

Pahuja, S. (2016, March 29). SAFe Framework Introduces CapEx and OpEx Elements of Software Capitalization. Retrieved from InfoQ: https://www.infoq.com/news/2016/03/SAFe-CaPex-OpEx

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.
Author: Eric Ries. Published April 2011. Publisher: Crown Publishing Group (USA).