Scrum

Ditch “The Three Questions” And Adopt The Agile Mindset Already

| Jeremy Brien

Ditch “The Three Questions” And Adopt The Agile Mindset Already

Scrum teams that have been using Scrum for a while are most likely settling into the new framework. The chaos and dust from the change has settled and things are normalizing a bit. However, each team has their own unique way of doing things and, from the outside, managers may be holding onto their “command and control” mindset. Shouldn’t a process, like the daily scrum, be repeatable and look the same for all teams? Perhaps their mentality is that Scrum is a “methodology” and it should be strictly adhered to vs. a light weight framework in the “Agile toolbox?” Maybe they’re too focused on accountability of individuals vs. team autonomy? Whatever the cause, the Agile mindset just hasn’t quite set in yet. With a little bit of coaching, they’ll get there. Exercise patience.

One thing I’ve observed from leaders who haven’t quite fully adopted the Agile mindset yet is their insistence on strict adherence to “The Three Questions” during the daily scrum. There exists a feeling that “Vanilla Scrum” is the best way to do Scrum (There’s no such things as ‘Vanilla Scrum’ by the way). There’s a perception that the best way to do Scrum is to make everyone answer the three questions:

  1. “What did you do yesterday?”
  2. “What will you do today?”
  3. “Do you have any impediments?”

While I agree that the scrum guide can be prescriptive at times, the three questions listed above are not, in fact, mandatory. Seriously, read the section on the Daily Scrum and then come back.

Welcome back. So now that everyone’s educated, let’s talk about creativity. There’s a lot of room for creativity from each team and every individual. The Scrum Guide tells us “What we should do,” however, each team is left to figure out “How best to do it.” The format of the daily scrum is no different and there’s a lot of room for creative and constructive discussion questions. Strict adherence to the three questions can become an impediment to communication.

When speaking to your leaders, it’s usually not a good idea to open the scrum guide and show them where they’re wrong. It’s not very tactful and you miss a great opportunity to make the conversation a teachable moment.

When discussing this with leaders, start by asking some simple questions. I usually start with, “what does ‘vanilla scrum’ look like to you?” Their answer will likely reveal one of two things.

  1. Focus on the process; or
  2. Focus on individual accountability.

It makes sense, doesn’t it? As a manager, their ability to reliably deliver products, services, or projects is a reflection on their ability to lead their unit. Managers are accountable to stakeholders, customers, and their bosses. Yes, managers have bosses too. It’s pretty simple when we put ourselves in their shoes and I think we can empathize with their position. It can be a great deal of stress. Management isn’t for the weak of heart.

Yes, managers have bosses too.

Creativity Over Strict Processes

Command and control via processes can be effective. Set up a process. Follow the process. Repeat. But at what cost? I’d argue at the cost of creativity. I’d argue at the cost of low employee engagement. I’d argue complete and utter mediocrity. Of course I’m not advocating for zero processes either. That would be irresponsible. The people and process dependency is a balancing act, but let’s not rehash that discussion.

My recommendation would be to challenge the manager’s perspective about creativity and engagement. They may say they value it, but their actions may speak differently. Perhaps they view the daily scrum as a status report? That’s an anti-pattern you don’t want to have. Trust me. Been there. Done that. Got the t-shirt.

Scrum shouldn’t be “standardized across all teams.” If the pain point of the organization is variable quality and unreliable delivery, Scrum won’t fix that for you. But if you allow creativity to happen, then your employees will become engaged. And engaged employees who are empowered can move mountains. They’ll fix things on their own because at the end of the day, everyone wants to go home at five thirty, have a beer and spend quality time with their family. It’s the mindset, not the framework that we should strive for. Intrinsic motivation, not another carrot.

Responsibility Over Individual Accountability

I’m not advocating for zero accountability. Again, that would be irresponsible. But, the need to hold people accountable for their actions is another “command and control-ism” and it makes people fearful for their jobs. As a result, it stifles creativity and people will do just enough to stay of the RADAR and out of trouble. This is a much tougher problem to address because a manager focused on “holding people accountable” likely suffers the same from their own management. We can all empathize with our managers on this. Just like us, they’re subject to the same influences of organizational culture. As a coach, you must be courageous enough to address this with everyone in the organization, especially when another witch hunt is just around the corner. Are we trying to figure out who put crappy code into production? Or are we trying to figure out how crappy code got into production? You see the difference? The first question is about assigning blame. The second question is about addressing a problem. Stop with the witch hunts. People make mistakes. It’s a part of doing business.

My recommendation would be to re-frame the conversation around responsibility. Accountability is for Product Owners who must own the success or failure of a project. They are the single wring-able neck. However, responsibility can be shared and is something reserved for teams who share the responsibility of managing risk, keeping on schedule, staying within scope, and producing quality work. Product Owners are accountable for the overall performance of the project and guiding the team with a product road map. The Product Owner provides the what. The Team provides the how.

Stopping the flow of communication so they neatly fit the mold of the three questions can introduce risks into the project. It jeopardizes the quadruple constraint (Scope, Schedule, Cost, and Quality). So let your team discuss the sprint goal. Let your teams talk about the future beyond the next 24 hours. Let them self-organize in a way that’s most comfortable for them. They’re responsible for delivery — have the courage to step back so they deliver.

I’d love to hear your thoughts on the daily scrum or the anti-patterns you’ve recently spotted. If you’d like to have a discussion, leave a comment below or contact me. Feel free to connect with me on social media as well!

Photo Credit: Pixabay

Related Posts

Scrum Anti-Pattern: Daily Stand-Up As A Status Report

The People and Process Balancing Act

Agile Leaders Understand Customer Service And Culture

The People And Process Balancing Act

| Jeremy Brien

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

 

 

 

Scrum Product Owners Part 2

| Jeremy Brien

The Product Owner Chooses Business Value

As the “single wring-able neck,” the Product Owner is tasked with maximizing business value and setting the direction for a new or existing product. She shares the guiding view into the future and collaborates with customers, stakeholders, technical teams, and supporting roles to steer the product to the desired end-state. In this article, I would like to share my favorite two value areas that effective Product Owners understand.

  1. Customer Service
  2. Operational Efficiency

1. Customer Service

An organization is nothing without it’s customers — they are either external or internal customers. Customers are the people who use the product to fulfill a specific need. A product that is easy to use and accurately fulfills a customer’s needs is valuable to the organization. Design considerations like User Interface and User Experience need to be considered when crafting user stories, however, the main consideration is, “how are we best serving our customer with this feature?” 

External Customers look to “exploit artefacts[sic] produced by the organization with specific requirements and specifications” (Hobbs, 2016). External customers are essential to the success of the organization as it operates to produce the artifacts specified by external customers.

Internal customers are all members of the organization who rely on assistance from each other to fulfill their duties in the production of artifacts specified by the external customers.

“If you build a great experience customers tell each other about that. Word of mouth is very powerful.”

— Jeff Bezos, Amazon

2. Operational Efficiency

An organization is unable to best serve it’s customers if it’s inefficient. While running the air conditioning in the middle of winter is wasteful, Product Owners go beyond the obvious to make operations more efficient. Below is a list of operational efficiencies in a ‘lean’ context that Product Owners should consider in their user stories. Product Owners should start with, “how does this feature improve our operations or reduce waste?”

  1. Reducing defects – features aimed at reducing defects strive to reduce errors, mistakes, rework, and preserve data integrity of internal and external customers.
  2. Reducing motion – features directed at reducing motion strive to automate a formerly paper-driven process. This helps improve efficiency and standardizes the quality of those processes. Additionally, frees up resource capacity so internal customers can engage in more technical work.
  3. Creating a common language – features sighted on centralizing information in a common place creates a lexicon synonymous with the organization. It simplifies the way information is shared and understood throughout the organization. Internal customers are all speaking and sharing the same meanings and when extended to client-facing applications, external customers speak the language too.
  4. Improving decision making – features trained on increasing transparency allow internal customer to make decisions quickly — ultimately helping organizations exercise business agility and ‘pivot’ when the internal or external environment prompts for it. 

Leave your thoughts on Product Ownership or Business Value 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

Sources

Hobbs, B. &. (2016). Projects with internal vs. external customers: An empirical investigation of variation in practice. International Journal of Project Management Volume 34, Issue 4, 675 – 687.

Related Posts

Scrum Product Owners Part 1: The Product Owner Steers The Ship

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

Six Elements Of An Effective Strategy

Agile Leaders Understand Customer Service and Culture 

 

 

 

Scrum Product Owners Part 1

| Jeremy Brien

The Product Owner Steers The Ship

The Product Owner can be described as the “single wring-able neck” in Scrum. They are responsible for maximizing value and setting the direction for a new or existing product. They work with development teams, stakeholders, groom & prioritize their backlog, and share a guiding view into the future. The Product Owner is the most important role in the organization and only a special kind of person volunteers for it. The rest are usually ‘volun-told.’

Intention and style shape the effectiveness of a Product Owner. Like all of us, Product Owners come from different backgrounds or roles. Angela Druckman, of the Druckman Company has a wonderful series on Product Ownership and I have personally worked with her and attended her Certified Scrum Master and Certified Scrum Product Owner courses during our Agile Transformation at the Nevada Department of Transportation.

As a coach, we don’t want to make assumptions about the anti-patterns our Product Owners may have inherited from their previous roles.

“An anti-pattern is something that looks like a good idea, but which backfires badly when applied.”

-Jim Coplien

Never assume that an ex-project manager uses “command and control” with their teams or that ex-business analyst will struggle with emotional intelligence. Leave all judgement to Judge Judy. Your job as a coach isn’t to fix anti-patterns. It’s to tap into people’s potential. Anti-patterns will extinguish as each person’s potential is unlocked and the agile mindset becomes a part of who they are. 

Captain & First Mate: Product Owner & Scrum Master

The first thing I want to stress is the relationship between a Product Owner and Scrum Master. These two roles, when combined with the Delivery Team, are a lot like a Project Manager and Delivery Team. Let’s take a 30,000ft view of the 10 Knowledge Areas of Project Management and see where the Product Owner and Scrum Master have responsibility in regards to traditional project management and its’ relation to iterative product development.

  • Integration Management
    • Traditional: This responsibility falls onto the Project Manager via a Work Breakdown Structure (WBS) and Gantt Charts.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master via collaboration and iterative development.
  • Scope Management 
    • Traditional: This responsibility falls onto the Project Manager and Change Control Board via the Scope Baseline and Change Management Process.
    • Scrum: This responsibility is the Product Owner’s via collaboration with stakeholders, prioritizing business objectives, and the product backlog.
  • Cost Management
    • Traditional: This responsibility falls onto the Project Manager via the Cost Baseline, budget, and Change Management Process
    • Scrum: This responsibility is the Product Owner’s via iterative delivery, business objectives, and budget.
  • Time Management (formerly Schedule Management)
    • Traditional: This responsibility fall onto the Project Manager via the Schedule Baseline, critical path, and Gantt Chart.
    • Scrum: This responsibility is shared among the Delivery Team and Product Owner via iterative releases.
  • Quality Management
    • Traditional: This responsibility falls onto the Project Manager and delivery team via Quality Assurance (QA), Quality Control (QC), and User Acceptance Testing (UAT).
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner via Quality Assurance (QA), Quality Control (QC), Sprint Reviews with stakeholders & Product Owner, Scrum Master resolving impediments during the daily stand-up, and Agile Retrospectives.
  • Procurement Management
    • Traditional: This responsibility falls onto the Project Manager and stakeholders via the organization’s Project Management Office procurement Policies, Processes, and Procedures
    • Scrum: This responsibility is not defined in Scrum, however, the organization’s Policies, Processes, and Procedures should be followed. A Scrum Master or  Product Owner should work closely with the Project Management Office.
  • Stakeholder Management
    • Traditional: This responsibility falls onto the Project Manager via the stakeholder management plan.
    • Scrum: This responsibility is shared among by the Product Owner and Scrum Master. The Product Owner elicits requirements from stakeholders and the Scrum Master insulates the Delivery Team so they can focus on the product.
  • Communication Management
    • Traditional: This responsibility falls onto the Project Manager via the communication plan.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master. The Delivery Team meets daily and communicates progress and impediments. The Product Owner manages stakeholder expectations. The Scrum Master can assist with managing stakeholder expectations, facilitates the Daily Stand-up, Sprint Planning, The Sprint Review, The Sprint Retrospective, and coaches the principles of Agile to everyone in the organization.
  • Resource Management (formerly Human Resource Management)
    • Traditional: This responsibility falls onto the Project Manager via the Resource Management Plan.
    • Scrum: This responsibility falls onto the Delivery Team and Scrum Master via iterative planning sessions, capacity planning for each iteration, and relative estimation and using past performance to forecast velocity.
  • Risk Management
    • Traditional: This responsibility falls onto the Project Manager via the Risk Register, Risk Management Plan, and Contingency Reserves.
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner. The Delivery Team and Scrum Master use retrospectives to address risk and improve how they work. The Product Owner sets the guiding view into the future, sets the priorities for each iteration via the backlog, and makes informed decisions based on the technical expertise of the team and the strategy of the organization.

While the above is a high-level, “vanilla,” list of the shared responsibilities and activities, it illustrates my point. The Product Owner and Scrum Master are a lot like a Project Manager split into two roles. This allows them to share responsibilities and specialize in select areas — making them more effective and increasing the chances of success. As a coach, we need to make sure these two stand as a united front. The Product Owner steers the ship and the Scrum Master is the first-mate.

Leave your thoughts on Product Ownership, Scrum, or Project Management 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

Improving Agile Retrospectives with SMART Goals

 

 

 

 

Improving Agile Retrospectives With SMART Goals

Soccer goal on an green field
| Jeremy Brien

Improving Agile Retrospectives With SMART Goals

Agile retrospectives are one of the best feedback loops built into Scrum. It allows delivery teams to pause from their day-to-day work to inspect and adapt their way of doing things. One of the final deliverables of an effective retrospective is a plan to implement improvements on how they build their products. Some of the things a delivery team may choose to look at are:

  • Tools & Techniques,
  • Processes & Practices,
  • People & Communication,
  • Quality & Risks,
  • Project Scope & Schedule,
  • Technical Debt & System Architecture,
  • Organizational Culture & Priorities.

A Caution For New Scrum Masters

While the above listed topics usually elicit deep, and sometimes passionate discussions, new teams may fail to actually develop and implement an effective plan to address the insights they generated. When I first started running my Agile retrospectives, my delivery teams would generate valuable insights, have deep and meaningful conversation, and then leave feeling a bit exhausted but generally glad that some dirty laundry was aired.

The result was mostly positive. Team members would develop better working relationships with each other and be more open to practicing empathy on a day-to-day basis. However, after a while, I observed that the discussions kept gravitating towards the same things over and over again. I realized some teams weren’t developing and implementing any plans to improve themselves.

As a scrum master, I was letting my teams down. I was facilitating great discussions and watching the teams develop better working relationships. Of course this was an accomplishment, however, that accomplishment was blinding me to the fact that the teams were maturing and ready to tackle process related problems. They moved past their interpersonal differences and were ready to tackle deeper issues. It was easy to recover from that fumble and SMART Goals helped me do it.

SMART Goals

A SMART goal is an acronym based goal setting guide. It stands for: Specific, Measurable, Attainable, Relevant, and Time-bound. It’s simple to use and forces teams to think, plan, clarify, and begin measuring their goals. To help your team set a SMART goal in a retrospective setting, I recommend allocating the last 20 minutes of the retrospective and writing the following quote and the word “SMART” on a white board.

“A dream is just a dream. A goal is a dream with a plan and a deadline.”

– Harvey Mackay

S – specific

We want to be as precise as possible with what the team is trying to fix or improve on. One tool I use comes directly from scrum — I have the team write a user story.

As a <delivery team> we want to <address some issue> so that we can <some improvement to be made>.

This should be done in an iterative fashion if the user story is not specific enough. Asking the below questions will help the team zero in on the specifics of their SMART goal.

  • Why do we want this?
  • Who is involved?
  • What resources are constrained?
  • Why is the goal so important to us?
M – measurable

What gets measured gets done. Think of this portion as the acceptance criteria of the user story. The measurements will be unique to the goal, but try to use quantifiable items. Ask questions about the desired end state. If the SMART goal is centered around the project you can use the 10 knowledge areas

  • Project Integration Management
  • Scope Management
  • Cost Management
  • Schedule Management
  • Quality Management
  • Risk Management
  • Resource Management
  • Procurement Management
  • Communication Management
  • Stakeholder Management
A – attainable

This is our first check point — the team should reflect and assess if their SMART goal is realistic. Like effective user stories, we need to check if the SMART goal is independent and free of dependencies. If the SMART goal isn’t free of dependencies, the team may need to return to the Specific portion of their SMART goal and address any dependencies that exist.

R – relevant

This is our second check point — the team should reflect and assess if their SMART goal is germane to the insights discussed during the retrospective. As a Scrum Master, you can ask questions like:

  • Is this a worthwhile effort?
  • Are we the right group of people to take on this effort?
  • Is this the right time to address this effort?

Again, if the team doesn’t define the SMART goal as worthwhile or discovers they are not the right group of people to take on the effort, they should return to the Specific portion of their SMART goal and identify something within their span of control.

Note: if the team discovers that another group is more suitable to address the issue discussed, the Scrum Master should take the generated insights and work with that group after the retrospective adjourns. 

T – time bound

The final step is to establish a target date. Teams tend to work better when there’s a deadline in place. The team, armed with the specifics of their SMART goal, defined metrics, and an ideal end state should be able to set a realistic date. In my experience, the date should be no more than 2-iteration lengths (4-weeks total assuming 2-week iterations).

Leave your thoughts on Agile retrospectives or SMART goals in the comments below or if you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Flickr

Related Posts
For more on:

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

| Jeremy Brien

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: