Teaching Social Intelligence and How It Relates to Agile

Being an agile trainer, I’m always interested in new techniques in teaching, and one of the blogs I subscribe to is that of Georgia teacher, Vicki Davis. Davis is not an ordinary teacher, however. She uses project-based learning and technology designed to teach compassion and empathy.

I listened to a presentation given by Davis at the “Education: Next Generation” conference titled, “Using Projects to Teach Compassion and Technology.”

I was particularly interested because soft skills are not typically taught in a classroom, yet skills such as social intelligence and emotional intelligence are particularly important for success in agile environments.

These are the types of skills that are so important for agile leaders, yet it seems that they’re rarely taught in the classroom.

Davis, author of the book, “Flattening Classrooms, Engaging Minds,” and podcast, “Every Classroom Matters,” teaches her students to become “social entrepreneurs” by tapping into their “heartbreaks,” and helping them to create apps that will do something to help address those heartbreaks.

“What are the things that break your heart and why? How can we do something to address that heartbreak?” are questions she asks her students. “It’s a great technique to get kids excited about their opportunity to change the world,” she says.

The kids have created apps to help with issues such as human trafficking, cutting and cancer.

The apps can be found on the site,, and not surprisingly are developed using agile and lean techniques, including Kanban.

In her talk, Davis talks about several concepts that we teach in agile management classes, such as empowerment, the growth mindset and capitalizing on the strengths of individuals.

Though Davis is empowering and focusing on strengths of students, she pointed out the importance of these skills in the workplace and that if bosses focus on the strengths of their staffs, studies have shown a dramatic increase in employee engagement.

Another parallel to agile teaching was Davis’s emphasis on the importance of conversation.

“It’s the conversations that change everything,” she says, giving examples of times where conversations between teacher and student can set the trajectory for growth, confidence and self-esteem that will lead students to meet their full potential knowing someone believed in them.

Davis talked about the importance of ensuring everyone had a voice in conversations, reminiscent of what we teach Scrum Masters.

She uses Socratic dialog, teaching with questions, but uses techniques to ensure that it’s not only the extraverts who are speaking up.

One way she does this is by giving students three poker chips. They use a poker chip when they contribute to the conversation, but once their chips are gone, they can’t speak until everyone’s chips are gone.

This puts pressure on the quiet ones to use their chips by speaking up. Though this may take them out of their comfort zone, Davis has found that this technique has exemplified that everyone has something to bring to the table.

Another skill Davis teaches her students is how to “professionally disagree.”

In talking to them, she will sometimes say something that she knows the student doesn’t agree with to see if they will challenge her. If they don’t, she’ll talk to them about why they didn’t speak up, and they’ll often answer that they didn’t think it was appropriate to disagree with the teacher.

She’ll then go on to teach them how they can respectfully speak up when they hear something that they disagree with. She wants the students to question. If something doesn’t make sense, ask why?

It’s encouraging to hear that Davis is teaching skills beyond the traditional, but really delving into these areas of social and emotional intelligence.

These students will become future leaders who will lead with empathy and compassion.

Already, these students are making a difference with the apps they are creating. For Vicki Davis, she finds meaning in helping the students make that difference.

Learn more about her teaching methods here:

Vicki’s website – Cool Cat Teacher Mad About Mattering website

3 Agile-Friendly Ways to Say No to Feature Requests

I recently interviewed a product manager from a well-established company. I was curious about how they handled feature requests and asked if there were ever times when the PO needed to say no to feature requests. I was floored with his reply: “No,” he said. “I prefer not to work at a company where we say no to requests.”

Sounds nice, right? Unfortunately, good product management means saying no frequently, and every agile team should know that regularly rejecting feature requests is an important part to creating a sustainable, effective product.

After all, one of the 12 principles of agile software says, “Simplicity--the art of maximizing the amount of work not done--is essential.”

To illustrate why saying no is actually a crucial aspect of agile best practices and to provide helpful ways to rationalize rejection, here are three common examples of when a good agile practitioner should reject a feature request.

Scenario 1: The Feature Request Serves Only the Loud Few

Your restaurant customers in Maine are asking for a system-wide alert any time there’s a lobster shortage. Everyone needs to know when it’s time to start hoarding lobster, right?

Well, if your product is serving the entire United States, most regions don’t have a lobster-heavy restaurant industry, and Maine only represents 0.42 percent of the country’s population. You might instead want to build a feature that serves both Maine and the rest of your customer base.

Ways to address:

Check with a larger sample size of customers Check the value of the customers—are they customers you can’t afford to lose? Or users who signed up for a free trial and aren’t paying? Check to see if the change could negatively impact customers who didn’t request it Opportunity cost: Bust out the microeconomic theory. Are there other features in your backlog that could deliver more value to more customers?

The agile angle:

Simplicity is essential Deliver more value with features that benefit more users, or more valuable users Scenario 2: The Feature Request Does Not Scale

A feature request comes in that requires you to set up a new public API with a huge volume of constant API requests. Your servers can handle it for the first few pilot customers, but if you try to roll it out to all of your current customers, your API service will be overloaded with requests. Your colleague asks you to add more server resources and a dedicated team to support the API, but customers aren’t paying anything additional for this service. The feature request does not scale, and if no one is willing to pay for the feature, chances are it’s not adding enough value.

Ways to address:

Ask your team to envision or simulate rolling the feature out on a larger scale. If it succeeds, can you afford to sustain it? Ask for proof of concept that shows the customer truly values the feature, i.e., they’re willing to pay for it or it’s needed to reduce customer attrition

The agile angle:

Agile processes promote sustainable development Scenario 3: The Feature Request is in the Contract, So it Must be Done

Your client asked for a feature and is ready to pay you to build it, so you should definitely build it, right? Actually, the customer might not know that there’s a better solution that could save them time and cost, while also delivering additional value.

As the agile practitioner, it’s your responsibility to collaborate with the customer to inform them if you believe a feature will not deliver value to them or if there’s a faster, more valuable, or more sustainable way to satisfy their user story.

Ways to address:

Take a few minutes to see if there’s an obvious solution that’s stronger Don’t stay silent, inform the customer of potentially better solutions and explain how it would deliver more value to them in a shorter period of time If necessary, explain to them why adapting to a better solution is usually better than sticking to a weaker original plan

The agile angle:

Customer collaboration over contract negotiation is one of the four values of the Agile Manifesto Responding to change over following a plan is another core value of agile An agile-friendly customer should value collaboration and responding to change, especially if they’re internal to your team or company Delivering more value on a shorter time scale is consistent with agile principles Conclusion

Regularly reflecting on how to become more effective as a team is yet another agile principle we should all adhere to.

Think about your own pursuit of being an efficiently functioning agile team. Do you find yourself saying no to feature requests periodically? What are some of the most common cases for you, and how do you address them in a way that’s consistent with agile best practices?

Let me know in the comments below.

How to Create the Minimum Viable Agile at Your Organization

We can probably agree on some of the things that agile is, but then either you or I would say something like: “And I also think agile is …” and offer some additional interpretation of what it means to be agile.

Because of this, a number of different agile methodologies exist. There are also many different values, principles and practices associated with agile.

The concept of a Minimum Viable Agile (MVA), that is, the bare minimum needed to say you are agile, isn’t really new. The Nokia test, first developed by Bas Vodde and later revised by Jeff Sutherland, is an example of this thinking. Many other checklists and assessments on whether or not you are agile exist, so the concept of an MVA seems to be interesting to many.

But why is it beneficial? And how do you create it?

Why the MVA is Beneficial

 The MVA would probably have the most benefit for teams or organizations getting started on the agile journey. Being in an early stage, you can easily get overwhelmed by all the different values, principles and practices of agile.

Defining the MVA could be one of the first steps towards a goal of being agile. The MVA could then be used to map the gaps between how the team or organization operates, and how it should operate to be more agile. Having an explicitly defined MVA will make it clearer which changes should be made and what kind of training is needed.

Having an MVA could also help experienced teams and organizations that have been through these transformations with a baseline of agile to fall back on, should they at any point go the wrong direction concerning their agility. 

How to Create the MVA Creating MVA Based on the Agile Manifesto

A somewhat natural approach towards an MVA would be to follow the Agile Manifesto and use those values and principles as the basis of your MVA. After all, adhering to the values and principles behind the manifesto surely makes a team agile by definition, yes? 

While this could be true, there are some problems related to this approach.

One challenge is that the written values are too vague to translate directly into actions. If you value individuals and interactions, how do you decide if a team adheres to this? The same goes for responding to change—how do you know if a team values this, and to what degree is it followed?

You could probably find some metrics to measure the adherence to the values to some extent, but it is doubtful you will find any specific unambiguous metric to capture this.

It would be great if the principles of the manifesto provided context-specific guidelines for implementing practices based on the values, but the manifesto doesn’t directly prescribe any practices.

What seems like a downfall of the manifesto is actually one of its stronger points. The power of the manifesto lies in its open to interpretation, which leads to agile being more of a mindset than a set of practices.

Therefore, an MVA directly based on the manifesto might prove to be difficult. Also, the manifesto in itself is meant as a living agile document, in that we should always be looking for better ways to make software—not limited to the content of the manifesto as it was written 15 years ago.

So somehow your MVA must reflect this as well.

Creating MVA Based on Existing Agile Practices

Another approach towards creating an MVA for your organization could be to look at all the different agile methodologies and actionable practices from these.

All the methodologies have a slightly different implementation of the core values from the manifesto, so whether your approach is based on Scrum, XP, a Scrum/XP hybrid or a Kanban approach to software development, the idea is to pick just the minimum of practices that makes you agile and call that your MVA.

The challenge is, as mentioned before, that agile looks different to different people. Because of this, there isn’t just one agile methodology.

There are different methodologies with some overlapping practices, but since the creators have slightly different interpretations of what agile is, they also have some non-overlapping practices. As an example, neither Scrum nor Kanban prescribes any of the technical practices from XP. However, often a lot of these are implied when using both Scrum and Kanban.

If you look at the results of the latest State of Agile survey, technical practices like refactoring, pair programming, TDD and collective code ownership are among the least used agile practices. Non-technical practices like the daily standup, prioritized backlogs, short iterations and retrospectives are among the most used practices.

With only 1 percent of respondents saying their agile implementation failed, the problem then becomes which practices to choose as our MVA, given that agile implementations seems to succeed even without technical practices like collective code ownership, TDD, refactoring and pair programming.

My MVA is Different Than Your MVA

The fact is, all teams have different preferences, and the context in which various teams work are not the same. So maybe a generic MVA that we all would agree on isn’t really feasible. A custom MVA for individual teams or organizations that is periodically revised or improved is probably more realistic.

Personally, I don’t think it’s important if there is a single, generic MVA, as long as the teams or organizations are aligned and have a shared and evolving understanding of their own MVA. As long as value delivery is maximized, it shouldn’t matter either.

Do you have an MVA? Share with me in the comments below.

How to Be a Successful Member of a Scrum Team

“Excellence is the gradual result of always striving to do better.”

-Pat Riley, NBA Executive and Former Coach and Player

While watching agile adoption continue its move into the mainstream over the last five years, I can’t help but think what a marvelous time it is to be in software development. Having worked with a number of Scrum teams as a Scrum Master and now as an agile coach, I’ve seen firsthand the opportunities that opened up for developers, testers, designers and others to become more than they may have thought possible—because for the first time in their careers, they are empowered to be more.

However, every opportunity comes with responsibility, and how well you perform will dictate your level of success. Over the years, I have observed the various commitments that Scrum team members take on.

In this post, I’m going to share with you tips on how to be a successful member of a Scrum team. As you read this, take note of how all the various components of the Scrum framework are interconnected, and provide subtle checks and balances that will aid you in becoming a successful Scrum team member.

Backlog Refinement

Backlog refinement is an ongoing story grooming process that periodically occurs during the sprint cycle. This where the product owner may ask you and other teammates to participate in a refinement session where you will work on a group of stories designated for future sprints.

Your objective will be to use your combined technical expertise to work with the product owner to refine these stories, so that:

The business value is understandable The acceptance criteria is appropriate, specific and measurable The work is doable by the team within a sprint cycle

It is in this process that you actually take part in shaping the future work to be done by you and your teammates. How well you perform your responsibilities can affect your sprint planning.

Sprint Planning

During sprint planning, the core team will plan out its work for the upcoming sprint, which is most commonly a two-week sprint cycle. How well the team conducts its planning will greatly impact the team’s performance in the sprint.

The first item addressed in planning is team capacity. Team capacity is defined as the amount of real time that can be committed to actual sprint work. It excludes vacation, training, meetings, other administrative or operational work, and it also takes into consideration the fact that estimates are good faith estimates and not certainties. The objective is to plan the team’s real capacity based on each team member’s availability during the sprint in order to support a sustainable work pace. So you need to be accurate in estimating your availability. The second item in planning is to discuss the stories brought into the sprint backlog so as to ensure the team has a shared understanding of the work to be done. The team will then break down work for each story into tasks (with estimates in hours) that addresses the stories’ context and acceptance criteria. The task hours are based strictly on team member estimates. The third item in planning is to finalize the number of stories for the sprint backlog based on the stories’ total task hours for the sprint. Should the total hours of the sprint backlog exceed the team’s capacity, the team along with product owner will need to decide which story or stories will be removed from the sprint in order to bring the total story tasks hours in line with the team’s capacity. The final planning item is for the team to conduct a review of all the stories and their tasks to ensure all the necessary work has been addressed, and perhaps have a brief discussion on the team’s work strategy for the sprint.

Sprint planning done well is all about the team taking time to plan for success. Remember that you and your teammates are making a commitment to accomplish this work during the sprint.

The Sprint

One of my high-performing teams often referred to the sprint as the “Quarter Mile.” This was a reference to a movie quote from the Fast and Furious movie franchise where the main character stated that he lived his life a quarter mile at a time.

When I asked for clarification, they stated that all the preparation and planning that the team had done has been for one thing and one thing only: the sprint. And once the sprint starts, you are working and living within the moment—the “Quarter Mile.”

These particular Scrum team members were successful with sprints because they:

Focused only on what needed to be built or accomplished during the sprint cycle Leveraged automated test driven development to improve unit testing and code quality Didn’t wait if they ran into problems; they escalated them immediately and also adjusted their work strategy to continue moving forward Understood the iterative process, and built only to the story’s acceptance criteria, even though it’s not the finished software product Delivered completed stories throughout the sprint cycle, rather than delivering the majority of the stories at the end; this allowed them to make corrections when a story was initially rejected by the product owner and get it fixed and accepted within the same sprint Used pair programming to partner some team members in every sprint as a part of the team’s own cross-functional development goals

I found this paradigm of living in the moment and working only in the here and now to exemplify a core team’s lean and agile mindset when in the sprint. They were not working harder than any other team, but they were working smarter, which allowed them to produce results at a sustainable pace.

Daily Standup

During the daily standup, each team member briefly talks about what they accomplished yesterday, what they’re planning to do today, and what, if any, blockers are preventing them from completing their work.

But the standup is more than a status report, it’s about keeping your fellow team members informed as to what is happening with you (especially if you need help) so that they can adjust and coordinate their day’s work as needed.

Even though the Scrum Master and product owner may be present, you are primarily communicating to your teammates, so talk loud enough so everyone can hear, and be specific in terms of identifying the stories and tasks you are working on as you move them on the board.

Prior to every standup, every team member should have reviewed the board and asked themselves: Are things going according what we planned during our sprint planning?

If not, the team should set aside time after the standup to discuss the concerns and adjust their work going forward. The standup is your primary tool for self-managing as a team during the sprint.

A final note the on the standup: if you cannot attend the standup, you should send an email to your teammates addressing what you would have said if you had been able to attend.

Sprint Review

The sprint review primarily falls under the purview of the product owner. The purpose of the sprint review is to demonstrate working software and obtain customer feedback, which in turn may result in creating additional stories in the product backlog.  

As a core team member, you may be asked to participate in a sprint review to demo a specific piece of software. Here, it is important to remind yourself who your audience is. That audience is usually low-tech, and comprised of the customer and/or managers who have a business-specific need.

So the conversation you may have with your fellow techies regarding the challenges you face building the product is not the same conversation you want to have with this audience. The fact that you are demonstrating working software is a testament to your technical proficiency as far as the audience is concerned.

So it is important to focus your conversation on the business value of what you are demonstrating, because that is why everybody is there. Demonstrating a working solution that solves a customer’s need is what will really impress this audience.

Sprint Retrospective

At the end of every sprint, the team will come together to reflect on the performance during the sprint. This environment is designed to be a safe and blame-free, where the team shares all responsibility.

The focus is not on the individual, but on process and execution improvement. The goal is to objectively learn what the team did well and where they need improvement. I would also suggest that you include the team’s cross-functional training goals as a topic for discussion.

Once this is accomplished, it is incumbent upon the team to select one or two items for improvement and then commit to instituting the necessary changes to the process or execution in the upcoming sprint, and reviewing the results in following retrospective(s).

The retrospective is your tool for continuous improvement and growth as a team, and will hopefully provide the team new ways to inspect and improve how they work together.

On Conflict

Core Scrum teams—even great ones—will experience conflict at times. It’s a given due to the intensity of working together day after day. But, great teams whose members respect, trust and value one another will always try to address conflict in a constructive manner and find ways to move forward.

Being a Successful Scrum Team Member

To be a successful member of a Scrum team, you will need to think beyond your technical area of expertise to be actively involved in a self-organizing and self-managing team.

On occasion, I hear someone remark about someone else’s success in a way that makes it seem it was happenstance: “Yeah, he’s successful, but he just happened to be in the right place at the right time.”

This may be true, but only in rare cases.

I believe that most people who have excelled in their careers are individuals who were prepared and committed to taking full advantage of opportunities presented to them. The same thing can be said for high-performance Scrum teams.

With empowerment, comes responsibility. And every Scrum team member has great responsibility to his or her fellow teammates. Fulfilling those responsibilities will make you a successful member of a Scrum team.

The Retrospective Meeting: A Golden Opportunity to Learn

In 2007, just before my first encounter with Scrum, I went to a lessons learned workshop as the test manager for a multinational company implementing a global technology and corporate change program.

By this time, I had attended many lessons learned workshops, which often took place at the end of projects, as a way of learning from the past project and improving the next. I enjoyed these events as they were an opportunity to work with the whole team to look at and solve all those day-to-day problems that prevent large complex implementations from succeeding.

I was often excited by lessons learned opportunities, but I was particularly looking forward to this one, since it was taking place midway through the project, and there was a chance that much-needed change would be implemented.

We workshopped away for a couple of hours and ended up with a stack of issues that needed solving, all clearly visible on a very large wall. The session had been productive. At this point, the program manager stepped up and announced rhetorically: “Well, I don’t think there’s anything there that we don’t already know!” And then he closed the meeting. We just shrugged reluctantly and went back to our jobs.

That meeting cost several thousand dollars. What did I learn? That leadership was not listening to its teams. What did the teams learn? Nothing that they didn’t already know. That program did not fare well.

Then I Found Scrum …

I was excited when I was introduced to Scrum and the Agile Manifesto shortly afterwards, since continuous learning is not just encouraged, it is essential.

Sure, learning is essential in a waterfall program, too, but the beauty of Scrum is that it makes it achievable by:

Working with small teams so that shared communication is optimal Embedding frequent inspection into the framework through the daily scrum, review and retrospective

When you’re working with a team to get stuff done, being able to adjust and adapt to not only changing circumstances, but also your own internal team dynamics is pure gold. It is one of the behaviours that make a team great.

How Scrum Facilitates Learning Lessons

The Scrum framework gives the team a sprint goal and empowers them to deliver it. The team is therefore invested in learning about itself.

Because of the daily scrum and the close-knit working relationship of the team members, external impediments are quickly identified and raised, so don’t become “lessons learned” flotsam.

The desire to deliver something of value and put the goal of the team first enables individuals to negotiate “personal preference” impediments. These are the impediments that we all bring to any team we join, and are simply our personal preferences for ways of doing things.

Having a clear team goal helps us to put these to one side when we need to and/or negotiate a shared way of working. In this way, the team culture develops.

The Scrum Master, by practicing servant leadership can support teams and invite them to act as servant leaders to one other. The retrospective is a good event for developing this skill.

The Retrospective is a Gold Mine … But Not Everyone Sees It That Way

The retrospective acts as a container in which a team can influence the next sprint by looking at the last one. It is an opportunity for team members to support and acknowledge one other by reflecting on the good work they have done, and their ability to adapt and find creative solutions.

In a positive working environment such as this, issues and difficulties are more easily resolved and can make the retrospective enjoyable, interesting and productive. Conflicts will naturally occur, but in a culture of mutual respect, they can be resolved openly and for the good of all.

However, I have known Scrum teams to discard the retrospective on the grounds that they already know what the problem is, and believe they would make better use of the time in working to deliver more features, especially since they have not delivered much in the last sprint (or two). This is a team that has lost its way.

The following scene is based on a version of real events …

Enter the Scrum Master.

Scrum Master: O Team!

Delivery Team: Yes, O Servant Leader?

Scrum Master: Have you forgotten that if you do not do Scrum, you are not doing Scrum?

Delivery Team: Go away, for we are busy!

Scrum Master: But what is the sprint goal towards which you strive?

Delivery Team: Um…

Scrum Master: Ah, let us retrospect and entreat the product owner to share their vision so we may be enthused and therefore desire to make it so.

Delivery Team: OK, but the product owner is busy and wants us to just get it done.

Scrum Master: Fie!* Let us retrospect all together as one Scrum team and reflect on the importance of the energizing goal.

*interjection, used to express annoyance

In the past 12 months, I have worked with a number of teams that have been introduced to Scrum and retrospectives for the first time.

And one question I have posed is: “How do we know when we have learned a lesson?” After all, saying that you have learned something is one thing; changing a working practice or behavior is quite another. Change often occurs incrementally. So how can a Scrum Master facilitate this process?

How to Get the Most From Retrospectives

A Scrum Master can help by supporting the team to create its own team charter—becoming a great team is not an accident or coincidence; it needs to be a conscious decision.

The team charter is team created and co-owned by every member. It defines the behaviours and ways of working that will help the team grow and work together. By setting this vision for itself, the team creates something it can reflect on in a retrospective, not as a way of punishing itself for failure, but as a way to honestly look at how it has lived its own principles during the last sprint.

With a clear sprint goal and team charter in place, the retrospective will be a rich source of ongoing learning.

In time, retrospective behavior and thinking can become a part of the daily work: Not everything needs to be saved for the retrospective; equally, not everything can be resolved on the spot.

What I like to do is create an area on the Scrum board called “retrospective,” where team members can stick a note when something occurs to them that may not be an immediate problem, but a creative way to improve the team’s delivery capability. We then review the notes in the retrospective and work with the ones that are still resonant.

This can remove the pressure on team members at retrospective time, as they won’t spend so much time furrowing their brows trying to remember that thing that happened.

Another light touch technique is to get a large white board, draw a horizontal line across the middle, put a vertical start point far left and a vertical finish point far right.

The distance between the two points represents the sprint. The y-axis represents “level of activity”; the top is “frenzied activity,” the bottom is “nothing, zero, zilch.”

Now, ask each team member the draw a line from left to right over the life of the sprint that shows their level of activity as the sprint progressed (different colours work well).

It’s fun, and when done, there is a clear pattern that the team can see. Often the team will annotate sudden plunges or spikes. This technique can be a good place to start if you have a team that often inflicts three days of frenzied activity on itself at the end of every sprint.

In sum, I’ve been through many variations of “lessons learned” meetings throughout my career, and this is what I have learned so far:

Some lessons have to be learned many times. Some lessons are learned quickly, some slowly, bit by bit. Some are never learned. But, the most important lesson of Scrum, for me, is to challenge the team to take responsibility for its own development by creating a charter, trust it to live those principles and remind it to reflect on them at the retrospective meeting.

How to Use Team Resistance to Reach the Agile Mindset

Agile relies to a great extent on the team and how team members interact with one another to achieve the expected goals. There is no simple formula or “golden rule” for building a high-performing agile team, but a combination of activities and tools can help achieve this goal. Even in the face of resistance, an agile mindset can be cultivated.

Building an Agile Team is Different

One of the most challenging activities for any leader is to build a high-performing team with members that work together in harmony. In “Developmental Stages of Small Groups” and “Stages of Small Group Development Revisited,” Bruce Tuckman finds that teams go through five phases of development:

Forming Storming Norming Performing Adjourning

To reach the “performing” phase, a lot of effort is needed by the leader to make the team members understand each other’s work habits and create a synergy among them.

When working with an agile team, we can recognize that there is more effort needed by the agile coach or Scrum Master. In addition to helping the team evolve through the common development phases, team members should be trained to change their mindset to think and act in an agile way.

When a team achieves an agile mindset, it can work independently with minimum coaching or guidance.

This last step is as difficult as--if not more difficult--than the other team development phases.

Also, this last step is usually the phase where the team develops most of its resistance, because of the tendency to focus on solving technical riddles rather than delivering business value.

There are several tools that a coach or a leader can use to overcome this resistance, and help the team acquire the proper agile mindset.

Team Resistance

When a development team is in a performing phase, the developers gain more confidence in themselves and feel that they need less coaching or guidance—or sometimes none at all. This excess confidence might lead in many cases to an increased resistance to the coach’s advice to develop an agile mindset.

So what should an agile coach do when a team decides to make a move that the coach believes is anti-agile?

Before proposing solutions, the agile coach should keep in mind that this situation has both positive and negative aspects ...

Positive aspects:

You have a good team that can agree on a single decision The team is in the performing phase, because they are confident and trust one another They are demonstrating dedication; from their perspective, it is better for the project to do it their way 

Negative aspects:

The agile mindset is not yet there How to Use Team Resistance for Coaching

Of course, the first action should be to show the team the drawbacks of such a decision and how it would affect the deliverability or the consistent pace of the team, which eventually would have an impact on the product.

But what do you do if they insist, and the product owner is supporting the decision, hoping to gain the development team’s trust?

Here are some tips that might help, but should be executed carefully to avoid backfiring:

Agree with their decision even though you believe it is wrong If there are consequences to their decision, let them experience them until the end of the experiment, whether it takes one sprint or more (but I prefer to limit it to one sprint to be able to repair the damages as soon as possible) At the end of the experiment, hold a special retrospective to reflect back on the results of the experiment and the pain (if any) they went through During the retrospective, make it clear that there is no blaming (Rule No. 1), only learning; without a proper retrospective that focuses on learning rather than blaming, they might lose their confidence, so you must be careful when using this technique Since it was a decision that was driven by lack of agile experience, they should be willing to listen and learn more; this is your golden opportunity to enrich their minds with agile concepts, and make them understand the reasons behind them

Hopefully after an incident where something goes the wrong way, the team will start to see things differently. At this point, you begin to cultivate a well-developed team that embraces the agile mindset as a compass for future decisions.

Resistance Can Be Your Friend

It is always challenging to coach agile teams, and a coach should possess many skills and have many tools to help him or her get the best out of the team. Although team resistance to agile concepts might seem like a bad sign or a challenge, it could be a golden opportunity to coach the team to change its mindset when other techniques might fail.

What do you think about the techniques here? Have you tried something similar or different? Let me know in the comments below.

A View of Brexit Through an Agile Lens

June 23, 2016 was a bad day for me …

Watching the votes being announced for Brexit, my emotions were a rollercoaster.

No! Who is to blame for this? Surely we can have a second vote? This is going to be terrible

After some processing, I came to terms and thought: Fine, how do we make this work in an agile way?

As the majority of voters in the referendum decided to leave the European Union, we need to accept this result in the UK and move on with the implementation. The difficulty, whilst the political parties implode, is to decide where to start.

We can begin with Maslow and consider our nation’s hierarchy of needs, and then we’ll look at how to implement it in an agile way:

Physiological – We must start by ensuring our food, water, energy, housing and basic goods are not adversely affected. This means negotiating a common market in order to ensure goods and services can still be freely exchanged. This is an initial major hurdle due to the ties between this issue and freedom of movement. Safety – Our army and security forces must continue to work closely within Europe to maintain our nation’s security. Financial institutions need to work across borders, as must our courts, in order to maintain financial and personal security. Love/belonging – With the basics covered, we can move on with our need to feel a sense of belonging and acceptance. This is difficult when starting with our rejection of Europe, but we will need to persevere, state our case and back it up by working closely with other countries to build bridges and personal relationships. Incremental change with consistency of purpose can change how we are perceived. Esteem – We have a need to feel respected, valued and accepted by others. We need to continue reaching out to others through charity, sport, science, trade and any other means we can find to make connections. Being out of Europe gives us the opportunity to make the United Kingdom’s distinctive voice heard, but this takes effort, time and money. Self-Actualisation – How do we become the best that we can be as a nation, to attain our full potential? We need to strive to collaborate, select the best paths, communicate well and continually improve.

Sounds great, but in practice, what can be done, and how can agile guidance help us get there?

Step 1 - Create a vision: After our politicians finish navel gazing, they must work together along with experts to create a vision for our future as a successful nation. Step 2 - Draw up a roadmap: After invoking Article 50 of the Treaty of Lisbon, the UK will need to collaborate closely with the European council to create a roadmap for the next two years. This will need to be done in a calm, politically astute way to work with others and smooth over some of the recent destructive rhetoric. Step 3 – Put together a team: A strong, empowered, cross-party and highly skilled team should be formed to steer the UK through the negotiations and guide the huge amounts of work that must be performed. Step 4 – Collaborate and communicate: Work within the UK to build consensus and within Europe to build bridges. Transparency over the process and progress is critical to avoid people feeling excluded and abandoned. We need to engage all UK residents and bring them into the change process whilst they hold the government accountable. Opportunities to create trade agreements outside of Europe will be important, but first we must seek to resolve the problems we have created. Step 5 – Iterate and improve: As we have seen, nothing is forever. Seek to engage, hold regular reflection sessions both within the team and externally. Hold regular town hall meetings, briefings and anything else required to ensure vision alignment, people are listened to and the process is continually improved.

The next two years are going to be painful for the whole of Europe as the UK seeks to form a credible and independent identity whilst remaining close to our former partners.

The Agile Manifesto tells us to value individuals and interactions, sustainable development, collaboration and responding to change. Using these key values, agile provides us with a lens with which we can manage change in a positive and collaborative value-focused way.

Time Management and Agile

A while back, I received a Scrum Alliance newsletter announcing that at Global Scrum Gathering Bengaluru 2016, the keynote speaker, Kiran Bedi, would be speaking on the topic of time management.

I’ve been interested in time management since the early 90s, way before the Agile Manifesto was penned, so I thought it a little unusual that this rather ageless topic would be chosen for a Scrum gathering, but then I realized that many agile practices do, in fact, have commonality with techniques taught in time management.


I’ll never forget a lesson I learned from my first time management class. The instructor asked the class, “If someone asked you to pick up a package that was an hour out of your way on the way to work, what would you say?”

Most students agreed that they would say something to the effect of being too busy. Then she asked, “What if I told you that there was a million dollars in the package that you’d get to keep?”

Of course, you’d drop anything else you were doing and make it a priority to get that package. If it meant being late to work, so be it. The worst that would happen would be you’d get fired, and with a million dollars, you just may decide to take the whole day off!

The instructor reminded us that when we use the phrase “I’m too busy,” what we’re really saying is “That’s not a priority for me.”

Next, we went through the exercise of figuring out our priorities--our big life priorities, yearly priorities, monthly and so on. Now that I’m familiar with Scrum, I realize we were creating our life’s backlog.

With software, we’re looking at a product and requirements on a backlog, and we need to continue to prioritize them and ensure they are aligning with our top priorities or our vision. As we prioritize, we weigh the value to the risks or consequences if those things didn’t get done, just like we do when we make any decision.


Another Scrum concept that can fall into the time-management category is that of time-boxing. Scrum is big into time-boxing meetings, such as the 15-minute stand-up meeting, and, of course, time-boxing the iteration itself.

Though some people find time-boxing frustrating because of the sense of pressure it can create, it can also help in creating discipline in completing tasks. The other big advantage to time-boxing is that it provides a mandatory stopping point so that feedback can be gathered. Many activities could go on indefinitely without being time-boxed.

Perfectionism will prevent many people from stopping and getting feedback. Think about the author who never is done with that novel, or the projects that get started, but never finished. Creating a time-box helps you focus, make progress, collect feedback and improve.


One more concept that was adopted from lean methodologies and is commonly referred to in agile circles, as well as time management literature, is flow, or elimination of waste.

Basically, I think of flow as when your mind is totally focused on what you’re working on. You’re in “the zone.” Things like multitasking are discouraged because there is waste associated with task-switching.

One of the Scrum Master’s responsibilities is to remove obstacles for the development team so they are able to focus and not be distracted by unnecessary interruptions.  

A few methods I’ve seen used effectively to stay focused are:

1. The Pomodoro Technique – a technique where you set a timer and stay focused during that time frame.

2. Declare a “No Meeting” policy for your group on certain days or periods. This might be Wednesday afternoons, for example.  

3. Have a visual cue to others (such as putting on headphones) that communicates that this is a time that you shouldn’t be interrupted.

In this day and age when we are constantly multitasking, checking smartphones and email, it can be tough to stay focused and productive. There are a variety of apps and techniques dedicated to helping people become more productive and better manage their time.

What are your favorites?