Blog


Diagnosing the Challenges in Scrum

When people go to the doctor's office, they often complain of superficial manifestations of a problem (i.e., "chief complaints") that don't present any serious concerns, but in reality, are indicators of a much more serious systemic illness.

I've come to the conclusion that we in the Scrum field are also dealing with a similar type of scenario.

For those of us who have been coaching for a while, it's probably a common experience to have a team member or a manager come to us with what appears to them as a "key problem," but in reality, turns out to be a symptom of a much more serious underlying dysfunction.

On June 1, 2015, there was one-day agile conference held in New York by a well-known local agile community: Big Apple Scrum Day. It brought together more than 250 Scrum and agile practitioners from around the globe.

I organized the "Scrum Coaching Clinic" for the event. I personally coached about a dozen people that day, and my experience only solidified the notion that it's crucial to trace a presented problem back to its original root cause.

From that event, here are some examples of local/topical challenges that were initially presented as "key problems" by attendees, but were then traced to more systemic issues …

Example 1

Symptom (chief complaint): Lack of honesty in retrospectives. Individuals very reserved in retrospectives.

Details: Individuals are very reserved in retrospectives. Too many generalizations, not enough specifics. Real problems are not discussed or downplayed. Actionable items are not identified. Too much "political correctness" and fudging.

Further discovery: Direct line management attends retrospectives, usually at senior management's command. Retrospective recaps are viewed as "official documentation" to be shared widely - this puts many people in harm's way (reprisals are not uncommon). In retrospectives, management frequently looks for individual accountability, as oppose to team accountability.

Example 2

Symptom (chief complaint): Miscommunication in executive reporting.

Details: Team-level metrics and data (velocity, throughput, forecasted dates) are not easily "translatable" to communication and reporting that is presented to senior management.

Further discovery: Metrics and data collection at the team level are not reliable in the first place (e.g., velocity is very volatile). As information travels up the chain of command, it is "formatted" to fit what is perceived as the "usual format" at that level. Along the way, data gets skewed and fudged. Individuals with limited understanding of work size and complexity also contribute to estimations. While agile implementation is attempted at a team level, senior management is not educated enough to comfortably read agile metrics and reporting.

Example 3

Symptom (chief complaint): Lack of reliability with estimation techniques.

Details: Velocities are volatile. The same work is estimated differently by the same team at different times.

Further discovery: Inability to normalize work size and translate it into "money." Poor teaming. Lack of cross-functionality. For every developer (coder), there is at least one (non-coder) whose understanding of work size and complexity is rather limited. Team members don't get a chance to work together long enough due to resource re-shuffling and can't "normalize" their view on work.

Example 4

Symptom (chief complaint): Difficulties with talent retention.

Details: Companies heavily rely on temporary staffing, instead of building their internal technical expertise.

Further discovery: Acquire unpredictable quality staff (usually lower quality workers at a lesser cost) who must soon depart a company due to HR policies. As a result, talented people are in scarcity, and so is knowledge retention. Continuous knowledge transfer is required with much of the knowledge falling through the cracks and getting lost, as people tend to protect their jobs by taking their knowledge with them as they leave.

Example 5

Symptom (chief complaint): Lack of synergy with product ownership.

Details: Odd relationships between product owners and teams. At times, direct reporting lines between POs and team members. At times, multiple "equally important" stakeholders stepping into a PO role simultaneously.

Further discovery: Very few POs have combination of knowledge, authority and willingness to intimately engage with technology. Frequently, the PO role is assigned as a mandate and is in competition with other responsibilities of an individual. Poor definition of a customer. Difficulties finding an individual whose "paycheck" truly depends on product development success. There is no traceability between efforts and money spent on development, and extra revenue generated as a result of development (i.e., no analytics on ROI).

Conclusion

While speaking to individuals that day at the clinic, I came to the conclusion that very few are actually willing to travel "upstream" from a topical problem to its deeper root cause.

As Scrum coaches, we should refrain from jumping too fast to conclusions. Sometimes, the effect of anchoring is too strong and hard to resist; the initial information presented may be loaded with hidden anticipation for a particular recommendation - a trap that we, as coaches, should avoid falling into.

By emotionally detaching from the company and people we are coaching while at the same time collecting information and not allowing ourselves to be led into false and premature conclusions, we are improving our chances to build a more objective, unbiased view that spans far beyond superficial symptoms and much deeper into organizational layers.

Gene Gendel is a Certified Scrum Coach, Certified Large-Scale Scrum (LeSS) Practitioner, CSP, CSM and PMP.

Choosers vs. Users

We often talk about our “customer”, they’re at the center of everything we do. But we rarely talk about who our “customer” may actually be. Often, we just assume that our customer is the user of our product … but what if they’re not?

It may seem strange to imagine a case where our customer and our user are not the same person, but it happens more often than you may think. But if our customers are not the users of our product, then we need to think about who is, and how we can design a product that appeals to them, too.

For example, imagine that we create educational apps for kids. We write these apps to appeal to kids, and we want them to be fun.

Kids are our users.

So, to appeal to our users, we craft colorful environments filled with enticing audio cues and addictive rewards systems. And, as a result, kids love our apps.

But, kids aren’t paying for our apps, their parents are. So, we also need to appeal to the parents. In this scenario, the parents are our choosers. This means that the app needs to provide more value beyond simply being “fun.” Perhaps it needs to provide educational value, or it simply needs to occupy the kids on a long car ride. Whatever the reason, it ultimately needs to serve the needs of the parents who will actually be the ones to spring for it.

But we can’t forget the kids, if they don’t enjoy the app then they’ll stop playing with it. And if they stop playing with it then they won’t be occupied on long car rides and their parents won’t buy apps from us again.

See what we did there? We’ve created a cycle. Whether it turns out to be virtuous or vicious is up to us.

Enough of This Consumer Nonsense

I know what you’re thinking: Sure, that example is all well and good for consumer apps, but I build business products. I build products for the enterprise. I don’t have to worry about this nonsense. But what if I told you that your choosers-versus-users dilemma is even more pronounced?

Imagine that you’re building a CRM app for the real estate industry. You’ll want the the product to appeal to real estate agents, so you’ll want it to be easy to use, lightweight and provide useful information such as contact info and recent conversations that agents can draw on when interacting with prospective buyers and sellers.

In fact, we could even customize it to their industry to allow agents to quickly access additional information such as each prospect’s desired home type and school district.

It should be everything they could ever want. After all, they are our users.

However, there’s just one problem: The agents aren’t paying for the product; the brokers who own the brokerages they work for are. And as much as the broker would probably like to make their agents happy, they’re not likely to spring for the cost of a custom CRM system just to put a smile on their faces. So we also need to appeal to them, perhaps even more so. They are our choosers.

To make the system worthwhile to our choosers, we’ll need to provide features that meet their unique needs. Many of these will likely stem from their agents’ ability to bring in new business and close sales, but may also include things like understanding the types of properties their agents are transacting (and what types are likely to transact successfully), the number of times their agents are reaching out to prospects, and who the most productive agents are.

So our product needs to include features such as reporting on listing trends, providing insights into communication trends between agents and prospects, and ranking agent profitability.

And, we need to do all of this without sacrificing the agent’s user experience.

Although our choosers (brokers) are paying for the product, they’ll derive no value from it unless our users (agents) find enough value in it for themselves to continue to using it. For example, brokers will find a lot of value in understanding the number of times that an agent reaches out to a prospect, and how that number correlates to the the likelihood of closing a listing.

But, an agent won’t log those interactions into the system without getting some value out of that action themselves. This means that in addition to the broker-facing feature of correlating interactions to listings, we also need to design an additional agent-facing feature that incentivizes them to log their interactions in the first place, such as letting an agent know when it’s been more than two weeks since they reached out to a prospect.

Otherwise, agents won’t log their interactions and brokers won’t have anything to report on. And if our users don’t find enough value to keep using our product, then our choosers won’t find enough value to continue to pay for it.

So What Do We Do About It?

So, what do we do about this? First, we need to understand who are choosers and users are, and whether or not they’re the same person.

Next, we need to determine the incentives for each group to use our product. What do our users hope to get from our product and what do our choosers hope to get from it?

And finally, we need to understand how the incentives for the users will create value for the chooser, or if gaps exist where they don’t. For example, what element of value do choosers wish to derive that users are not incentivized to provide?

Once we understand where these gaps exist, then we can design features and flows to help create the value expected by both. By keeping this in mind, we can ensure that we create not only a product that our users will love, but also a product that our choosers will pay for.

And then, everyone will be happy.

Is the Product Owner a Member of the Scrum Team?

At the March meeting for the Agile Nashville User Group, we had a lively discussion around whether or not the Product Owner was a member of the Scrum team. This stemmed from a comment about the Product Owner not attending the sprint retrospective since it was primarily only for the team. There were several people on both sides of the issue, each very passionate about their respective stance, so in this article, I thought I would throw in my own two cents worth.

Following "The Rules"

Several people pointed to the “Scrum Guide,” as it clearly states that the "Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master." This is pretty definitive, but still some people pressed the opposite view. There were references made to other organizations such as the International Consortium for Agile, Scaled Agile Academy and the Project Management Institute and their reference materials, which were not as clear cut.

I found this very timely since I had just come back from the Mile High Agile conference where Mike Cohn of Mountain Goat Software had given the keynote, which contained some guidance around just following "the rules."

Mike cautioned that agile practitioners sometimes get too caught up in prescribed rules to the point where they start to blindly follow them. While most attendees involved in the discussion were open to idea of the Product Owner not being on the Scrum team and not attending the sprint retrospective, many seemed to get stuck on what the rules were from the Scrum Guide.

Another interesting thing that coincided with Mike's keynote was the idea of confirmation bias, where we tend to search for or interpret information in a way that confirms our preconceptions.

One of the user group members brought in some research material on this subject at our next meeting. In this material, it outlined what most of the major agile/Scrum organizations stated in regards to the Product Owner being on the Scrum team and attending retrospectives.

The document was well referenced and contained multiple viewpoints, but the section that most aligned with the author's own view was the most robust and annotated. When people with the opposite viewpoint reviewed the content, they tended to focus on the sections that leaned towards their own opinion.

Back to the Basics

When I was asked by several of the group members what I thought, I used the age-old coaching trick of answering a question with a question: "Why do you think the authors of the Scrum Guide clearly state that the Product Owner is a member of the Scrum team, and if it is so definitively stated, why are we still debating it?"

Agile Values and Principles
Now I don't do this just to be a jerk (that is a side benefit), but rather to get people thinking beyond the rule and more about why the rule is there in the first place.

When I train Scrum teams, almost one-fourth of my class is spent on the values and principles from the Agile Manifesto. Often, this is a quick reference slide in some of the training I've seen; but to me, it is at the core of what we adopt in agile – and more importantly, why we adopt it.

Teams definitely should adopt a set of mechanics and rules as part of their process, but these can evolve and change over time where the underlying values and principles remain fairly immutable.

So, let's look at the first part of my question about why Jeff Sutherland and Ken Schwaber decided to state that the Product Owner is part of the Scrum team.

When I look at one of the first principles in the Agile Manifesto, I think what applies is the following: "Business people and developers must work together daily throughout the project."

The Product Owner's job is to maximize the value of the product as the primary representative of the business stakeholders and end users. So if we consider the Product Owner to be one of the "business people," then we want them to work daily with the developers.

In Scrum, developers are part of the Scrum team, so we are saying that we want to have the Product Owner working together daily with the Scrum team. To me, that sounds like they are part of the team.

For another example, take the following principle: "The best architectures, requirements and designs emerge from self-organizing teams."

As the owner of the product backlog, the Product Owner is primarily responsible for the requirements of the product. The developers are primarily responsible for the architecture and design of the product.

As the principle states, we believe that the best way to create these is to have a self-organizing team. Once again, the implication is that the Product Owner is part of the Scrum team so that they can collaborate on these efforts.

Now take our user group's specific issue around the Product Owner attending the sprint retrospective. This ceremony reflects the principle that "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

We can infer from the principles above that the Product Owner is indeed supposed to be an integral part of the team. If we also expect that team to regularly reflect and adapt through the Scrum ceremony of the sprint retrospective, then it is easy to conclude that, yes, the Product Owner is meant to participate.

Why is This Still a Debate?
So if you follow my reasoning above and concur that the Product Owner is meant to be a member of the Scrum team and attend sprint retrospectives, why is this still something agile teams are struggling with?

I find that many organizations struggle with the role of Product Owner, period. They often put people in the role who are not truly empowered to act for the business stakeholders. Sometimes they may put an actual business stakeholder in the role, but they will have competing responsibilities that constantly drag them away from the team.

When this happens, the Product Owner role becomes diluted and stops reflecting the agile values and principles it is supposed to embody. They no longer work with the teams on a daily basis or they cannot truly represent the business stakeholders and become a mere order taker.

The more abstracted from the team they become, the less they are collaborating, and the team will struggle to self-organize around efforts such as gathering requirements. While this can happen on any team, it can be more prevalent in larger organizations where the sheer size and number of teams requires more distributed management. This can easily lead to a certain detachment from the Scrum team for the Product Owner.

When the team feels the Product Owner is not fully integrated into their daily process, then it starts to seem reasonable that they would not be involved in the activities to inspect and adapt that process.

In addition to feeling like the Product Owner should not have much influence into their processes, the Scrum team may also feel a lack of trust that would dissuade this as well. When the Product Owner is farther away from the team and does not have a good understanding of what they do, they tend to make more unrealistic or uninformed demands.

This situation can easily cause friction between the two, and if the Scrum team feels like they cannot openly discuss these issues in a retrospective because of the Product Owner’s involvement, we start to lose out one of the best aspects of agile.

So, Are They a Member of the Scrum Team or Not?
In my opinion, there is no debate that in Scrum, the intention is that the Product Owner is an integral part of the Scrum team. If, in your experience, you feel this not to be true, then I ask you to think about what reasons you have for feeling that way.

What factors are leading you to not want your Product Owner to be in your sprint retrospectives? Investigate those reasons and try to fix the underlying issues to get the team to a place where they would feel completely comfortable with and absolutely want the Product Owner there.

Rather than blindly sticking to a rule one way or another, understand the values and principles behind it, and figure out how better to implement them. Rules are meant to bend, evolve and sometimes even break, but the values behind them will rarely fail you.

To learn more from Tommy, check out his online courses on "Scrum Fundamentals" or on "Advanced Scrum: Requirements Management and Quality Assurance."

Agile Teams: When is an Impediment Just a Complaint?

In Scrum we often talk about impediments: Scrum Masters should remove impediments; team members should raise impediments at the daily scrum; and everyone should make impediments visible, to help get them solved.

Physical impediments are easy to notice and quick to solve. Things like getting hardware for a build server, or getting a whiteboard in the team area.

Other complex impediments like regular production stability issues, or long automated build times are more difficult to solve. They require root cause analysis and a multipronged approach. Often, they are even difficult to identify because people have become so accustomed to them, they no longer even see them as a problem.

What about an organization's cultural impediments?

Recently, we brainstormed impediments with a group of new Scrum Masters at a large corporate organization. Here are some of the things they listed as major impediments:

Some stakeholders are resistant to agile There is a lack of support of agile from management The team lacks the authority to get other departments to work with them The Product Owner tries to control the team too much At first these might look like reasonable impediments. But take another look. Imagine you are the team’s manager or Product Owner, and read them again.

Don’t they sound like the team is complaining? Every one of these "impediments" is about how someone else is the problem.

Can you imagine what might happen if the team made these impediments visible on a whiteboard? Most likely it would create conflict and damage some relationships.

So what can you do instead, if these sound like impediments you have?

Make sure you understand if there is a real impediment to the team, or if people are just complaining Phrase the problem neutrally, without blaming anyone Gather concrete examples and data about how this problem impacts the team Look for solutions for what the team can do to reduce the impact, and ask for help from others to solve the problem together Let’s take the following impediment as an example: “There is a lack of support of agile from management.”

In this case, the team felt this way because the Scrum Master role was not considered a full-time job by management.

The real impediment here is that the Scrum Master role is new in the organization, and therefore not well understood or full time.

The impact to the team is that they skipped their last retrospective because the Scrum Master was too busy with other work to prepare for the retrospective.

As a result, the team did not have an opportunity to discuss a process that was not working for them, and they continued to use this process, causing delays, miscommunication and rework.

Given this impediment, there are a number of actions that can help. For example:

Have the Scrum Master keep a journal of everything they do for a week, and share that in a learning session with others to spread awareness about the role Agree as a team that if the Scrum Master is too busy, someone else on the team will prepare and run the retrospective Run an agile training session for managers to explain the roles in Scrum and why they are important Ask management to try an experiment of allowing one person to be a full-time Scrum Master for 3 months, and assess at the end how it worked Google the problem to see how other companies have solved this Now imagine if I made this impediment and the action ideas visible? Do you think I am more likely to get support?

Going forward, when talking about impediments, and making them visible, focus on the problem and the impact, rather than blaming someone for them. You might be surprised how much easier that makes them to solve.

Remember that there is always something within the the team's control that can be done to help remove the impediment.

Agile Transformation: Tips for Organizational Change

Jason Little describes his career as helping organizations "discover more effective practices for managing work and people." He is the author of the book, "Lean Change Management: Innovative Practices for Managing Organizational Change," a speaker, agile coach, Certified Scrum Professional, ScrumMaster and Scrum Product Owner. 

In this interview, Jason reveals what to watch for when trying to implement agile into an organization -- especially in larger companies that value control and stability. Here, we'll dive into the concepts featured in his course on Front Row Agile: "Agile Transformation: Four Steps to Organizational Change." 

In your course at Front Row Agile, you talk about the idea that understanding your organization’s culture is a good start, but it may not be a good idea to intentionally try and change it. Why is that?

Jason: Despite the agile community’s consistent message that agile isn’t a quick fix, it’s still perceived as being one. The pace of change, disruption and innovation is constantly increasing, and agile isn’t going to undo years of cultural baggage and organizational debt in a short time period.

I mention it’s a good idea to understand what your culture is because it’s important to pick an approach that is more likely to work. That means in a “control” culture that values structure and stability, you may want to start with considering agile to be a new process. 

What I mean by that is approaching an agile transformation in this type of environment by leading with the agile values and principles might be perceived as “fluffy,” and it may turn people off. 

In this environment, people might need a bridge built between how their processes work today and what they might look like tomorrow. For example, larger organizations I work with have more governance in place so developing an “agile governance process” can be a good short-term strategy for people to figure out how to move forward. 

After they’ve seen how what they do works in an agile environment, then more focus on agile values and principles might be a good approach. 

You teach different options for how organizations can learn about what agile means before they get started. Can you elaborate on that?

Jason: Back in 2007 when I started with agile, there weren’t nearly as many options as there are today for learning about agile methods. I still see organizations using only training and certification as a way to learn about agile, which is one of many ways to get educated about agile.

The agile community has grown substantially since 2012, and there are numerous conferences, meetings and virtual learning opportunities.

One of my favorite education tools is to send people to agile coach camps of which there are many around the world. That is a great way to connect people in the organization to experienced agile coaches that they can learn from.

You stress the importance of retrospecting often in your course. How can larger organizations use this technique at scale?

Jason: I recommend conducting retrospectives at the team, management and organizational layer; this helps get people focused and aligned around the purpose behind transforming to agile in the first place.

I recently used that technique with an enterprise client. Their team wanted to know the answer to one question: After a year, do we want to keep going with agile?

I coached the internal coaching team lead on how to do a large-scale retrospective for 30+ teams, management and executives. The short version of the story is that the answer to the question was yes. Even with all the problems and pain, they wanted to keep going.

The interesting part of that exercise was how it was executed. I worked with the internal coaching team lead on how to do the technique, and she then coached the existing Scrum Masters and Kanban team leads to do that exercise with their teams. 

This way, there was no single bottleneck. We took full advantage of a network of people, and then the coaching team lead took all the data from the teams and compared it with the data from the manager and director retrospectives.

She found it to be a great deal of work, but well worth it in order to see where staff, management and executives were aligned or misaligned.

“Scale” often scares people, but it’s not difficult to do large-scale retrospectives. It simply takes a little more planning and coordination. 

Organizations often lose sight of how their journey towards agile is going because they get too caught up in the day-to-day challenges and organizational problems agile is exposing. Taking the time to stop and reflect shows a serious commitment by leadership to helping make agile work.

For more info from Jason or to get in touch, head on over to his website.

How DEEP is your product backlog?

All good Scrum teams need a good product backlog, but how do we know if ours is up to the task?

“DEEP” is a handy acronym developed by Mike Cohn that describes the ideal attributes of a high-functioning product backlog. If you find yourself drowning in a huge list of stories, then DEEP is a great way to start digging your way back out. 

Let’s take a closer look at each of the criteria to get a feel for how it will work on our own backlogs.

Detailed Appropriately
We want the stories near the top of the backlog, which our team will be working on next, to be well defined enough that the team can be productive with them as soon as they pick them up.

A good indicator of this is that the stories near the top of the backlog are smaller and more fine-grained, but become progressively larger and less specific as we start to move down.

Estimated
Each item on the backlog should be estimated ‒ even if it’s only a rough estimate. This helps us prioritize each story against the others and also helps us project completion dates for each batch of work.

But, since the stories at the top are better defined than those at the bottom, we accept that the estimates will become less precise as we move down the backlog.

Emergent
The product backlog is not a fixed object. It is a living document that evolves over the course of the release. We should expect the items in the backlog to change priority, new ones to be added, and even some to be removed.  

As we progress through the release and learn more about the needs the product is trying to solve, the product backlog will evolve to reflect this knowledge.

Prioritized
Our product backlog is prioritized with the most important items at the top, and the least at the bottom. This ensures that the team is always ready to work on the most important item next. A good rule of thumb to help us know if our backlog is prioritized appropriately is to walk down the backlog and imagine that our product is suddenly shipped – including only those features above the line.

If we’re not happy with the features that were shipped or if there were other features that we wish had been included instead, then we need to re-prioritize our backlog.

Looking Through the Lens DEEP
DEEP is an incredibly powerful tool for helping us tune our product backlog and keeping it in shape. Much of its power lies in its simplicity; not only is it easy to remember, but also we can apply the criteria to our own backlogs in a surprisingly quick amount of time.

If you’d like to see DEEP in action, or learn more about how to create and maintain a great product backlog, check out my course, "Agile Release Planning," which is available now on Front Row Agile.

Creating Comfortable Workspaces for Agile Teams

Ilan Goldstein is an agile practitioner and thought leader based out of Australia, perhaps best known for his tips on "Scrum shortcuts," a compilation of ideas that became the basis for his published book: "Scrum Shortcuts Without Cutting Corners." 

Ilan talks a lot about the Scrum startup, and the elements that go into making Scrum adoption successful. At the foundation of this is team morale, and he believes that team dynamics and workspaces are the cornerstone for productivity in agile development.



In a field that often casts its professionals into lightless caves in order to toil away in solitude (often by the request of the developers themselves), Ilan argues this isn't always best for the Scrum team. We caught up with Ilan in this interview to hear more on his thoughts around creating a work environment that makes Scrum work better.



With new Scrum teams, how do you help shift the mindset from individual accomplishments or goals to doing what's best for the team?

 

Ilan: It really is incumbent on the business to communicate and reinforce what is truly important - the creation of quality, working products that delight customers.

Simply put, a product is not built by an individual, it is built by a team. As such, it needs to be appreciated that individual accomplishments are the building blocks that make up the overall team accomplishment; they are a means to an end. 



No doubt, the individual building blocks are still important but it is critical that they are all aligned and supporting one another to create something much bigger and more important then the blocks themselves.



You talk about the physical workspace impacting the Scrum team. Can you expand on that a little here?

 

Ilan: First, let me say that I couldn't agree more with the truism, "It's the small things that matter." You'd be surprised by how many retrospectives I've witnessed that have been dominated by concerns and complaints about the physical environment.

Whether it's a lack of meeting rooms, limited wall space or microwaves that were bought when Reagan was in office, these day-to-day annoyances can really drag on morale and lead to direct and indirect productivity loss. 



Some of the best environments I've seen haven't necessarily been slick, extravagant settings decked-out with multi-million dollar fittings complete with slippery slides and lava lamps. No, in fact, they've actually been rather economical and grungy; however, they got the basics right and in turn became super-productive yet really comfortable spaces. 



Now if I was to choose one key consistent element of the worst environments I've seen, I would say the least optimal environments are those that impose email as the primary method of communication. This imposition may be due to physical or cultural boundaries but irrespective, relying on an asynchronous and easily misinterpreted communication channel is not conducive to effective teamwork.



What are your tips for changing the way Scrum team members interact with one another if it's a less than friendly environment? 
 


Ilan: My solution to this problem is to avoid it in the first place. So how do you do this? Well, you hire the right people with the right attitude and you model the behavior that is expected.

I worry about trends in our industry where the focus is on hiring "rock stars" with a total focus and emphasis on technical brilliance as opposed to interpersonal brilliance. The latter brings out the best in others and will ultimately lead to happier and more productive teams.

For more from Ilan, check out his course on Front Row Agile: Scrum Shortcuts