Categories
Operational Modernization

Part II and III: Exploring Human-Centric Transformation

Podcast Companion Infographic

Bâton Global and Trility Consulting® teamed up to discuss how data and technology supports the transition towards a distributed workforce in a series of podcasts, particularly during and post- COVID-19.

The infographic below provides key actions shared in Part II and III, which focus on designing everything around the human experience and addressing the areas with friction in moving to a simple flow-based experience.

As teams work remotely and customer experiences shift even more quickly to on-demand, digital experiences. Key challenges include: casting a vision everyone understands, measuring performance and operational health, finding and using correct and complete data, developing a virtualization strategy, and ensuring personal safety and information security.

Listen to the Series

Part I

Join Kavi Chawla, Wade Britt, and Matthew D. Edwards as they discuss how this industry can address transformation aimed at simplifying and automating processes for team members, stakeholders, and ultimately customers by protecting their most valuable asset – people.

Part II

The second episode further uncovers the idea of flow, the necessity of performance metrics that measure throughput, qualitative experience, and humanistic value, as well as the subsequent implications on organizational culture and data management. 

Part III

The episode further considers the concept of managing data in a virtual world, ways that companies like Uber are guiding trends in customer experience, and the ensuing implications on the virtual workplace and data management. 

Part IV

In the final episode, you’ll hear how leading financial services organizations are meeting these challenges head-on and positioning their teams for success. Featuring Amy Hunold-Van Gundy, Head of Talent Management at Principal Financial Group and Brad Rasmussen, CIO at Merchants Bonding Company along with Kavi Chawla, Wade Britt, and our own Matthew Edwards.

Categories
Operational Modernization

Part I: Exploring Human-Centric Transformation

Podcast Companion Infographic

Bâton Global and Trility Consulting® teamed up to discuss how data and technology supports the transition towards a distributed workforce in a series of podcasts, particularly during and post- COVID-19.

This is the first of two companion infographics to the podcast series, which summarizes discussions of the strategies and tactic organizations can consider when responding to the industry headwinds and pressures – including those amplified or created by the pandemic.

Part I

Join Kavi Chawla, Wade Britt, and Matthew D. Edwards as they discuss how this industry can address transformation aimed at simplifying and automating processes for team members, stakeholders, and ultimately customers by protecting their most valuable asset – people.

Listen to the Series

Part II

The second episode further uncovers the idea of Flow, the necessity of performance metrics that measure throughput, qualitative experience, and humanistic value, as well as the subsequent implications on organizational culture and data management. 

Part III

The episode further considers the concept of managing data in a virtual world, ways that companies like Uber are guiding trends in customer experience, and the ensuing implications on the virtual workplace and data management. 

Part IV

In the final episode, you’ll hear how leading financial services organizations are meeting these challenges head-on and positioning their teams for success. Featuring Amy Hunold-Van Gundy, Head of Talent Management at Principal Financial Group and Brad Rasmussen, CIO at Merchants Bonding Company along with Kavi Chawla, Wade Britt, and our own Matthew Edwards.

Categories
Operational Modernization

A Basis for Automation, Part 2: Inclusive Continuous Delivery

This article was previously published on LinkedIn.

You are the Delivery Manager. There are 1,000 people in your organization. Twenty-five of them are on your project. Of the 25, six defined “done” for this deliverable. In your opinion, you delivered some of your best work. Twelve people, not on your project, come out of the woodwork telling you things are missing from the deliverable. You’re surprised. The project sponsor is mad. Your big boss wants answers. And the delivery team wonders why you’re letting people say harsh things about the deliverable and team without a fight. The deliverable cannot go to market until you get this figured out. What happened?

Many people suggest this is a problem with the Delivery Manager. Some suggest that stakeholder requirements were not identified and managed correctly. Others blame tools, processes, procedures; some notice internal kingdom-building, protectionism, and turf wars. A few even suggest the technologists who built the system are basement-dwelling anti-social figures of darkness who deliver what they want and don’t seem to know or care about business needs. While these conversations may be entertaining, in the end, finger-pointing conversations don’t solve the real problem.

  • How does it even happen that we miss stakeholders and requirements?
  • How do we ensure we’ve identified and included all pertinent stakeholders in project definition, verification, and validation?
  • How are we going to deliver all these additional requirements, definitions of done, and system attributes?

The answer is simple and accessible.

How Do We Miss Stakeholders and Requirements?

The problem starts inconspicuously at the beginning of the project when people are classified as one of two groups: requesters and builders.

Software Builders vs. Software Requesters
Figure 1. Projects are set up to differentiate “us” and “them.”

After that, requesters are decomposed further into three groups – now, later, never.

  • We’ll concentrate on these roles/users/user classes now,
  • We’ll consider those other roles/users/user classes later, and
  • We’re not going to consider these roles/users/user classes
Backlog Prioritization in Software Development
Figure 2. Groomed backlogs manage scope, priority, risk, time and cost

From above, the “deliver now” requests are then prioritized even further into:

  • We’ll do these things first,
  • We’ll do those other things immediately thereafter, and
  • We’ll do these other things later.

It seems deductively logical and very efficient.

Grooming a backlog is a learned skill. And when done well, it enables team focus and success, manages project risk and reward, as well as provides iteration upon iteration of value to the targeted stakeholders. A single, frequently curated, and prioritized backlog is a healthy core behavior of successful projects.

Over-zealous backlog grooming may also be why you’re missing expected functions, features, and attributes when projects are delivered. The project team thinks they are done, and yet things are missing.

Have you considered that teams are so efficient at curating the backlog that stakeholders and requirements are collateral damage?

How Do We Make Sure We’ve Included Everyone Necessary?

Create a cross-functional strike team responsible to securely operationalize the planned project deliverable – from inception to delivery. A project is not just documents and code. Projects operationalize ideas to serve clients, expand opportunities for growth, and generate revenue.

To securely operationalize requires a complete end-to-end cast of people from project sponsorship to design, develop, test, inspect, and secure to back-office operations including finance, procurement, sales management, and support services.

Cross-Functional Strike Team, (c) Trility, LLC
Figure 3. Cross-Functional Strike Teams are special-purpose teams designed to discover the superset of requirements ensuring common knowledge, purpose, priority, decision, investment, and commitment.

Then as a team, perform the following steps incrementally and iteratively through the course of the project – and support – efforts:

1. Identify the problem statement and desired outcomes.

2. Identify the work and definitions of done per work item. Focus upon roles, capabilities, and attributes.

3. Structure the work into independently digestible chunks with clear definitions of done. Note: Common today is the use of Epics, User Stories, and Acceptance Criteria.

To have the highest probability of delivering something useful to most, we need to know what they want by including more people, more roles. Conversely, to have the highest probability of dissatisfaction with the deliverable, exclude people and guess on their behalf.

You may be wondering, if there are going to be higher numbers of stakeholders and higher amounts of requirements, how are we going to get this done without lengthening the project, increasing the cost and adding to staff?

Enter the role of automation.

What Is Automated Continuous Delivery?

Developers are expected to do many things. Writing code is a means to an end, not the deliverable itself. To deliver more value, minimize context-switching, and increase flow, developers seek optimizations.

For some, optimizing means cutting things out and kicking them down the road. For many others, optimizing means automation.

What do I have to do?

What can I aggregate, separate or eliminate

What do I have to do manually?

What can I automate?

Continuous Integration, Continuous Delivery
Figure 4. An example of a continuous flow experience for a developer.

A fantastic result of developers who seek efficiencies through automation is that those same efficiencies can be used all along the delivery pipeline and out into general availability/production.

For some great examples of how developers seek to simplify through automation, look to Will Rubel, and his four-part conversation on test automation in delivery pipelines.

Figure 5. An example of continuous flow at the (team, project, program, division, enterprise) release level.

What about all of this makes automation and continuous delivery inclusive?

Remember the cross-functional strike team previously discussed? Many times, stakeholder numbers are minimized to control scope, time, cost, risk, and complexity because the developer, respectfully, is the constraint.

Automated continuous delivery pipelines change the math regarding how many stakeholders, requirements, and developers are required to deliver value.

With automation, we decouple the dependency between requirements and the capacity to meet them.

How Will We Deliver More Value with Fewer People?

There are three keys to moving into this new paradigm:

  • Use your cross-functional teams to define work.
  • All work must have definitions of done articulated as acceptance criteria.
  • All acceptance criteria become automated tests that are applied to user stories on the continuous delivery pipeline.
Strike teams build automated tests/checks in the continuous delivery pipeline. (c) Trility, LLC
Figure 6. Strike teams build automated tests/checks which are included in the continuous delivery pipeline designed to prove or disprove a user story is still behaving as expected.

Cross-functional teams contribute to the discovery, definition, and prioritization of roles, capabilities, and attributes in the backlog and participate in demos to verify value. The smaller strike team who makes the code commit, builds, verifies, and delivers the solutions also creates automated tests along the way.

Together, they rely upon definitions of done, automation, and the continuous delivery pipeline. Together they deliver a solution.

Principles for Delivering the Solution Everyone Wanted

  1. Let anyone at any time, for any reason, add any ideas, suggestions, or requests to the backlog.
  2. Curate, cultivate and prioritize the backlog perpetually, daily
  3. Use cross-functional delivery teams for backlog prioritization, epic and user story build-out, design, development, inspection, testing, and delivery behaviors from beginning to end of the project.
  4. Tell teams to focus on flow.
  5. Use version-controlled, continuous delivery principles from end to end of the project, i.e., from developer out into product implementation support and evolution (General Availability (GA)).
  6. Automate. Automate. Automate. If you would like to further explore the reasons and value behind software automation, refer to A Basis for Automation, Part I.

We don’t need to run from, defend against or hide from stakeholders and their expectations. Instead, invite them. Then continuously curate, prioritize, and automate their feedback.

How Do I Get Started?

If you’re perplexed by delivery teams saying they are done, but the solution delivered seems short on features, functions, and value, the conversation more likely lays around how software is being defined and delivered instead of what.

  • Ask your teams how they choose stakeholders.
  • Ask your teams how they choose requirements.
  • Ask your teams if, how and to what extent they use continuous delivery principles and automation. Do they pursue continuous flow?

Their answers point you to your next steps.

Interested in Examining Flow?

Trility joined Bâton Global for a podcast series on Human-Centric Transformation. In the four-part series, they discuss how leaders and technology can simplify and automate processes for team members, stakeholders, and customers.

Before you listen, view our companion infographics highlighting key takeaways as these organizations discuss how to better respond to industry headwinds and pressures.

Categories
Operational Modernization

A Basis for Automation: Predictable, Repeatable, Auditable Workflow

This article was previously published on LinkedIn.

I remember a math teacher from long ago telling the class, “Until you know how to do the math with a pencil and eraser, you cannot use a calculator.” And I have subscribed to this logic my entire life journey. Learn everything at the most basic level. Understand why not just what. Optimize the information after I understand so I can then learn even more. This is one of the great experiences that made me want to be a lifelong learner.

Another was a physics teacher sitting beside me, walking me through a book from the Smithsonian Institute on space. His questions to me, as we thumbed through the pages looking at high-resolution pictures of the planet were simple, “Can you imagine what it would take to travel to that planet?” “What do you think it would take to live on that planet?” And I, thereafter, sought to understand what it would take to solve these problems. This experience taught me, “Think very big and do not be intimidated by large, opaque, complex, high-risk problems.”

I also remember, with great sadness, when I realized there was more to learn than I would live long enough to understand and value.

All Big Things Become Small Things

So, I looked for methods of discovering, organizing, and leveraging greater volumes of information in my everyday life. I needed a way to discover and appreciate the depth and breadth of a seemingly infinite set of bodies of knowledge while accepting I only have one lifetime to do it. I needed a way to take big things and break them into small things so I could choose what, when, where, why, and under what circumstances they may directly apply, or cross-apply, to other endeavors in my life.

Common words for organizing big things into little things and so on include paradigms, frameworks, patterns, templates, reference architectures, taxonomy, decomposition, configuration management, deconstruction, classifications and even Table of Contents.

Figure 1. Big things decompose into small things.

To the dismay of all logophiles out there, I’m going to condense this discussion to one word – patterns.

I look for reusable patterns in everything. Patterns to understand things around me. Patterns to organize. Patterns to do work. Patterns to assess risk. Patterns to deliver. Life is full of reusable patterns.

Life is full of reusable patterns.

So, when you’re trying to understand something big, break it down into parts and pieces. It will be easier to understand, organize, prioritize, and build back up again at scale because you will discover one or more patterns. Whether something is broken down to the atomic level or to user classes, epics and user story threads depends upon your project.

Work Has A Predictable Pattern

Most people understand the idea of work. I am cold. I put on a coat. I am warm. I have dirty dishes. I wash them. I have clean dishes.

State A. Do something. State B.

And many people want to see the results they want to see – right now.

I want pecan pie right now. I want it to look and taste just like what my Grandmother used to make for me on holidays and birthdays. My Grandmother has passed away, I don’t have her recipe and I failed to ask her to teach me how to make the pie. I want it nonetheless. Now. Exactly the way she used to make it. With whipped cream. Do not fail me, maker of pecan pie.

What I want and what I can get is dependent upon an ability to:

  • See the big thing (pecan pie);
  • See the parts and pieces (ingredients); and
  • Understand the method (order and method of operations).

Whether I’m making Grandmother’s pecan pie, building a barn or implementing a continuous delivery pipeline in the cloud, they all require the same steps, in the same order, to begin and complete the work.

The basic pattern of work looks like this:

  • a request for work,
  • entry criteria (criteria by which we agree to start work),
  • a method of doing and a method of checking work,
  • exit criteria (criteria defining “done and acceptable”),
  • and a deliverable.
Figure 2. “Do Work” – A simple view of how work happens for one person.

People Do Not Perform Consistently

The unpredictable, non-conforming, variability of people is one of the things that makes life an adventure. People and their culture are rich and unique, and our memories and the stories we tell about them form a vibrant tapestry.

When it comes to work, if we know the pattern of work, then why do so many hard-working teams fail to deliver, let alone deliver well?

Humans are not automatons. Humans are, by nature, variably behaved, expressed and experienced. For 100 people to complete 50 individual tasks 100 times in a predictable, repeatable and auditable manner is a pretty tall order. Which may explain why a grande caramel macchiato retrieved from the same chain store in different cities tastes different so often. There is a recipe, an order of steps and method. Nonetheless, sometimes the coffee tastes like the highly caffeinated liquid weight gain I expected and other times a painful waste of money.

If there is a pattern and the work is human and manual, there will be variable results. Human results are variable. Why does only one team win the annual football bowl game while others do not? More interestingly for our conversation, explain why that same team doesn’t win every single year of their existence. Variability.

We know what a predictable, repeatable pattern of work looks like and we know how human variability can impact that pattern in everyday life.

Now let’s look at what happens when we have many people.

Work Patterns Get Complicated As They Scale

Assembling around an objective to achieve a result is seen in all of nature. It isn’t unique to humans.

Bees. Ants. Animal packs. Sports teams. Military units. Projects.

For Humans, work becomes more complicated as the number of people involved increases. With more people come more units of work, more steps and more latency between steps.

Consider the following behavioral pattern many of us see in organizations, “This team does work, then this team does work, then this team does work.” Have you seen this before?

Queue work, start work, do work, hand-off. Repeat.

When we watch ants decompose food, there appears to be a constant flow of activity. When we watch bees collect honey, we see the same characteristics. Flow.

When we watch people on projects, it simply isn’t the same.

Imagine being in the passenger seat of an old 1968 F-150 pickup while a teenager is learning to drive a stick-shift. Now imagine every time said teen pops the clutch, taps the accelerator, hits the brakes, or all of them at the same time, your head rocks back and forth between the glass behind you and dash in front of you. There was no padding in the dashboard. Learning to control the clutch is a practiced, learned behavior. Learning to push the accelerator while letting off the clutch is also a learned behavior.

Flow is a learned behavior. Flow must be sought on-purpose.

Now, imagine smacking your face on the dashboard, glass or both every time work moves from person to person on a project in your company. Start. Go fast. Stop. Start. Stop suddenly. Kiss the dashboard.

What if your face was the barometer of your organization’s flow? Imagine increasing the number of people, concurrent projects and tasks to span the company and you are the only person who hits glass and dashboard for all projects, all people, all steps, all starts and stops. Need a helmet?

If you think I’m exaggerating to make a point, I am. A little. The stick shift story is real. I feel bad for my dad and all the watermelons we ran over in the field that day. He ended up sitting in the seat sideways with arms against the seat and dash in a self-defense position. If there had been predictable start and stop patterns that day, perhaps he could have navigated the situation more enjoyably. I still remember the look on his face.

Figure 3. “Do Work and Wait” – A simple view of work for multiple people.

When it comes to performing work and delivering results, the ideal experience achieves a smooth flow of work being performed, with little to no wait times in between steps, and smooth transitions.

Wait time and unpredictable transitions likely cost my dad time on this earth realized as dynamic, premature aging. Wait time and unpredictable transitions cost companies time and money.

The “start and stop” method is also known by some as the “throw it over the wall” principle.

“My part is done. Worked for me. Good luck!”

We want flow like ants and bees. We more likely experience starting, stopping and pain like my dad while teaching me to drive a stick-shift.

Manufacturing Controls Flow-Through Batch Sizes

If you and I are on the same page regarding the value of flow versus kissing a dashboard with your face, let’s talk about how to get there.

Decades ago, the manufacturing industry began the use of assembly lines (automation) to increase flow, throughput, predictability, quality and manage their scaling economics. They received another boost in productivity and value when they moved from large to small batches along the same assembly line. Wait times decreased and flow increased.

And due to batch sizes, their ability to adapt to change increased.

In the manufacturing world, wait times (inventory in a wait state) are considered unrealized revenue and therefore waste. Manufacturing supply chains, therefore, seek to eliminate waste. They build things to make money. They do not build things to store them in the supply chain. The key? Flow.

Figure 4. Too much in-flight, undelivered work is unrealized revenue.

If warehouses full of product are considered unrealized revenue and therefore waste in the manufacturing industry, how do we then categorize in-flight, incomplete, undelivered or otherwise unfinished software solutions in companies? What do you think that implies with regards to the numbers of in-flight user stories or numbers of in-flight software projects?

What do you think happens when we introduce the idea of rework?

Work Always Has Rework

Ideally, when we run projects, things always go as planned. And when they don’t? We end up dealing with two subjects that weren’t in the original plan – technical debt and refactoring.

Technical debt is defined by work you know you need to do now, but decide to kick down the road until later. This creates additional work in the backlog. Just like interest rates on debt, the longer it sits there, the more time, complexity and/or cost it will take to address. Technical debt is work.

Refactoring is defined by changing, modifying or otherwise evolving something from a previously acceptable state of existence to a new and improved state of existence for the purposes of delivering desired value. Refactoring is also work.

Figure 5. Rework – “I found a problem. What do I do with it?”

When John finishes his task, the deliverables move down-line for Jane to complete her task. Jane finds a problem with the inherited deliverable and either fixes it, ignores it or sends it back up-line for John’s eventual attention.

If Jane fixes it on behalf of John, was it correct and complete? If she ignores it, will it be found and addressed later? By whom? If she sends it back up-line, how will John know? And when will John get to the refactoring work given his existing backlog of prioritized work?

The problem discovered by Jane impacts her ability to complete planned work. And depending upon her decision, it will become work for one or more others.

Now multiply John’s and Jane’s experience by the numbers of people, teams, projects, stories, and associative decisions to acknowledge, fix, send it back up-line to someone else’s queue or ignore it altogether.

This churn contributes to wait times between steps. And if a person doesn’t plan for rework, it also contributes to cranky people.

Rework happens. Plan for it. Manage impact to flow by decomposing all work into small, edible pieces. Manage your batch sizes. Seek flow.

How Do We Achieve Flow?

To consider automation, we have to first understand work, batch sizes, and flow. Otherwise, with automation, all we’re really doing is taking bad things, making them go faster and calling it digital transformation.

Steps to achieve flow:

1. Manage batch sizes. Break big things down into small things.

2. Minimize and eliminate wait times between steps and people.

3. Plan for, invite, and accept rework. Manage it through batch sizes.

4. Automate.

5. Repeat.

Automation is not the goal. Predictable, repeatable, auditable flow is the goal.

Automation is only the medium.

My math teacher has made sense for a very long time.

Pencil first. TI-88 programmable calculator second.

Read Basis for Automation, Part II, to learn the steps for ensuring a project team addresses requirements and prioritizes backlog before automating a continuous delivery pipeline.

Interested in Examining Flow?

Trility joined Bâton Global for a podcast series on Human-Centric Transformation. In the four-part series, they discuss how leaders and technology can simplify and automate processes for team members, stakeholders, and customers.

Before you listen, view our companion infographics highlighting key takeaways as these organizations discuss how to better respond to industry headwinds and pressures.