The People And Process Balancing Act

The Agile Manifesto Teaches Individuals and Interactions Over Processes and Tools

There’s a common misconception, especially among those new to Agile, that the relationship between people and processes is one of friction — that it’s a dichotomy. The subtlety of the language used, “individuals and interactions over processes and tools” implies that both need to exist. The framers of the Agile Manifesto even state, “while there is value in the items on the right (Processes and Tools), we value the items on the left more (Individuals and Interactions).” I agree with this and would also argue that processes and tools are an input to productive interactions among individuals. We know what is more valuable according to the Agile manifesto but, which one is most important? People or Processes? Maybe we’re thinking about it all wrong?

Chinks In The Armor

Asking, “what’s more important, people or processes?” is a fair question to ask when you’re new to Agile. Especially since most organizations looking to “go Agile” start with Scrum (by the way, practicing Scrum does not mean you are Agile. It’s a great start as long as the leadership team continues to stay open minded and doesn’t limit the organization to just Scrum). Usually, a handful of developers, project managers, business analysts and line of business managers are sent to a two-day class scrum class; they receive a certificate dubbing them newly minted “Certified Scrum Masters/Product Owners/Developers” and are given a small project to show a “proof of concept” with the

storm trooper
Scrum Reveals The Chinks in the Armor

new framework. It’s chaotic and exciting at the same time; however, the organization’s weaknesses begin to show up (Scrum has a way of shedding the spot light on the problems that have existed in the organization for a long time). I call these the “chinks in the armor.”

The biggest chink I’ve seen most teams discuss in their retrospectives are the People vs Process Dependencies. Invariably, team members and managers dig in their heels about which one is better. This is because people default to what they know best. They use what has worked for them in the past. Change is hard, even when there’s clear evidence that what they’ve been doing will not work anymore because of changes in the business environment.

As a coach, it’s important to understand the pros and cons of the people and process dependencies. It should be explained clearly with not only your teams but, with the management team too. The organization will have to move past striking a balance and figuring out which areas need the most improvement. Instead, they should assess the parts of each dependency and figure out what works best for them today. Below are some extreme examples of each dependency to illustrate the pros and cons of both.

People Dependency

Pros

  1. It gives workers satisfaction – employees feel satisfied when they know they are valued
  2. Flexible – employees are empowered to perform work in the way they feel is best
  3. Adaptable – the ability to pivot and make changes is the hallmark of business agility
  4. Efficient – unnecessary steps in a process are avoided
  5. Helps to retain high-achieving, confident, people – people stick around because they know they are important and are good at their job

Cons

  1. Less repeatability – changing processes are not repeatable and leads to waste
  2. Makes customers nervous – customers feel comfortable when there’s visibility on the process
  3. Can provide a “false sense” of a high degree of control – processes are measurable. What get’s measured gets done. When managers rely solely on the self-reporting, certain messages may get filtered and there is no data to verify.
  4. Turnover impacts are much greater – institutional knowledge can walk out the door or get hit by a bus
  5. Higher risks – for the reasons listed above

Process Dependecy

Pros

  1. Repeatability – repeatability helps with predictability
  2. Easier to improve – a documented process is easier to improve with less risk to the organization
  3. Less people dependent – automation of easily repeatable tasks frees up resources for more value added activities
  4. Predictability – it can be measured objectively and relied on as a lever for control in the organization
  5. Brings new personnel up to speed faster and with less risk of poor performance

Cons

  1. Paperwork can overshadow the task – processes that are overly complex distract from value added work
  2. Resources must be spent enforcing or ensuring compliance – managerial debt is incurred. Managers spend less time removing impediments and more time micromanaging processes.
  3. Someone must own and manage the process
  4. Less “thinking” is needed – employees and managers can become complacent if there’s no impetus for process improvement. This leads to waste. 

Processes Come First But They Should Not Be Valued

I know I’m going to rub a few people in the Scrum community the wrong way (and probably piss of a few of the business process analysts too) But, processes should come first but they should not be valued in the same way we value our people and interactions. It’s easy for managers to regard processes as instruments for control. Some managers finely craft their business processes. They labor over them and build complex systems for the organization. But only effective processes facilitate people. Not complex ones. If you require a practical rule of me, I recommend you murder your darlings.

“Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it — whole-heartedly — and delete it before sending your manuscript to press. Murder your darlings”

— Arthur Quiller-Couch,

On the Art of Writing

vintage scale.jpg
People and Processes Are Not Equal

I argue that people and processes should not balance each other. Many representations of this balancing act builds a false dichotomy. It implies that they are of equal value. Like the framers of the Agile Manifesto, I do not value them the same way.

Processes should support our people and facilitate their interactions. Processes are either operational, supporting, or management oriented. If they do not provide value. Murder them. It’s up to the teams to decide which processes they need most and which ones can be forgotten. Each organization is different. Each darling should be judged accordingly — but retain the ones that still add value. Don’t throw the baby out with the bath water. Don’t assume that just because you’re “doing Agile” that processes no longer needed to exist. No, processes are still important. They unlock your people’s ability to work at a higher level. But it’s time to end the love affair with processes and value your people.

Share your thoughts in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum

Improving Agile Retrospectives With SMART Goals

Six Elements of An Effective Strategy

 

 

 

Six Elements Of An Effective Strategy

Back to Basics: The Six Elements Of An Effective Strategy

Developing a strategy ready for execution is one of the most difficult tasks facing organizations. Global commerce is no longer reserved for the “titans of industry.” Small to medium sized enterprises are now operating in the global economy and other than resource constraints, the playing field is generally even for anyone with quality services and products. Understanding the basics of an effective strategy is more important than ever.

“Going back to basics strengthens your foundation”

Money, people, and time are finite resources and should be used wisely. When developing a new strategy or enhancing an existing one, leaders must understand there are three value areas that a strategy should address before proceeding.

  1. Improving Operational Performance
  2. Improving Customer Service
  3. Exploiting New Opportunities

Understanding the three value areas enables leaders to establish priorities based on business goals. Additionally, as a new initiative is developed and acted on, the tactical needs must be met while the organization continues moving forward. Long story short, understand your business needs & do not disrupt operations. 

The Six Elements Of An Effective Strategy

Element 1 – Continuation Of Policy

Formulating an effective strategy means understanding the landscape you operate in and and those affected by your decisions. Policies are both external and internal.

  • External policies are the laws and industry standards your organizations must follow. External policies mandate what an organization must adhere to and can include international, federal, and state laws.
  • Internal policies are an organization’s vision and mission. They must be aligned with an organization’s core competencies and value chain. Internal policy should be easily understood by everyone in the organization. A good litmus test is, “can our policy be described in three sentences or less and does it address the way we operate, how we treat our customers, and capture new markets?”

Element 2 – Overcoming Adversarial Competition

Understand those who operate in your market and either directly or indirectly oppose your progress. Leaders need to understand their competition, their internal policies, and value stream. Leaders should be honest when assessing the weaknesses of their own organizations and compare themselves as objectively as possible. Weaving fantasies about the competition or the competencies of your own organization leads to bad decision making. Entrepreneurs of small to medium sized organizations are especially prone to fantasy based thinking. While optimism is a good quality for successful entrepreneurship, it is not the basis for effective strategy formulation.

“If from your strategy you can’t identify anything that you would say no to, it’s probably not a good strategy.”
– Karl Scotland

Element 3 – Account For The Talent Gap

Organizational leaders and tactical managers must understand the skills required so the policy can move forward and succeed. An actionable strategy accounts for the talent gap. Unfortunately, HR departments lack the ability to close the skills gap — either through recruitment & retention efforts or training & development. Leaders must develop a roadmap for developing & recruiting the required skills for strategy execution.

Element 4 – Impetus & Focus

Firm understanding of the corporate culture and the attitudes required of those operating internally of the organization helps leaders gauge how well employees and the tactical management will readily adopt the strategy. Experienced leaders understand culture and attitudes are not specifically ‘defined’ — they evolve over time and accumulate based on whom the organization hires. The following considerations should be made when creating your strategy and roadmap.

  • Who are our external customers?
  • How well do our employees treat our external customers?
  • How well do we treat our employees?
  • When we’ve implemented change in the past, does the leadership team “walk the walk” or just walk around with a “big stick?”
  • Is company culture a strong consideration when hiring new employees?
  • Do we invest enough in training and fostering the growth of our talent?
  • How well do we on-board our new hires?
  • How well do we evaluate performance and customer satisfaction?
  • Do we provide opportunities for growth?
  • Do our employees feel empowered to make decisions and take ownership of the issues or are there silos in our organization?

Element 5 – Communicate The Guiding View Into The Future

Everyone wants to understand where their organization is moving and what the organization wants to accomplish. This has a strong influence on the decisions, priorities, and the way work is accomplished from day-to-day. Return to the internal policy established in the first element and re-write it in a way that everyone in the organization can easily understand. Fold in your vision statement in a way that makes sense and adopt it as the organization’s mantra. Consistently communicate the mantra across all mediums. It’ll eventually stick and influence your culture.

“The mantra should describe the way we operate, how we treat our customers, and communicate the guiding view into the future”

Element 6 – Measure

The above elements are all aimed at creating a strategy that can respond quickly to change. Many refer to this as business agility — starting with intention and pivoting over the long-term as internal or external factors require. Leaders should track what was intended, what emerged, and what was realized and adjust their strategy accordingly. The company culture and your talent gap will most likely cause you to lag behind emergent strategies, however, measuring the progress over time is useful because it can help you refine your strategies in the future. The below figure illustrates my point. Each black dot represents an environmental change and the green lines are the emergent strategies (E1, E2, E3). The red line lags behind, this is what is realized.

PlannedVsEmergentStrategy

The outcomes that should be measured are:

  1. Operational Performance
    • Time to Produce
    • Cost Savings
    • Quality
  2. Customer Service
    • Time to Delivery
    • Value Delivered to Customers
    • Customer Satisfaction
  3. New Opportunities
    • Time to Market
    • Return on Investment
    • Addressing Unserved Needs

Leave your thoughts on strategy in a comment below or if you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts
Sources

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum.

The 5 P Pyramid Model.

I recall my first software development project as both exciting and nerve racking. Luckily, I was paired with an extremely talented Business Process Analyst who’s approach to requirements gathering was both methodical and like watching an artist at work. He introduced me to several ways of thinking about organizations — what I now call the 5 P Pyramid Model. This model has helped me analyze business processes and has been a wonderful tool for change management and exercising business agility. I continue to refine his ideas and accumulate my own knowledge, however, I would like to share his lessons with you by using the Scrum Process as an example.

“When eliciting requirements or attempting to document information from your stakeholders, keep the following items in mind:

The 5 P Pyramid Model
  1. Policies,
  2. Processes,
  3. Procedures,
  4. People, and their
  5. Personalities”

Policy

Policy is about understanding the landscape you operate in and those affected by your decisions. Policies guide decisions and provide rationale for their existence. Well written policies describe the what — they do not describe how an organization will fulfill the requirements of the policy. Generally, you can bucket your policies as external and internal. Internal policies also have two characteristics: De jure and de facto.

  • External policies are the laws and industry standards your organizations must adhere to. These include international, federal, and state laws you must adhere. In the case of Scrum, a government agency has policies regarding purchasing. Here is a great article regarding public-sector purchasing using Agile.
  • Internal policies are the policies related to the organization’s vision, mission, and goals. Whether undergoing business projects or internal IT projects, policies regarding how products and projects are delivered also exist. In the case of Agile, an organization’s policy describes the use of iterative and incremental development techniques vs. gated and sequential development.
    • De jure internal policies: Have been formally evaluated, approved, and adopted by the organization. Usually, they are easily accessible, understandable, and “written in stone.”
    • De facto internal policies: Have been widely adopted and accepted by the organization, however, they are not written and documented — leaving room for interpretation. Finding and documenting these policies can be difficult. At times it can feel like you’re on a journey to find the tribal leaders who can teach you the “song of the tribe.” It becomes increasingly difficult to find the tribal leaders to teach us their “songs” as more people retire and the trend for job hopping continues to grow.

Process

Business processes are the high level activities that an organization accomplishes in order to fulfill policies. They can and should be analyzed at different degrees of resolution. Think about the saying, “Give me the 30,000 foot view” vs. “At the ground level.” They should be assessed and dropped into three different categories:

  1. Operational processes are the processes related to an organization’s value chain. They are the core business activities that organizations engage in to deliver their goods and services. Using the processes that our Scrum teams use, we can see that the Sprint Review and Pushing Code to Production directly add value to our customers because this is where our stakeholders review and accept the code (sprint review) that was developed during the iteration and the delivery team makes it available to for use (delivery of shippable code).
  2. Supporting processes are the secondary functions that exist within the organization. They support the core business processes but do not provide value to the customers directly — Sprint planning and the daily scrum is where our delivery team plans what will be worked on (planning) and discusses the work being done over the past 24 hours to address any impediments to meeting the sprint goals (daily stand up). 
  3. Management processes help coordinate the operations and supporting processes. They drive for business efficiency and success. The sprint retrospective is used by the delivery team to inspect and adapt their daily work to improve efficiency and product backlog grooming is for prioritization, addressing dependencies, and writing effective user stories before the next planning meeting.

 

Scrum Process Diagram
A 30,000ft view of the Scrum Process

Procedures & People

Procedures are the steps that need to occur in each process to reach desired outcomes. They are normally fulfilled by a combination of people & technologies and are sometimes referred to as standard operating procedures. Let’s look at the procedures in our Scrum processes as an example and identify the people involved.

Sprint Planning
  1. Scrum Master: Opens the planning session, sets expectations, announces the agenda, and enforces a “time-box” throughout the planning session.
  2. Product Owner: Presents a prioritized and groomed product backlog to the Delivery Team and states what business objectives the stakeholders want attention during the iteration.
  3. Delivery Team: Examines the high priority user stories, asks clarifying questions with the Product Owner, identifies potential risks & dependencies, and helps refine acceptance criteria.
  4. Scrum Master and Delivery Team: Reviews the velocity from the last few iterations and plans their capacity for the coming sprint.
  5. Delivery Team: Uses relative estimation to size the user stories.
  6. Delivery Team: Uses their past velocity to benchmark how many user stories should be responsibly committed to.
  7. Product Owner and Delivery Team: Finalizes the Sprint Goal together.
Daily Scrum (aka. Daily Stand-up)
  1. Scrum Master: Ensures the meeting occurs, ensures no management interference on the free flow of information and discussion, and enforces a 15-minute “time-box” on the Daily Stand-up.
  2. Delivery Team: Conducts the meeting and discusses the progress towards the Sprint Goal.
  3. Product Owner: When available, attends the meeting to answer questions for the Delivery Team and makes decisions when needed.
  4. Scrum Master: Makes notes of any impediments that the Delivery Team is facing and immediately takes action following the Daily Stand-up to resolve impediments.
Sprint Review
  1. Scrum Master: Opens the Sprint Review, sets expectations, announces the agenda, and enforces a “time-box” throughout the review.
  2. Delivery Team: Presents their work in accordance with the acceptance criteria agreed upon during the planning meeting to both the Product Owner and any stakeholders invited to the meeting.
  3. Product Owner & stakeholders: Once the Delivery Team has finished presenting their work, the Product Owner and stakeholders are invited to ask clarifying questions and interact with what was built.
  4. Product Owner & Delivery Team: Takes notes of any issues, risks, or concerns from the stakeholders related to what was built or will be built in the near future.
  5. Product Owner: Accepts or Rejects each user story the Delivery Team worked on during the sprint.
Delivery of Shippable Code

Teams and organizations have their own way of pushing their code into their production environments. Due to the various best practices that exist, a separate blog post will be posted to address this at a later time. Seriously! This could be a ph.D thesis!

Sprint Retrospective
  1. Scrum Master: Facilitates the meeting, enforces a “time-box” and “sets the stage” –all information shared during the Retrospective stays within the meeting. I call this the “Vegas Rule” because what happens in Retro stays in Retro.
  2. Scrum Master: Starts with an ice-breaker if the Delivery Team is new and reviews past velocity with the team. The Scrum Master may also reminds the team of all the impediments that occurred during the sprint if the Delivery Team faced any during the sprint.
  3. Scrum Master and Delivery Team: The Scrum Master facilitates “Data Gathering” activity and the Delivery Team produces the data.
  4. Scrum Master and Delivery Team: The Scrum Master facilitates an “Insight Creation” activity and the Delivery Team creates the insights.
  5. Scrum Master and Deliver Team: The Scrum Master facilitates a “Prioritization” activity and the Delivery Team prioritizes what they want to improve.
  6. Scrum Master and Delivery Team: Decides how they will improve their own processes (either operating, supporting, or managerial processes) and creates a realistic plan to execute on. Scrum Master may need to coach new Delivery Teams about developing SMART Goals or some other goal setting techniques.
Product Backlog Grooming
  1. Product Owner: Prioritize the Product Backlog based on business objectives.
  2. Product Owner and Scrum Master: Gathers the requirements from stakeholders and writes preliminary User Stories and Acceptance Criteria
    • User Stories: As a <some role or person>, I want to <some procedure>, so I can <achieve a business outcome>.
    • Acceptance Criteria:
      • Functional
      • Non-Functional
      • Performance
      • Security
  3. Product Owner, Delivery Team, Scrum Master and invited stakeholders: Scrum Master and Product Owner facilitates an activity for the stakeholders and Delivery Team to refine the user stories and acceptance criteria.

Personalities

The personalities of our employees influences their effectiveness for their role(s). Selecting the right people with desired personalities ensures that the procedures and processes are completed correctly and in a manner that matches the organizational culture. While I won’t go into the different “types of personalities,” I will speak to the types of characteristics and traits that make an effective Scrum Master, Product Owner, and Delivery Team member.

  • Scrum Master
    • Ability to coach others with empathy.
    • Ability to resolve conflict and communicate with empathy.
    • Deep understanding of Agile and Project Management.
    • Facilitation skills and creativity.
    • Servant Leadership.
    • High level IT skills and knowledge.
    • Business acumen.
  • Product Owner
    • Strong leadership.
    • Ability to prioritize work and competing demands.
    • Ability to make decisions independently.
    • Ability to gather business requirements and elicit information from stakeholders.
    • Understanding of Agile and Project Management.
    • Domain knowledge.
    • Tactful communication skills.
  • Delivery Team Member
    • Ability to work well with others.
    • Openness to coaching.
    • Strong communication skills.
    • Strong technical skills.
    • Ability to analyze and solve problems.
    • Honesty and integrity.
    • Understanding of Agile and Project Management.

I’d love to hear your thoughts on the 5 P Pyramid Model in the comments below or if you’d like to have a discussion about Business Process Analysis, please contact or connect with me on social media!

Photo Credit: Flickr

Related Posts
For more on: