Role Of Managers In Large-Scale Scrum

A client who is basing their scrum adoption on the LeSS scaling framework recently sent me the following question about the role of manager in Large-Scale Scrum.

Question

I’ve read that when scaling scrum with LeSS, cross functional teams need to have 1 manager. The author advocated strongly for this. In reality I’ve seen this fail miserably. Losing the domain owner causes the group to skew heavily to the bias of the team manager, as well as lose the ability to strongly drive and foster domain expertise. I’ve seen product people be appointed, and the tech goes to pot. Also, I’ve seen technical people don’t want to report up through product. I’ve seen engineers as team managers, but it’s rare to find good engineering/product people, and you have the reverse problem. I’m not completely convinced that a team manager is a good idea. Chris, what are your thoughts?

Answer

My experience aligns with yours. I think teams work best when it is clear that their product owner is the one person who directs what objectives they focus on. The development team member’s job is to work with their teammates to build a high-quality solution to the problems/objectives selected by the product owner.

The role of manager becomes much more about coaching and mentoring, not assigning work. I’ve seen it work well when individuals have managers based on their primary skill area. For example, a Java engineer having a manager who is an even more skilled Java engineer. The manager helps the contributor to improve their skills and grow into an ever more valuable contributor. The managers also anchor communities of practice (COP), sometimes called guilds. All of the Java engineers get together on a regular basis in their COP/guild to discuss things related to Java development: tools, conventions, and architectural direction. These decisions influence how they do their work, but not what work they do. Sometimes, a COP/guild identifies a technical objective they feel is important to the business and may submit requests to specific teams’ backlogs to address the issue. In these cases the COP/guild will make the business case for why the product owner(s) should have their teams pursue the objective.

Managers also have an important role in creating and maintaining an environment where teams will thrive. This usually involves working with scrum masters to identify systemic impediments reducing teams’ effectiveness and implementing interventions to improve the environment.

All of this seems to align with the description of the manager role on the LeSS website.

Cheers,

Chris

Posted in agile, scrum | Leave a comment

Sprint Planning Prep For Product Owners

Sprinter getting readySprint planning is the first event each sprint. Doing it well will align the scrum team and set a course for success. Doing it poorly will waste time, energy, and team morale. Here’s how a product owner can prepare for a successful sprint planning meeting.

Prerequisite: Well-refined product backlog items

If your sprint planning is to have any hope of succeeding, you need to already have well-refined (some say well-groomed) items at the top of the product backlog. I recommend maintaining two to three sprints worth of sprint-ready items (stories) at the top of the product backlog.

Start With A Goal In Mind

The product owner should walk into sprint planning with a meaningful sprint goal that they would like the scrum team to achieve this sprint, and a set of product backlog items that would support achieving that sprint goal. For example, the desired sprint goal might be to reduce the time it takes for a customer to complete their order. Some of the supporting product backlog items might be: prefilling the bill info, prefilling the shipping info, and optimizing the speed of the database for the check-out transactions.

Order The Backlog To Support The Goal

Once the product owner has their proposed sprint goal identified, they move sprint-ready product backlog items that would support that goal to the top of the product backlog. The product owner can use the team’s historical velocity to guide them as to how many stories would be reasonable. If the team’s velocity is 100 points per sprint, then the product owner might select about 100 points worth of stories supporting their proposed sprint goal, and move them to the top of the product backlog.

Be Prepared For Change

All of this may sound like the product owner gets to plan the sprint without consulting the team. Nothing could be further from the truth! This pre-work that the product owner does becomes the starting point for the sprint planning meeting. In the sprint planning meeting, the product owner and development team work together to create the sprint goal and identify which specific product backlog items will be in the team’s forecast (some say commitment) for the sprint. This pre-work by the product owner will set the stage for a productive and efficient sprint planning event.

Cheers,

Chris

Posted in agile | Leave a comment

Business Value Myths

Pot of gold with rainbowTo prioritize items in a scrum team’s product backlog, the product owner needs an estimate of both value and cost for each item. This way, they can identify which items have high ROI and move them to the top of the backlog. Other concerns such as dependencies must be considered, but in general the team should always be working on the product backlog item (PBI) with the highest ROI.

This makes sense. And yet, most organizations don’t have estimates for the value of the items in their scrum teams’ product backlogs. Why this glaring omission? I believe that it is due to several common myths, or misunderstandings, about the nature of business value.

Myth: Business value is money.

Many people mistakenly think that we should/could put a dollar (or currency of choice) value on each product backlog item. It’s not that simple. Money is a one-dimensional concept; it can be represented by a single number. But business value is multi-dimensional.

The business values money in multiple forms: revenue, cost-savings, and profit. The business may also value: increasing market share, breaking into new markets, improving our brand recognition, attracting & retaining great employees, reducing technical debt, understanding emerging technologies and trends, environmental sustainability, giving back to the community. Anything that the business is willing to expend resources to pursue, is something that the business values. So you see, business value can’t be expressed in a single dimension with a single number.

Myth: Business value can be measured and quantified.

Measuring all of the dimensions of value is essentially impossible. It may be possible to measure some of the dimensions. Let’s say we have a PBI for increasing the size of the ‘Buy Now!’ button. We think that changing the size of the button will lead to more sales. We could implement the new button and run an A/B test and measure how many more sales occur. But this is only measuring one dimension of value, not total value. And, it’s a trailing metric. That is, we have to implement the PBI in order to measure the value created. We need leading metrics, or estimates, so that the product owner can make well-informed decisions about what to build.

Myth: Business value is objective.

We would like there to be an absolute, objective truth to what the business value of a PBI is, but there isn’t. We build products for our stakeholders. Value is in the eyes, and opinions, of those stakeholders. Therefore, it is inherently subjective. Different stakeholders will value the same PBI very differently. Oh, and their opinions, and thus the value, changes over time.

So here we are. Business value is multi-dimensional, can’t be measured, is subjective, and changes over time. It sounds totally intractable! No wonder people get stuck. The good news is that business value can be estimated using some simple, yet very effective techniques. Stay tuned for future posts about exactly how to go about this. If you just can’t wait, sign up for one of our Certified Scrum Product Owner (CSPO) or Advanced Certified Scrum Product Owner (A-CSPO) workshops.

Cheers,

Chris

Posted in agile, scrum | Leave a comment

Defects And Done

Question

The developers on our scrum team are done with a story (product backlog item). Then defects are found during QA testing. Do we count it done? What about the defects?

Answer

Not DoneMy general advice is that a story should not be considered done in the sprint if there are defects, or if the testing isn’t complete. If you know there is more work to do before the story would be acceptably complete then it’s not done. This is where the definition of done comes in.

A key part of scrum is the definition of done. The idea is that when a scrum team says a story is done, then the business can recognize the value anytime they choose. For software products, this means the story is ready to release. This is why a scrum team should have all of the skill areas needed to get something all the way done. This usually includes testing.

On the other hand, sometimes a defect escapes detection even when we’ve made every effort to test and confirm that the story is complete. If a story is tested, declared done, shown in the sprint review, and some time later a defect is found, that defect becomes a new product backlog item. Of course, the team may want to revise their definition of done, or at least their testing procedures, in order to prevent any similar defects in the future.

If you need help creating a good definition of done, have a look at How To Create Your Team’s Definition Of Done.

Cheers,

Chris

Posted in agile | Leave a comment

Daddy, Where Do Product Backlog Items Come From?

StorkA scrum team works from a prioritized list called the product backlog. Product backlog items are often called user stories. In this article we’ll examine the lifecycle of a product backlog item. It starts with conception. You see, when a product owner and a development team love each other very much…

What Is A Product Backlog Item?

A product backlog item (PBI) is a request. The PBI describes a valuable outcome that stakeholders want from the scrum team. When I use the word stakeholder, I’m referring to someone outside the scrum team. Example PBIs include: enhancement requests, bug fixes, and documents. In each case, there is a valuable and verifiable outcome the business wants the team to produce.

Where Do Product Backlog Items Come From?

The PBI is a request for the team to create some value. These requests can come from almost anywhere: customers, sales, marketing, managers, product management, or other teams. Members of this scrum team probably have ideas about what they should build as well. Literally anyone can make a request or suggestion.

How Do We Manage Inbound Requests?

We don’t want every request going directly into the product backlog. That would make a mess. The product owner needs to collect all requests in a holding area. I call this holding area the protobacklog. The product owner evaluates each request and refines it with stakeholders. They will solicit a business value estimate and the initial acceptance criteria. Armed with this information, the product owner decides if this request should be pursued further.

Refining Requests With The Scrum Team

For the requests that make the cut, the product owner presents them to the development team during a product backlog refinement meeting. This meeting is sometimes called storytime or the backlog grooming meeting. Typically, the product owner will invite the stakeholders who care about the request. This allows the development team to interact directly with those stakeholders and thoroughly understand their request. During the meeting, acceptance criteria are negotiated, an estimate is created, and the team indicates if the request is sprint ready. After this initial refinement with the team, the product owner decides whether to add the request to the product backlog, or not.

Welcome To The Product Backlog

Each item that makes it into the product backlog will have the following attributes: description, order, work estimate, and value estimate. The description is often divided into an overview statement and a list of acceptance criteria. The order, sometimes called priority, is simply its location in the product backlog. The product backlog is a strictly ordered list; no two items are of equal priority. The work estimate is created by the development team and is frequently expressed in story points. The business value estimate is created by the stakeholders and is often expressed in value points. If that last bit intrigues you, you might be interested in learning more about business value estimation in our Certified Scrum Product Owner and Advanced Certified Scrum Product Owner workshops.

Where Do Rejected Items Go?

It can be useful to keep requests that didn’t make it into the product backlog. We don’t want them cluttering up the protobacklog, so we put them in the icebox. The icebox is where requests go to die, or at to least wait in suspended animation. The icebox is an unmanaged list that doesn’t get any additional attention or effort. Every once in a while, something happens that makes an old request more interesting and the product owner can thaw it out and move it back to the protobacklog.

How does this compare to the way requests get into your team’s product backlog? Leave us a comment and let us know.

Cheers,

Chris

Posted in agile, scrum | Leave a comment

Emergency Work In Scrum

Red box with axe in case of emergencyScrum strikes a useful balance between flexibility and focus. In sprint planning, the product owner presents the most important objectives to the development team. The development team commits to as many of those as they believe they can deliver in the sprint. Once sprint planning is over, the business doesn’t change their mind about what they want. The development team is able to focus on delivering the product backlog items to which they committed. At the beginning of the next sprint, the business has another opportunity to change direction in any way they need to.

Every so often something comes up that can’t wait until the next sprint cycle. This could be a problem that has arisen, such as customers not being able to log in. It could be a business emergency such as needing a feature rushed into production in order to land a new client. Such unplanned work is the subject of something that I call “the emergency protocol.” The emergency protocol isn’t an official part of scrum, but it’s a useful addition that many organizations choose to adopt.

Declaring An Emergency

First off, we need one person with authority to declare something an emergency: the product owner. The product owner’s job is to make sure the team always focuses on the most valuable outcomes. Therefore the product owner decides if this urgent thing is more important than the team’s current work. Is it worth putting the sprint goal at risk?

Dealing With The Emergency

After declaring an emergency, the product owner shares the emergency with the development team. It’s important that they go to the whole team, because we want the team to take ownership of this emergency and decide how best to resolve it. Maybe the whole team will swarm on the issue. Perhaps the team will decide that two or three members can address the emergency while the rest of the team continues with the planned work. It’s important that the team decides, not somebody outside the team.

After The Emergency

After the emergency has been resolved, the team gathers together and considers whether they still have full confidence they can deliver all the sprint backlog items and achieve their sprint goal. If they believe they can, then they move forward as usual. If, however, they no longer believe they can get everything done, then the product owner decides what items to remove. If the business is not going to get all of the originally committed product backlog items, then deciding which ones should be sacrificed is a business decision we want the product owner to make. The product owner selects one or more product backlog items to remove until the team has confidence they can complete the remaining items.

How does this affect the team’s velocity?

Since the emergency was unplanned work, there are no story points associated with it. Velocity is a metric that tells us the rate at which planned work is getting done. Unplanned work reduces the rate at which the planned work gets done. That is to say it reduces velocity. Remember: story points and velocity are a tool for predictability, not a way to keep score.

Does your organization have a different way of handling emergency work? Leave a comment and let us know.

Cheers,

Chris

Posted in agile | Leave a comment

From Component Teams To Feature Teams

Components I recently facilitated a software development group’s transition from component scrum teams to feature scrum teams. The new structure reduces cross-team dependencies, which had been causing significant delays in shipping new features. Over the course of a day, we dissolved the existing component teams, groomed a shared product backlog, created a shared definition of done, self-organized into new teams, and held LeSS-style sprint planning meetings. The excellent work everyone did left me in awe, and I felt honored to have the opportunity to facilitate the day. The participants left energized and excited for their new adventure.

What follows is a description of how we structured a one-day event to transition the participants from being members of component teams to being members of feature teams.

Set The Stage

The group’s manager had been preparing the individuals for the transition. In each employee’s weekly one-on-one meeting they had been told that their current team would be shutting down and they would be participating in a day-long event to create new teams.

Early on the morning of the big day, the leadership team gathered together with me to go over the plan for the day one last time. The day would start with very brief presentations by leaders about what wasn’t working with the current component team structure: dependencies are killing us! The organization’s chief scrum coach gave a very brief introduction to the LeSS model on which the new structure would be based.

We took a few minutes to honor the work of the teams that were being dissolved today. They had done good work on their components. We spent a bit of time making sure each person was introduced to the larger group, including details about their skills and history at the company.

Create A New Product Backlog

We began collectively to refine the new product backlog items. We started with a high-level look at the new objectives. We brought items from the teams’ previous backlogs in as well. We used The Team Estimation Game to create the initial estimates for the new product backlog. During lunch, the product owner assembled the product backlog, ordering each of the items that we had just refined.

Self-Organize Into New Teams

After lunch, we asked the participants to self-organize into as many teams as possible, given the constraint of any team being able to complete virtually any item in the product backlog. This would require each team to have members from each of the previous component teams. The organizational leaders and I huddled in the room watching the group explore various options. Occasionally, they had questions that required an answer from one of the leaders. After about 45 minutes of deliberation, the new teams announced themselves. I had the honor of giving them their first assignment: name your team. That took another fifteen minutes, as the teams really wanted coordinated names. It seems like a small thing, but I’ve found that teams that name themselves seem to do better.

Create A Shared Definition Of Done

Next up, I facilitated the teams in creating a shared definition of done. You can read about the technique I used in last February’s post: How To Create Your Team’s Definition Of Done.

Plan The First Sprint

Now that we had teams, a product backlog, and a definition of done, we were finally ready for sprint planning. The first part of sprint planning was done together. The product owner would pull the first item from the product backlog and ask the group to decide if it could be done in the sprint and which team would take it. Then the next item was pulled from the top of the backlog, and so on. It wasn’t long before the teams collectively said “Enough!” They couldn’t accept any additional items and still have full confidence that they would be completed in the first sprint.

For the second phase of sprint planning, the teams retreated to different corners of the room to task out the stories that they had just committed to deliver. The scrum masters for each team supported the teams with facilitation so that the tasking could happen efficiently, yet self-organized.

Wrap It Up

Five o’clock was fast approaching as we celebrated all that had been accomplished during the day. Conversations were still buzzing between new team members as they left the room. As the organization’s leaders and I debriefed the day’s events, I was in awe of everyone that had organized or participated. I left full of hope for the future of the organization and the new teams. I’m excited to follow along on their journey as feature teams.

Cheers,

Chris

Posted in agile, coaching, scrum, teams | Leave a comment

Agile And Scrum Conference List 2019

Graduates of our Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), and Advanced Certified Scrum Product Owner (A-CSPO) workshops often ask how they can continue their journey of learning about scrum, as well as earn Scrum Educational Units (SEUs) to help them renew their Scrum Alliance certifications. Attending conferences is a great way to accomplish these goals. Here is a list of conferences that you might consider attending in 2019. I’m sure we’ve missed some good ones, so point those out to us by leaving a comment.

Event Start Date Location Focus
Agile Open Northwest February 6 Portland, OR Open Space
Agile Open San Diego February 7 San Diego, CA Open Space
European Testing Conference February 14 Valencia, Spain Software Testing
Product Camp Portland March 2 Portland, OR Product Management
Agile Games New England April 8 Boston, MA Agile Games
Mob Programming Conference April 11 Boston, MA Mob Programming
Goto Chicago April 28 Chicago, IL Software Development
Deliver Agile 2019 April 29 Nashville, TN Agile Engineering Practices
Craft May 7 Budapest, Hungary Software Craftsmanship
Scrum Gathering Austin May 20 Austin, TX Scrum
XP 2019 May 21 Montreal, Canada Agile Software Development
Mile High Agile May 29 Denver, CO Agile & Lean Methods
Agile & Beyond May 30 Detroit, MI Agile
Agile + DevOps West June 2 Las Vegas, NV Agile
Agile Testing Days US June 23 Chicago, IL Agile Testing
Agile On The Beach July 11 Cornwall, England Agile Product Development
ÜberConf July 16 Denver, CO Programming
Agile Day Riga July 19 Riga, Latvia Open Space
Agile 2019 August 5 Washington DC Agile
Agile Business Conference September 25 London, England Cross-Sector Agile
Play4Agile North America September 26 Ontario, Canada Coach Camp w/Playful Approaches
Pacific NW Software Quality Conference October 14 Portland, OR Software Quality
Scrum Gathering Vienna October 28 Vienna, Austria Scrum
Agile + DevOps East November 3 Orlando, FL Agile
Agile Open Nor Cal Expected October San Francisco, CA Open Space
Agile Open SoCal Expected September Irvine, CA Open Space
Agile Coach Camp US TBD TBD Agile Coaching
Joy Of Coding TBD Netherlands Software Development
Agile Maine Day TBD Portland, ME Agile
Posted in agile, conferences, events | 2 Comments

My Clients Aren’t Dying To Adopt Scrum

atul-beingmortal-cover3d1-319x479I recently read the book Being Mortal by Dr. Atul Gawande about empowering people to make end of life decisions. Now you might be wondering what that have to do with scrum? Well it turns out the same questions we might ask a dying person to help facilitate their end of life in an empowering way are the same ones we might ask a client to empower their scrum practice or agile transformation.

Dr. Gawande wrote the book about his experience (or lack of experience) having difficult yet essential end of life conversations with patients and their families. Conversations about what is important to the patient at the end of their life and what impact that might have on the the treatments they undertake and ultimately the experience that they and their families might have.

Medicine has a natural tendency to promote life at any cost. As Dr. Gawande shows in the book, there is often a substantial cost to patients and their families as they are hoping that the next treatment will be “the one.”

While agile transformations are not end of life issues, there are some parallels for agile coaches here. We agilists often think the next coaching session or the next training or the next incremental improvement will be the game changer for our client. We are often driven by the power of the possibility we see, for what agile practices can do for a company or if you are like me, for the world.

In the book Dr. Gawande outlines two ways that doctors interact with patients: paternalistically or as an informer. In the paternalistic mode, the doctor treats the patient like a child and the doctor the good father, telling the patient what to do and reassuring them it will be ok. As the Informer, they are laying out all the objective options and information and assuming the patient will put it all together and make the best decision for their treatment. Often neither of these approaches empowers the patient and they are left at odds and unsupported in their decision about their treatment.

I could immediately see myself falling into both of these traps in my scrum training and coaching work. Sometimes, my client regards me as the expert and is eager to follow whatever advice I give. It’s all too easy to become the wise ‘parent’ in this scenario. Sometimes, I provide them with information about best practices and such and assume that they will make a good decision now that they are informed.

Going back to Being Mortal, Dr Gawande describes a third approach he learned from a hospice director: the interpretive approach. In this approach, the doctor starts by asking the patient: what they want the outcome to be, what’s important to them and what are they willing to do to get the outcome. Then they listen, a lot. They talk about tradeoffs in treatment and experience. They give options. They counsel. They listen to both the spoken and unspoken desires of their patients to understand what is truly important to them. In essence they are working with the patient and their family to create context, and then help them interpret the information so they can have the kind of treatment or end of life that really works for them. This is distinct from a longer life at all costs approach.

It strikes me that this approach could make a huge difference for our clients. First we help our clients think about and articulate what they really want (why they want to be more agile) and what they are willing to do to get it. From there, we can help them understand the possibilities of an agile approach and what that really means for them. This includes understanding the tradeoffs and the various options they might pursue. In this way, perhaps we could impact our clients by facilitating difficult conversations where they confront the reality of their culture and what they are willing to do or not do to have a result. From there the actions for them to take might be more clear and the motivation to take them much stronger.

For me, this means giving up my own attachment to the idea that agile practices are always the best thing, in every situation. This is like a doctor giving up the idea that prolonging life is always appropriate.

For now – I’m working on slowing down and asking my clients and students: “What do you want the outcome to be? What is your motivation for adopting scrum? And what are you willing to do to get it?” Then listening, without judgment or attachment, for how I can support them achieving their goal or outcome.

Posted in agile, coaching | 2 Comments

Scaling Scrum With Scrum

Leadership Scrum Team

One of our clients recently reached out to us asking for advice about how to manage their organization’s scaled scrum adoption. They wanted to know if they could use scrum to manage the adoption of scrum in the organization. The short answer is yes.

Guiding an organization’s adoption of scrum is a big project. It’s a project that will require a cross-functional team. It’s a project where the full scope of work can’t be known when the work starts. It’s complex, exactly the kind of endeavor that you want to use scrum to implement. When I’m working with organizations that are adopting scrum at scale, I always start by recommending that they create a scrum adoption team, and that this team use scrum to do the work of rolling scrum out to the organization.

One of the many benefits of leaders using scrum to guide their organization’s adoption of scrum is that they are leading by doing, instead of telling. “Do as I do” is much more compelling than “Do as I say.” The leaders will also develop a much deeper understanding of what they are asking their people to do, and will be better able to understand the changes needed in order to be successful.

This team needs a product owner, someone who can answer the question “Why is this organization adopting scrum?” The organization’s management is seeking some kind of value, and they believe that investing in this scrum adoption will get them that value. Is the value faster time to market? Higher product quality? Happier customers? Happier employees? Something else? These are all laudable goals, but it’s important that the product owner for the scrum adoption team understand which of these is most important to the business. Based on this knowledge, the product owner can create and share a vision for how this scrum adoption will create value for the organization. This vision will guide the team’s work.

The scrum adoption team will need a product backlog filled with the deliverables of the scrum adoption itself. One product backlog item might be identifying a pilot project to try using scrum. Another product backlog item might be to pick the team members for that first scrum team. Yet another item might be to get scrum training from Agile Learning Labs for that first team (okay, that was shameless). As the organization starts to adopt scrum, the scrum adoption team will discover impediments that are preventing scrum from working well, such as middle managers that aren’t willing to let go of control. These impediments will lead to new items in the scrum adoption team’s backlog. Perhaps they’ll decide to bring in Agile Learning Labs to do some training and coaching with those middle managers (okay, I’ll stop now).

The team will need a scrum master. As with any team, the scrum master will focus on helping this team become high performing. The scrum master will coach the team and help them use scrum effectively to self-organize and continuously improve.

Most importantly, the team needs team members. These should be people from various parts of the organization who will do the work of guiding the organization’s adoption of scrum. I recommend that the team have some permanent members, perhaps high-level managers from engineering, test, product, and human resources. The team should also have a rotating group of people from the field. These are people who will be using scrum and/or be impacted by the organization’s adoption of scrum. Examples include: scrum masters, product owners, engineers, testers, managers and anyone who will interact with a scrum team. These rotating members should serve on the team for pre-defined terms, perhaps three to six months. These members of the scrum adoption team will provide the muscle to get the scrum adoption team’s work done. They will also act as eyes and ears, keeping the adoption team in touch with what’s really going on.

Here are a couple of things to be careful of. First is the role of the scrum adoption team itself. Scrum is about ‘doing it better and better’ not about ‘doing it right’ and so the scrum adoption team should not be the scrum police, telling the teams how they are doing it wrong. Their mission should be to help the organization learn, improve and drive toward the specific value that the organization is seeking from their scrum adoption. Focusing more on education and less on enforcement usually leads to better results.

Secondly, the scrum adoption team needs to guide the organization in the selection of appropriate metrics for the scrum adoption. Measure the wrong things, and that’s what you will get! For example, velocity (often measured in story points) is a terrible metric. No organization ever adopts scrum to get “more velocity.” What they probably want is to deliver more value or to reduce time to market. So create metrics that focus on these things, not velocity.

Obviously, I’ve just scratched the surface here. Hopefully it helps you get started creating your scrum adoption team.

Have you been a part of a scrum adoption team? Or perhaps you’ve worked at an organization that needed one, but didn’t have one? Leave a comment and let’s talk about it.

Cheers,

Chris

Posted in agile, scrum, teams | Leave a comment