AGILE INNOVATION IN ACTION: DELOITTE

Introduction
For a company such as Deloitte Central Europe (hereafter referred to as Deloitte), stating that employees
are the most valuable assets is not just a cliché. Deloitte creates value for its clients by delivering profes-
sional services in the areas of audit, consulting, financial advisory, legal, and tax based on the skills and
knowledge of its employees. Recently, Deloitte has broadened its scope of services, which means that its
appetite for talent is even bigger than before. No wonder that recruiting at Deloitte is a strategic process
in its value creation chain.
Nevertheless, the legacy recruiting system that Deloitte has been using for years became seriously
outdated, as it did not keep up with standards that we are used to in the new digital world. In order to
apply, candidates had to go through 11 screens and 18 data fields entailing 30 mouse clicks. And, as if that
were not bad enough, the candidate could encounter several critical errors, which would make it impos-
sible to successfully complete the application process.
Being so far behind the pace set by the digital leaders, Deloitte was experiencing the loss of nearly
half of the candidates who began the application process. Qualitative research showed that many of those
who dropped out of the process were in fact exactly the type of talent that was needed for the new suite of
digital services Deloitte was beginning to offer. Faced with such a difficult application process and know-
ing that there were dozens of other companies, which in many instances were the primary choice for such
employees, many candidates abandoned their applications or declined to apply to Deloitte. Therefore, a
substantial part of the company’s employer branding effort was wasted due to poor candidate experience
in the application process. That was a serious impediment for implementing the organization’s strategy of
attracting and retaining top talent. In addition, from the recruiter’s point of view the legacy system did not
meet basic expectations such as the ability to easily search for candidates and quickly screen their profiles.
Having realized the inability to deliver its strategy using the legacy recruiting solution, Deloitte lead-
ers decided to build a new, custom-made solution. On the one hand, it was a risky decision in that there
were quite a lot of off-the-shelf solutions that could improve the situation. On the other hand, within the
organization there was a group of individuals passionate to build an innovative application, tailored to
meet the needs of candidates and recruiters alike. Fortunately, leadership trusted the team and decided to
run an experiment by building the system from scratch, created in close collaboration with candidates and
recruiters, in a cloud environment, using agile practices. The project, which received the acronym “CEX,”
which stood for Candidate Experience Platform, was born.

Body
Project Manager Duties
Why should the project sponsor invest in such a role as the project manager for the “CEX” project? On
the one hand, there was a feeling that building a new digital product in an agile approach, based on the
values and principles of agile rather than on the traditional command and control elements of a waterfall
approach, would create an environment for creative thinking and unobstructed working.
On the other hand, since it was one of first agile projects delivered in the organization, it was met
with some expectations, fears, and worries. Most notably, the sponsors wanted a single point of contact
for the project, one person responsible for managing progress and the budget, provide coaching, and
cultivating an open environment for sharing ideas. It didn’t matter if this person was called the “agile
coach” or “project manager,” the expectations were that someone was responsible for planning, delegat-
ing, monitoring, and controlling the project. So how was the traditional role of “project manager” applied
across these areas to such an innovative initiative as CEX?

Plan
The project was envisioned and delivered in four subsequent phases: discover, define, develop, and
deploy, following the “double diamond,” a creative process created by the Design Council, a nonprofit
organization promoting the concept of inclusive design, depicted in Figure 2-4.
In the “discover” and “define” phases, there was no agile coach or project manager role present.
These phases were not conducted according to the traditional project delivery methodology, but rather in
the so-called “magic time,” meaning somewhere in between all other tasks. In these first two phases, there
was just a single “management” role—the product owner, who was responsible for gathering insights
as well as understanding the problems and needs of candidates and recruiters. The understanding of the
underlying problems to be solved provided the foundation to develop the interactive prototype and subse-
quently define the initial product backlog of the future recruiting solution.
The third phase of “develop” required significant capital investment, and as such, the sponsors
asked for the project manager (PM) or agile coach (AC) role. The first task for the appointed PM/
AC and PO working in tandem was to prepare the statement of work and the pitch presentation to the

Learn Build

Human-centric Agile
service design

Measure

Discover Define Develop (MVP) Deploy

Decision point (department level) Board pitching (country level) ExCo pitching (regional level)
Business Business
Case Case

Time One month One month Three months Six months

Product owner, visionary + 6 developers, UI, –2 developers and - UI

+1 front-end developer
Team UX, researcher, recruiters agile coach/PM

Fuel 1x 6x 30 x 50 x
Part-time job Full-time job

Figure 2–4. Our Road to Innovative Problem Solving.

management board, which included project approach, timeline, scope, budget, and team structure. This
required proper traditional planning. An iterative approach for the delivery of the new recruitment
platform was selected as the preferred project management approach. This decision was made by one
of the sponsors (let’s call him the visionary) based on his intuition rather than experience. PM/AC/PO
together with the visionary explained to other stakeholders, that using the iterative approach would
minimize risk and waste.
Regarding the timeline, from the beginning of the project it was clear that there was no hard deadline
for launching the new recruitment platform. “Hard deadline” was understood to mean a date resulting
from business, technical, or compliance r­ easons. Nevertheless, a deadline was set, the date when the team
will run out of money (budget). Other points on the timeline were more indicative and were presented in
order to depict the team’s ideas for subsequent stages of the project delivery, from demos, to UATs, RITE
tests, friends and family testing, and security testing, to potential release dates. These points of time were
not treated as milestones, as they did not define the critical path (this expression was never used during
the project), and moreover, the changing of initially defined dates did not require acceptance from the
sponsors. These activities were not regarded as “project deliverables.” The only agreed deliverable was
the business value to be delivered, meaning an improved candidate experience, enhanced recruiter experi-
ence, and reduced time needed to process candidates through the recruiting cycle.
The scope was defined in a few iterative steps starting with an interactive prototype created during
the “define” phase of the project. The prototype was discussed with almost all business users (around 20
individuals) during a full-day workshop. The prototype covered key user interactions and flows across
the entire recruitment journey. That was a very helpful tool for the product owner and UX designer—the
facilitators of the workshop tasked to engage future users in the co-creation process. For the candidates,
recruiters, and the business, it was also much easier to point out key recruiting activities that should be
enabled and simplified based on the prototype. In the second step, based on the workshop outcomes, the
product owner, with support from PM/AC, wrote the product backlog with MoSCoW (must have, should
have, could have, and won’t have) priorities, along with the DEEP technique. Next, during a two-day
workshop the development team estimated in man-days the required work effort, which was taken as the
baseline for the project budget to be agreed with the sponsors. So far, the role of the PM/AC was focused
more on facilitation of meetings and elimination of impediments, so he acted more like the agile coach.
Regarding the team structure, sponsors expected to see who would be responsible for specific project
areas such as business requirements, architecture, and quality assurance, and so the DSDM (dynamic sys-
tems development method) team structure was used to define such roles as business visionaries, business
ambassadors, technical coordinators, solution developers, and so on. In subsequent stage of the project,
the team worked much closer to a traditional Scrum framework with three key roles: product owner,
development team, and agile coach.

Monitor and Control

Costs
Since the key project constraint was the budget, not the timeline, the PM/AC did not focus much on track-
ing on how well the work was progressing against the project schedule. The most important item that
was tracked was the ratio between investment (tracked at the sprint level) and business outcome (verified
after production releases). In order to manage the investment and keep track of project costs, two key cost
management measures were introduced. First, all project purchases, such as SaaS licenses for Heroku
(development platform), Lucidchart or Atlassian (project support tools), were made directly by the PM/
AC. This ensured that opex costs were under control and could be easily tracked. As the PM/AC was
working very closely with the team (same location, almost every day), he did not constitute a bottleneck
in this case. Second, everyone on the team reported work time in JIRA (project support tool) on user story
level, even time spent on Scrum ceremonies. It was agreed with the team in the definition of “done” that
a user story could be treated as done, among other criteria, only once all hours have been reported. This
allowed the PM/AC to control the budget and present biweekly updates of budget consumption to the
team and sponsors. This act of transparency turned out to be very useful in discussions about changes to
product backlog and priorities.

Deadlines
As already stated, the only hard deadline the development team faced was the date the budget would be
exhausted. The role of the project manager was to closely monitor the budget in order to know when to
start user acceptance tests (UATs), which were not conducted as part of each sprint due to recruiters’ time
limitations. Every two weeks the project manager presented to the team, sponsors, and other stakeholders
the expected kickoff date of UATs, as well as the target end date of the project based on past budget con-
sumption and planned team capacity, which varied because of vacations, public holidays and sometimes
other duties assumed by project team members. Such an approach allowed the team to appropriately plan
their sprints, and the product owner to effectively manage priorities.
One additional deadline that was important to the project team was the end of each sprint. Every
two weeks the team had to present to the product owner (and sometimes also to other stakeholders) the
product increment. This allowed the team members to keep their focus on the goal of each sprint. It was
also a useful mechanism that enabled the team and the project manager to monitor the progress made and
check whether the project was going in the right direction, taking into consideration the scope that had
been agreed on with the sponsors and stakeholders.

Scope
Before the official start of the project and just after the prototyping phase, there was a need to create an
initial list of features of the product. The idea was to conduct a whole-day workshop with business users
(around 20 individuals) in order to create a list of features that would be included. Therefore, the team
decided to print all screens of the prototype in the form of mockups and hang them on the walls of the
conference room. The task of invited guests from the business side was to mark various functionalities
with self-adhesive colored cards, where the color reflected the perceived importance. Initial prioritiza-
tion of backlog items was possible with the use of MoSCoW priorities (must, should, could, won’t), as
per the DSDM methodology. The joint workshop provided a great opportunity to gather feedback from
the actual users of the future system as well as a chance to engage them in the co-creation of future
functionalities.
It is worth highlighting that business users initially believed that all the proposed functionalities were
equally important for the functioning of the application and all features should or even must be included
in the final version of the product. Such thinking is typical of the traditional waterfall model, where the
requirements are collected at the beginning of the project and making subsequent changes to the pre-
liminary scope is difficult. Because of these habits and experiences, the selection of key functionalities
turned out to be at first very difficult. The solution was to limit the number of “must” and “should” cards,
which brought up a dialogue between business users and project team members. It was crucial that busi-
ness users understood the basic limitation, which was the budget. The main challenge for the product
owner during the workshop was to guide business decisions and raise awareness that they were creating
a product for the end users (in this case, candidates that were being recruited to Deloitte) and therefore
should be guided by their expectations and not by what seemed to be important business users and team
members at the time.
This was also the reason why the team decided to show the MVP (minimal viable product) during
the software development process to end users (i.e., students at Warsaw universities), who agreed to take
part in RITE (rapid iterative testing and evaluation) tests. At the beginning of the week, UX designers
conducted tests with users in a room behind a Venetian mirror. Provided feedback was incorporated into
the application during the week and the next round of RITE tests took place on Friday. The increase in
end-user satisfaction in the second round was truly outstanding.
The product owner’s focus on scope management played a key role in the subsequent iterations of
the project. The person acting in this role is always under pressure from two sides—the business and
the team. We can describe this phenomenon as product-oriented dual personality. The product owner
always required from the team that they deliver valuable increments of working software while at the
same time he was responsible for identifying unfeasible requirements presented by the business side.
For that reason, the product owner had to know the limitations and capacity of the team in order to be
able to effectively negotiate the scope of a sprint with the sponsors, to make sure that it was both feasible
and valuable.
At the end of the project, the development team had yet to integrate the application with LinkedIn,
integrate the back office with the provider of preliminary test results (SHL) for the organization, create
report panel for recruiters with statistics of the ongoing job applications, and adapt the application to
mobile devices through full responsive web design (RWD). The budget would only allow for the delivery
of two of the four functionalities that were originally categorized as “should have.” The product owner
facilitated a business meeting during which it was decided that the key functionalities required of the final
product were a reporting module and access from mobile devices. The remaining “should haves” had to
be de-scoped.
The last verification of the product’s scope of functionalities before deployment was the launch of
friends and family tests, during which the final feedback on what else should be included in the scope of
the solution was collected from a group of over 80 candidates and 10 recruiters. A benefit of running tests
for many users at the same time was the discovery of new bugs on the production environment before the
final release.

Quality
At every stage of product development, the product owner felt fully responsible for the produced software
and the value delivered to future users. Appropriate empowerment within the organization, responsibility
for management of the entrusted product budget, an entrepreneurial and innovative personality, as well
as the ability to pay special attention to detail, made the product owner identify with the product very
closely. She made her best effort to present the expected product before the organization, so she never
compromised on quality. During sprint reviews, the product owner always made sure that the user story
complied with the definition of done and the acceptance criteria. Moreover, the product owner challenged
the development team on a daily basis to make any given functionality easier, faster, and better. A few
weeks after the project startup, the members of the development team started to identify themselves
with the brand of the product and ambitiously wanted to create an innovative product at the highest level
of quality.
Risks
Agile delivery philosophy (of which the most popular method—Scrum—was chosen for this project),
allowed the project manager to identify and help the team mitigate risks very quickly. Each day, at the
daily Scrum event, all developers discussed whether anything was preventing them from completing the
tasks to complete a sprint. The project manager’s task was to help remove the impediments identified
by the team members. Additionally, during the sprint review, by presenting the product increment and
using the definition of done, the team could verify with the product owner how much closer they were
to delivery of the agreed scope. Each review ended with an update to the burndown chart, which made
demonstrating progress transparent to the team and stakeholders. If the team’s velocity was lower than
expected, it was the project manager’s duty to explain the situation to the sponsors and the stakehold-
ers, as well as help the product owner collaborate with them to reprioritize the backlog. Furthermore,
the use of another Scrum event, the sprint retrospective—which focused on inspecting and adapting
the delivery process—allowed the project manager to discuss with the team how to avoid and manage
certain risks.
Iterative delivery was itself a great risk mitigation solution. For example, since developers working
in an iterative way merge code more often, this allows for discovery of inconsistencies much earlier. Each
sprint included rigorous testing, which again contributed to lower implementation risk at the time of
release. The project manager’s duty in this case was to make sure that each developer committed code at
least once a day and the functionalities were developed accordingly to the agreed criteria of the definition
of done, including automated testing code coverage.
All risks not associated with developing the system, such as legal or compliance issues, were reported
to the sponsors every two weeks during the status meeting. Where matters needed the immediate attention
of sponsors or other stakeholders, a quick escalation path was designed for the project manager to bypass
the biweekly meeting and organize another call to make the proper decisions as soon as possible.

Benefits
The product owner’s role is to build a product that provides a specific business value. However, in the
case of the recruitment platform, it was extremely difficult to calculate and depict measurable business
benefits that flow directly from the implementation of such a solution. From the organization’s point of
view, the entire project was treated as an investment that had to pay back.
To create a point of reference, the team measured the conversion rate of the previous recruitment
application. It turned out that of users who visited the recruiting website and started the application
process the number who actually completed and submitted it was significantly low. That meant that a
lot of effort and money invested into employer branding was being wasted. The overwhelming number
of screens and irrelevant questions annoyed applicants and as a result they abandoned the application
process. Even those who completed the process were annoyed by the amount of time required to sub-
mit the application, which in turn negatively influenced their perception of the entire company. There-
fore, the business case for the project was based on the simple assumption that we should significantly
increase the conversion rate and make the application process for the candidates as easy and convenient
as possible.
The product owner must have a good understanding of the value the product brings to the organi-
zation; he must prove it, set a clear and measurable target, and regularly show how the value increases
over time.
Agile Coach Duties (Scrum Methodology)
Expect High Performance
What is not clearly defined in PRINCE25 (but was very important on the CEX project) is focus on the
team’s performance. It clearly resulted from making the project budget central not only in discussions
with sponsors, but also during reviews, plannings, and refinements. As the daily cost of the project team
was quite significant, there was pressure to make sure the team had the right working conditions and that
it was not distracted by external factors. The team was also aware of the importance of improving its
productivity. From the value stream map perspective, there was very little space for any kind of waste, so
in accordance with the principles of Lean management, the team eliminated these potential time-wasters:

● Partially done work. Everyday code commitments, team reviews of documents.

● Extra processes. The team was self-organizing; project processes were set up by the team not
imposed by external parties so extra processes were avoided.
● Extra features. No budget for extra features so this was avoided.
● Task switching. Individuals dedicated to one project, cross-functional team.
● Waiting. Multidisciplinary team members were limiting queues.
● Motion. No need for handoffs, all tools and skills present in the team.
● Defects. Defects were limited due to definition of done and acceptance criteria.

Another method for improving the efficiency was the adoption of development approach and archi-
tecture based on the DevOps concept. The team was responsible and empowered not only for developing,
but also for maintaining of the new recruitment platform.

Inspiration for the Team

The uttermost inspiration for the development team was the awareness that their work can change the
reality around them. The first time the product owner read the opinions of students who had the oppor-
tunity to try out a new recruitment platform, he was extremely happy, because nobody expected such
positive feedback.
The entire team was also in close contact with recruiters, who used the platform every single day. As
it turned out, the new solution significantly improved the comfort and efficiency of their work. Browsing
through the applications of potential candidates had become a pleasant, easy and intuitive task. Further-
more, the product improved the ease of applying to Deloitte for about 20,000 candidates who send appli-
cations to our organization every year.
Observing the real impact of the product on the life and behavior of users was a very rewarding expe-
rience. Over the course of time, the team not only drew inspiration from feedback, but also set itself the
challenge of better and better insights.

Protecting the Team

One of the most important decisions made was to locate the entire team in a place separated from the
headquarters building, which limited random involvements in different projects. However, it was not

5. PRINCE2 (Projects in Controlled Environments) is a structured project management methodology, a process-based method for
effective project management.
enough to guarantee that team members would be fully dedicated to project work. Very often, line man-
agers tried to engage developers in different projects as SMEs or event part-time developers. It was the
role of PM/AC to inform line managers about the consequences of disrupting the team and sometimes
to escalate those issues to sponsors. The PM/AC was not popular among line managers, as the main key
performance indicator (KPI) of the PM/AC was team efficiency in the long term while line managers’
KPI was new sales.

Summary and Takeaways

The initial conversion of users completing the application process increased from 60 percent (average
between June 2016 and October 2016) to almost 100 percent in the period after application release. In
the first four months the platform collected 14,574 applications for advertised jobs and 11,787 candidate
CVs. On average, 30 percent of candidates viewed job offers via mobile devices, so the decision taken in
the last sprints to make the product compatible with mobile devices was crucial for the achievement of
the eventual outcome.
At the beginning of the project, the established Scrum team did not have enough knowledge about
the expectations of end users. Working in short iterations and regularly collecting feedback from both
sponsors and the market made it possible to develop custom-made solution that met the expectations of
all stakeholders. The experience has shown that in the case of innovative projects with a high probability
of changes in scope, an agile approach works perfectly. Although it might seem that Scrum in a large
corporation does not make sense, that it will not succeed, and that the whole project is doomed to failure
due to numerous procedures, rules, and excessive documentation, we managed to prove that nothing is
impossible. Adequate management support and the necessary trust in the team has enabled us to deliver
in five months a very mature product, which is currently in use by recruiters in 16 countries across central
Europe. The development costs have been fully paid back and the platform will continue to serve the
organization for many years to come.