As we have been taking our organization through an Agile Transformation as a part of an overall Digital Transformation, we have been leading extensive training across our business lines and technology teams. One of the most common questions as we discuss Scrum, is around job titles and role. In scrum, there are only a few key roles, and job titles do not apply! There is a good article on the Atlassian site, linked here, that I encourage you to read through. Ihit the highlights here, but they offer a deeper read.

“the essence of Scrum is empiricism, self-organization, and continuous improvement, the three roles give a minimum definition of responsibilities and accountability to allow teams to effectively deliver work.”

The idea of scrum is to keep things simple, contained to a self organized team, and optimized for continuous delivery. To accomplish this, there are 3 defined roles and it is from the intersection of these roles and classic titles or thinking that I see many questions.

Development team

The development team does not have to consist of software developers. According to the Scrum Guide, the development team can be comprised of all kinds of people including designers, writers, programmers, etc.  Titles here have been a source of confusion as involved leaders ask why a business analyst or business user is called a developer – I hear arguments that “I’m not an IT person” or “I don’t write code, why am I a developer?”. The key point for the developers role is that the person is a team member, focused on delivery of value in one or more capacities.

Ideally in a long running scrum team, the members will cross train sufficiently to blur the lines in roles, even in the development team! Unfortunately, in my industry and area, most teams come together for a project, and then disband leading to a higher than ideal rate of churn on this topic.

CSM / Scrum Master:

The scrum master is the “glue of the team” and the challenges in role vs title I see most often are those that come from the traditional PM thinking. I get the question – so who is the PM on this agile project? Or I get the CSM trying to hand out tasks against a project schedule instead of the collaborative scrum approach. This curve is an interesting one to watch, especially in the long time PMI / PMP trained professionals!

Product Owner

“The product owner should not only understand the customer, but also have a vision for the value the scrum team is delivering to the customer. The product owner also balances the needs of other stakeholders in the organization.”

I see business owners who initially struggle with the idea of the product owner role. They are used to the paradigm of meeting with a business analyst, providing requirements and waiting for something do be delivered that they then need to spend more money on since it does not match what was in their head or did not keep pace with the changing business needs.

The product owner role is a far more hands on role, and has expanded responsibility. The key step to success in communication and managing this role is establishing real clarity on the value of the high engagement. The regular feedback cycles, direct ownership and participation in sprint reviews means change is always an option, and surprises are minimal. This means less re-work but to get there, a product owner must understand that they are not the “hands off sponsor” or business lead that gets a “white glove” engagement. The product owner role is a bit of a dirty, hands on, learning in role to get the most value. This is a real paradigm shift for many, but pays off in amazing ways.

There are more articles, papers and consultants than I can count on the topic of transformation in business. Many of them focus on the idea of transformation, and now especially “digital transformation” as a means of survival. I suggest an alternative, but complimentary idea. Don’t think of transformation as a survival exercise. Use transformation as a vehicle to truly be transformational, not in the buzzword sense, but rather in the overall value chain perspective.

To transform to survive is relatively straightforward. Look at where your peers are going, and queue up alongside them at the industry feeding trough. You will have a shot at staying relevant for a period, but your investment will likely be drowned out by the noise of the accompanying industry shifts, and be no longer lasting than the last series of “revolutionary ideas” the organization has moved through in the past. Transformative change comes from taking a hard look at your own house, industry, supply chain, and customers.

• What are the trends in your industry pointing to?
• What is your risk tolerance? (organizational, industry, regulatory …)
• What are the trends across adjacent spaces that move more nimbly than your own?
  • How can you choose to leapfrog your competition and industry by making bold investments, while mitigating some level of risk by learning from adjacent spaces?
• Is your broader organization ready to accept your changes?

Trends in your industry

The trends in your industry point to where your peers are headed. This is good information directionally, but also a map to “what is” as opposed to “what could be”. Use this as a means to cross check your ideas – are they closely aligned? If the answer is yes, you are likely transforming to survive.

How can you take a leadership position in your industry, partnering with your consumers / customers and your respective regulatory bodies to bring the consumer ever closer to the value? For heavily regulated industries, how can you ensure regulations evolve along with your technological investments? Be a trendsetter through partnerships with the regulatory agencies. Gain the competitive advantages from being positioned to take advantage of emerging legislations and changes.

The idea of adapting to win comes from being bold, and as a part of that, being a thought leader. This comes with risk, which leads to the next point.

What is your risk tolerance?

I learned many years ago to assess my risk tolerance for any given initiative, and to share that information with other senior leaders for confirmation and alignment. I have seen doors open that previously were firmly shut, once risk tolerance was understood and accepted. Conversely this also serves as a set of organizational guard rails to ensure that the proper foundation is set prior to embarking on your change event. Thinking through the risk, communicating the value of the risk and potential upside to the right stakeholders will set the change event up for maximum success. This is a topic all on its own, and something to give real thought to. Risk management should be thought of as a tool, and something to actively own as opposed to something to avoid if you are to grow.

Trends across adjacent spaces

Examining your own industry can be informative, but taking a hard look at industries that are much less regulated, or less constrained and closer to the forefront of technology and engagement is the key to starting to build your vision. To chart a course for transformation, a leader must have some idea of the future possibilities for the organization. A “North Star” must be defined, and a vision that can be clearly understood articulated. To do that, pointing to success sets up a believable path for your own industry and makes the unbelievable more realistic in the minds of your stakeholders. The adjacent spaces will likely have forward thinking that is not hindered by the regulatory or other structural burdens of your industry, and hence you as a leader are responsible to building the bridge of believability to get there, using your risk tolerance and vision as a foundation.

Is your broader organization ready to accept your changes?

The question of change readiness is a difficult one to face for many organizations, and is difficult enough at the project level, and even more so at the organizational change level. There is an element of “the org will do what I say”, to be sure, but real change will come from the people in the organization getting behind the mission, and both understanding and supporting the transformation activities. To gain this support, a non-trivial amount of up front work is required as well as continuous change management through the life of the actual transformation, and then well beyond the “done date”. The real value to be extracted from this significant investment comes in the “run state” of the new model. To get that, plan to invest in long running change management, voice of the customer and “micro tweaks” as well as highlighting the value in broad messaging.

Focus on the people, celebrate those team members who are bold and join the change as leaders, but do not forget those in the back who are supporting the leaders. People deliver on what is rewarded and celebrated. If as a leader, you celebrate “done” at the org alignment milestone and then resume business, you will miss the sustaining value of the change. Plan for a long tail on the investment. This is a real financial investment, but without it, plan to gain minimal transformative value.

Properly nurtured, the change event will result in a lasting difference in your organization and its ability to deliver meaningful value to your stakeholders. Remember to set a clear and compelling vision, and then measure yourself and your organization against that on on a regular basis. Celebrate success, support the change and be prepared to hold the course when things are difficult!

I was reading an article at CIO Dive about the CIO at cosmetics conglomerate Estée Lauder Companies Inc. and it resonated with a transformation we are undertaking in the pharmaceutical industry. The thing I love about these types of situations is the broad applicability of good thinking, but also the value of “stream jumping”, a term I picked up from an agency I worked with in a past role focused on innovation. The key idea of this stream jumping is taking lessons from adjacent spaces and applying them to your challenges, not being constrained to “my industry”.

In the article, the author Mitch Betts says: Michael Smith joined the New York-based “prestige beauty” company as senior vice president and chief information officer, information technology last year, with a mandate for pushing IT innovation to help the company stay abreast of the fast-moving beauty industry, where an Instagram photo of celebrity’s new lip gloss can drive sales.

While the drug industry is not reactive to that degree, our engagement is around delivering life saving medicines as quickly and effectively as possible. As a part of that journey, the patient connection is taking an ever more prominent role, whether it be in the trial compliance or reporting, medical routine compliance, or health monitoring, or any of a number of other scenarios.

Mr. Betts lists the year one accomplishments for the CIO and his team.

1. Reorganizing IT to align with business units, instead of technologies, so IT stays can stay close to business needs.
2. Hiring IT talent, globally, with new skill sets.
3. Fostering greater IT agility and speed, such as moving from waterfall to agile software development processes, and breaking down walls between applications and infrastructure groups to adopt DevOps.
4. Moving from a buy-and-integrate IT strategy to building systems in-house when they provide a competitive advantage

It is interesting to see the pendulum swing on these principles, as over time I have seen a few of these move in and out of favor.  What is particularly encouraging is the recognition of the value of Agile software development and DevOps. This helps de-risk some of the moves to build vs buy and business unit alignment of IT functions.

The classic waterfall model tends to drive a centralized service mindset, and long lead to value cycle times, which creates a host of challenges in meeting expectations, both customer facing and internal delivery team focused. When coupled with decentralized business alignment, it creates a continuous conflict for service time, and generally leads to infighting in my past experience. It is possible to make it work, but the effort expended is not commensurate with the value returned.

An agile approach, coupled with decentralized IT staffing can potentially yield optimum results, however there is opportunity to drive efficiencies into the model through replication of core services. The ideal match for this approach would be a scalable, SLA driven managed service provider approach to the commodity centralized services – “classic IT”, while devoting the employee headcount and leadership to the business facing roles and the intersection roles.

Every managed service has an inward facing employee accountable for performance. These leaders are measured by each business facing lead, as well as the internal metrics. This will help ensure a balance of efficiency vs. effectiveness in delivery of value, while taking the complexity of scaling and growth off the plate of the business facing teams.

The article does not go into any detail about the specifics of the alignment, but this is yet another in the trend I am seeing around the recognition of the value in taking an agile approach, and adopting agile development practices. This concept scales beyond the software development, to collaboration, organization and most other value streams.

This transformation for Estée Lauder, as well as the others in flight, will be interesting to watch over the next year. This is especially true as we are in the beginning stages of our own internal changes!

Link to the original article