To Ask or Not to Ask

Starting a New Job

Many years ago, when I started a new job, I was excited because, well, I am not exactly known for being tolerant of boredom. New job, new domain and some new tech: heaven for a curious person such as myself.

My induction task looked fairly innocuous: Refactor some part of the code and add a few features that customers had been asking for. Doable, you’d think. Well, yes, at first glance.

The code base was larger than any I had seen before. Someone who was no longer with the company had done a refactor earlier, but the need for further work was obvious. The code was still unnecessarily complicated, and getting to grips with it wasn’t easy.

I went about that task in the most ineffective manner possible: I tried to figure it all out by myself. While I did ask questions, I asked nowhere near enough.

Guiding New Hires

A couple of years later, by then well-versed in the code base and the functionality of the application, I volunteered to help new hires get up to speed. It was fun, and I liked it a lot. My heart always jumps a little when I see the lights go on behind someone’s eyes.

The arrangement was simple: We’d discuss what the part of application they were working on was intended to do, any problems that existed with it and any features that needed to be added. Then, I’d show them around the relevant code and give them a few “search terms” to find other related code. After that, I was available for any questions they might have.

Though not ideal, it worked well--at least, it did at first. It fell apart when a new hire didn’t ask enough questions. We had some of those, and the consequences weren’t pretty: oversights, bugs and inefficiencies in places where performance was crucial. Many were caught at review time. More were caught by the QA or acceptance testers. Some were not caught until they reached customers. All of them required extra work to rectify what had fallen between the cracks.


What stopped me from asking questions? What allowed some new hires to ask questions, some of them ad nauseam? What stopped other new hires asking enough questions?

There are plenty of reasons why people do not ask questions. Over-confidence is one. Not wanting to bother busy people is another. Fear, as the opposite of trust, is what interests me.

Though I didn’t think of it at the time, in hindsight, fear – or a lack of trust – was the main reason for my lack of questions. While I haven’t explicitly asked any of the new hires about this issue, I do remember many conversations we had around the topic, including some very illuminating responses that all point to that same reason.

So, what was driving that lack of trust?

We just started out in our jobs and were still feeling out our new surroundings. Every interaction we had would have influenced our trust levels, as would every interaction we observed. Still, trust doesn’t erode that quickly.

Whenever you go into a new situation with new people, you are thrown back onto yourself. So, unless you actively discourage questions, how many questions people ask in the first few weeks is driven by their levels of self-trust.

I do mean self-trust and not self-confidence. My self-confidence has always been pretty high. I know what I can and cannot do and I tend to think I can do almost anything given a bit of time and practice.

My self-trust, however, has until recently been extremely low, if not non-existent.

When you look at BRAVING, it’s the N that’s the kicker in these situations. The more judgmental your self-talk is, the less likely you are to open yourself up to judgments from other people. Asking questions becomes fraught with danger, the core of which is: “They will think I’m incompetent.”


When you start a new job, or join a group of people:

Realize that the judgments you fear from others are actually your own judgments about yourself which have formed as a result of your self-talk. Practice non-judgment (towards yourself) and ask the questions that enter your head. Of course, you should try yourself first, but don’t remain stuck by not asking. Show what you’ve tried when asking your question. It will go a long way toward other people gladly helping you out when they see that you don’t just cry for help at the first obstacle. Realize that asking questions shows your reliability. This may sound strange, but it shows that you are aware of your competencies as well as your limitations. People can rely on you to ask for help when you need it.

When someone new starts in your team:

Realize there are several reasons for not asking questions: over-confidence, not wanting to bother busy people or lack of self-trust, to name a few. Realize that no matter how often you assure people that it is okay to ask questions, it does not guarantee they will do so. Respond to questions with patience and non-judgment. Judgment and lack of generosity are the quickest ways to kill trust. Showing impatience or getting irritated by questions is just as much a judgment as an explicit statement. Proactively engage with new hires. Show interest and ask open questions daily, if not multiple times a day. Realize that “how are you” and “how are you getting on” may start with “how,” but are actually closed questions because they only allow for a very short answer: “Good.”

Have you or a colleague ever struggled with a fear of asking questions? Let me know in the comments below.

Be brave and braving!

How IT Service Teams Can Be Agile

Agile software development approaches were originally created to address software development challenges. As enterprises that don’t sell software as their main product adopt agile, they find the need to adjust their approach in order to apply agile across their IT organization and entire enterprise. 

In previous posts, I explored how you can use agile to work with COTS and business intelligence, both of which are common activities that are different from (but not entirely unlike) software development activities frequently found in IT organizations. In this post, I’d like to explore how you can perform another activity, IT service, in an agile fashion.

Characteristics of IT Service Work

IT service work includes areas such as service desk, release management and configuration management that are related to providing information technology services in an organization. There are several other areas that could be included in this description, and I could spark several semantic arguments about what is included in the IT service work category.

To keep things simple, what I’m talking about in this post are those teams in an IT organization that tend to have work with the following characteristics (as opposed to teams that work on software development projects):

Work items usually takes the form of a request or a ticket. These items show up at unpredictable times. Some items are extremely time-sensitive, especially if they deal with people not being able to get their work done, while other items represent changes which are not quite as time-sensitive. Each item is independent from every other item. This means that as soon as you finish the requested action you can deliver the results to the requester, without waiting to finish other, unrelated items. Items generally have less uncertainty surrounding them than items on a software development backlog might have. The only exception to this is when the item represents a bug that requires investigation to identify the root cause. Work Flows Through an IT Service Team

You can group agile frameworks into two groups: those based on timeboxed iterations, such as Scrum, and those based on flow, such as Kanban. 

Each type of framework is better suited for different situations. The context in which you want to apply each framework helps you determine which framework works better for your team to establish your methodology.

Flow frameworks are better suited to IT service work than timeboxed iterations. There’s a variety of reasons for that:

Flow approaches provide greater flexibility to deal with priorities that change frequently. You can change your priority every time you start working on a new item. Flow approaches are better suited for work items that show up randomly, are independent of each other and are generally not part of a bigger whole. Flow approaches are better suited for work items that you can deliver when you are done rather than those that need to be grouped together with other changes. How Work Flows in an IT Service Team

To describe how to apply a flow approach to an IT service team, let's look at a team that maintains a not-for-profit professional organization’s website, including membership administration, event registration and community groups.

Work flows into this team when someone submits a question, request or complaint via a “contact us” form on the organization’s website. The team can’t predict when these questions will come in, and the items vary in their urgency. The team also has a few ongoing efforts to introduce changes to the website driven by new programs or events.

The team has five members, each with their own area of responsibility. A few of the members have the ability to back up the others when necessary or deal with the more involved support situations.

The team is distributed so they use Trello to keep track of the items they must work on and the items that are in progress. Because the items do not all have a consistent workflow, they keep their board straightforward by dividing items into the following sections:




Newly identified items are placed here when either the team identifies work they need to do or someone submits a request via a form on the website.

On Deck

Items that have been triaged and have sufficient information to proceed.

In Process

Items that a team member has picked up to work on.

Waiting for Verification

An item where a team member has completed the work and has requested verification that the work was completed appropriately.


The requestor or other team member verified that the work was done satisfactorily.


Change was implemented on the website or request was delivered to the requestor.

When someone submits a request via a form on organization’s website, the form sends an email notification which Trello converts to a work item in the “new” section. 

The team members take turns triaging the items in the “new” column. As part of their triage activity, they determine the urgency of the item and classify what type of work it is (i.e., does it relate to membership, event registration or website content). The team member doing the triage sets the appropriate label to indicate the type of work. They then move the item to “on deck” and place the new item in a specific order in the “on deck” section based on the item’s priority.

When a team member is able to move an item they were working on from “in process” to “waiting for verification,” they check the “on deck” section for a new work item to start on. The team has some rules that everyone uses to select an item that are based on priority and the type of work that each item represents.

Experiencing the Best of Both Approaches

Even though the team uses a flow approach, they’ve adopted some practices used by teams working in an iterative fashion, mainly because they found value in adopting those practices, not because anyone required them to.

A regular planning cadence

Once every other week, the team gets together to look at the “on deck” section to determine if the items are in the proper order, whether there are any new initiatives that they need to account for and whether there are any items in “on deck” that could be removed altogether from their board. 

This discussion is like a sprint planning meeting with the exception that the resulting queue - in this case the “on deck” section - is not set in stone. Essentially, this discussion serves to reorder the “on deck” items based on the team’s current understanding of the priorities.

Daily stand-ups at the board

The team gets together once per day to briefly discuss what everyone is doing that day and to determine if there are any in process items that have hit a roadblock. During these stand-ups, the team members discuss:

What the team needs to do to get things moved across the board. Based on what is known right now, what item the team should start working on next whenever there is room. Retrospectives around the board

The team also finds value once every other week to discuss how to improve their process. They have this retrospective while looking at the board, because it provides insight into how the team is doing. The questions the team asks during these retrospectives include:

Is there any hidden work that’s not represented on the board? Do we need to add a queue section? Are there any impediments? How can we remove them? Are we tracking things at the right level?

The team used these retrospectives to end up at their current process. They certainly didn’t start using a flow approach with the process described here. Rather, that process evolved as the team got some experience and held retrospectives to gradually improve the process.

Measure and learn

To aid with their retrospective, the team tracked a small set of metrics that also helped them to identify obstacles in their process. These metrics include:

Throughput: the number of items completed this week Lead time for each item (completed date and start date) Average lead time for this week Items completed with > 0 blocked days Total blocked days A list of places where items were blocked How Can You Get Started?

Would you like to begin using a flow approach in your IT service team? The best way to get started is to map your current process using a board similar to what I described previously.  Then, place all the work your team is currently working on in the appropriate section and start working together as a team to gradually improve your process using stand-ups, metrics and retrospectives.

Do you have any experience applying flow techniques in an IT service team? Share your experiences in the comments below.

What the V Model Can Teach Agilists

Last month, a client and I were sitting in a nondescript conference room in downtown New York.

My client was relatively new to software development, and I was explaining that, in traditional software development life cycles (SDLCs), it is absolutely critical to get requirements right. Why? Because if requirement errors and omissions are not caught until very late in the process, they can cost a lot of money and rework down the road.

To illustrate my point, I showed him a typical V Model illustration (focusing on requirements elements):

The V Model is certainly not new to the world of software development. It can be viewed as a simple evolution of a typical waterfall model that has the testing and verification phases bent up to form the shape of the letter V. When this is done, there is a correspondence between the phases on the left (that elaborate the product) and the phases on the right (that validate those earlier phases).

The conversation ended with my client saying, “All of this is good for you to know, but if you’re working in an agile environment, you won’t have to worry about it.” But, on the long train ride back to Washington, it occurred to me that this isn’t exactly the case.

Indeed, the V Model has a few things to show us agilists.

It Highlights the Importance of Testing

The most obvious characteristic of the V Model is that it strongly favors testing and validation of all the work done earlier in the project. Yes, all the work, whether you are talking about unit tests validating a module’s code or project acceptance validating that the project delivered the business requirements.

But what is our real day-to-day consideration of (non-unit) testing? At most, it will usually be a quick “let’s run it by a couple (actual) users.” More often, we have testers (or even just the product owner) poking around at it and making sure it works. And that makes sense, because our next iteration is coming out in two weeks anyway, so we can effectively just have our users test the product in production. Right?

No! Not right! Remember that we are not just tasked with delivering software frequently, but also with “deliver[ing] working software frequently.” Too often, we can take an expedient view of getting the product out the door, and this can have a massive impact on our customers’ impressions of the product and indeed on our businesses.

It Encourages Us to Question Test Coverage

Here’s the deal: There are two different definitions of “working,” and we need to hit them both.

What do we usually consider it to mean? First, that it’s bug-free, or at least has a low defect count. I’m certainly not going to challenge our traditional concept of quality, but this definition is less important that the second criterion, namely:

Does the product do what the customers want it to do?

Most of our agile teams don’t have any process in place to verify that the next release will pass this test. And that’s why we are frequently surprised when a particular version isn’t well received. We met our definition of done and acceptance criteria, after all.

Make no mistake: rapid iteration is not a solution to mediocre quality.

It Shows Us Why We Do Agile

Have I talked enough about quality? Good! Let’s shift gears to focus on the V Model as the most effective marketing tool for agile development ever created.

The next time a customer or CTO asks you why they should switch to agile methods, pull out a copy of the trusty V Model, and you can’t go wrong. Simply follow this three-step process:

Point out the lateral distance between “business requirements” and “project acceptance.” Tell them that represents time. Not project time, but real-world time in which their customers’ needs are changing and their competitors are working to beat them. Mention that, unfortunately, the project’s scope will be frozen during this period, unless they want write a new statement of work (SOW). Point out the distance between “functional requirements” and “user acceptance testing.” Tell them this represents the time gap between their providing requirements and their seeing the first version of the system. Business-technology collaboration isn’t written into waterfall processes during this time (although, it does kind of show up for non-agile iterative methods).

As you can see, the V Model has a lot to teach us – or at least to remind us. Good product development practices can often be found in the last place we’d expect to find them, and it’s worth taking a fresh look from time to time.

How about you? Do you see any other leverage points for the V Model in agile? Let me know in the comments below.

Bad Meetings Are Boring and Ineffective

Every day, when my husband returns from work, I ask him “How was your day?”  Most of the time, he shrugs, and says something like, “Urrggghhh – so many meetings – I didn’t get ANY work done.” I’ve no idea what he does, but his LinkedIn profile tells me he “attends meetings and adds value.”

But meetings ARE work. They are an important part of the collaborative process, and one that the Scrum framework recognizes and formalized.

According to MeetingKing, 11 million meetings occur in the US every business day, and waste $37 billion in lost time each year. Maybe you are in a boring meeting right now, reading this.

Patrick Lencioni’s fable, “Death by Meeting,” hits the nail on the head:

“Bad meetings, and what they indicate and provoke in an organization, generate real human suffering in the form of anger, lethargy, and cynicism. We typically complain we have too many meetings, but the real issue is that the meetings normally aren't very effective.”

That doesn’t sound very agile, does it?

Lencioni cites the problem as twofold. Meetings generally lack:

Drama or conflict Contextual structure

Frustration is inevitable when “little is decided as participants have a hard time figuring out whether they are supposed to be debating, voting, brainstorming, weighing in or just listening.”

Why Are We So Bad at Meetings?

We are failing our Scrum Masters. They are our anointed servant leaders, coaches, and facilitators. How inspiring! However, we rarely tell them HOW to fulfill those roles. There is a general overemphasis on process and technology, and an under-emphasis on leadership skills.

I have a recurring daydream, where I decline every single meeting on my calendar. Eventually, if I’m really needed, I’ll be contacted again. Bliss! I’ve learned that this isn’t the most emotionally intelligent way of dealing with meeting overload.

David Grady’s humorous take on organically seeding good meeting etiquette is a great primer, especially when you have no idea what the meeting is about:

You don’t HAVE to accept every meeting you are invited to – use the “tentative button.” Talk to the organizer, and let them know you are excited to support their work. Ask what their goal is and how you can help. If you do this often and respectfully enough, maybe people will become more thoughtful about putting meetings together.

The Difference Between In-Person and Virtual Meetings

While I was attending an advanced agile scaling class a few years ago, the instructor stated, “at scale, Scrum won’t work if you have distributed teams – they must be co-located.” Always one that likes to debate, I sent out a “thought balloon” to see how it would be shot down. I was curious.

“Do you think that 16 years after the Agile Manifesto and its principles were written, technology has changed enough to update the idea that ‘the most efficient and effective method of conveying information to and within a development team is face-to-face conversation?’”

“NO!” was the emphatic response, followed by a couple of slick and funny YouTube videos highlighting the problems with conference, or worse, VIDEO conference calls.

I had to admit I agreed with him. Today’s modern communication software does not replace face-to-face conversation, but the reality is that the majority of teams are moving to this type of dispersed work. 

Whatever the latest technology du jour is, it will not replace the fact that you can learn how to facilitate better.

So what can we do to make the meetings suck less?

Have a Plan

I have great respect for the Grove Facilitation Model, which provides a robust, world-class way to lead a meeting.  It helps to provide the context for the following questions that every participant of a meeting needs to know:

Why am I here? Who are you people? What are we doing? How should I behave? When can I leave?

In my agile coaching practice, a common weak point I see is the retrospective being omitted. People don’t have time to do these meetings, and therefore they mistake the lack of effectiveness for false efficiency. This points to all kinds of juicy and dysfunctional problems, but meetings don’t HAVE to be a chore.

Make Your Virtual Meetings Shine

After training with The Grove on successful virtual meeting facilitation, I’d love to share their six main points to consider when planning a meeting. Make a template and fill it in so you have a proper plan you can add to your agendas. Scrum Masters, discuss it with your team to use as part of your working agreements.

Prepare Assign roles (such as tech support, scribe, timekeeper or facilitator). Don’t make the team lead a facilitator. Use a visual focal point for each agenda point. Humans are a visual species – this is how we remember and engage with things. Include a team portrait and graphic facilitation. Practice transitions. Determine how you will reach your outcome. How will time be used, who owns each topic, when do you make decisions, how will you make and document a decision? Make it engaging. I like to channel Sharon Bowman’s The 6 Trumps™ for any occasion. The person doing the most talking is doing the most learning, and if anything is longer than about 10 minutes, then you have lost your audience engagement. Design things well to maximize audience participation and use simple tools. Clarify Communication Channels Confirm meeting arrangements ahead of time. Audio is the most important element to get right. Include working norms. For example, always use a headset – no speakerphones permitted. How will you share working documents? Which ones does your company support? Which ones support the type of work you want to do? KISS (keep it simple, stupid)! Go Slow to Go Fast Expect a slow start. Include an icebreaker to allow people to get settled. It also serves as a subtle way to do a tech check and ensure that everyone can hear. Display the agenda often, especially at the beginning, transitions and the end. Virtual meetings often omit an agenda altogether. Create space right away for people to have their voices heard and get connected to content. Ask people to reframe the purpose of the meeting -- include a “2 breath” rule to allow for bottom-lining of context. Ensure Participation is Balanced Engage everyone by name, especially in blended meetings. Make space for quiet participants. Be sure to throw the quiet people a line. Structure an inclusive process (maybe write thoughts down first, then share). Keep Calm and Carry On Keep participants accountable to the agenda. Expect things to fall apart. Always have a lower-tech back up plan (phone or chat). Actually Follow Up Form crystal-clear agreements on next steps. Communicate with people after the meeting. Make the notes visual and ban the bullet point. It’s a snore fest. My list here is ironic. Document! List action items, owners and due dates, and add things to the backlog.

Poorly facilitated meetings are still poor meetings, irrespective of location. Virtual meetings just amplify facilitation problems. Facilitation as a skill is not often purposely honed--it’s something that most people “just do.” The evidence overwhelmingly tells us that it is not usually done well.

Now I know my husband does work by attending meetings and adding value, even though he feels like he attends every one of those 11 million meetings a day.

Bad meetings are boring and ineffective. But, if done well, they can be a time-saver.

Have you had positive or negative experiences with virtual meetings? Do you have any tips for improving their efficacy? Let me know in the comments below!

Find more information about different facilitation models here:

Grove Facilitation Model and OARRS

Agile Coaching Institute POWER


End the Scrum Revolution, Begin the Scrum Evolution

An organization is a network of complex dependencies. Because of this complexity, any change in any direction will face some resistance. The major difference between a waterfall project and a Scrum project is that the latter encourages and even welcomes change. How do you introduce Scrum to a non-agile organization without facing major resistance?

Unfortunately, in their efforts to apply Scrum, companies often take the head-first approach, seeking a revolution. They look at the ideal world of how a fully agile company is run, take parts of it and stick them on their own organization. This is like putting wings on a dog and shouting at it:

“Now fly!”

And, lo and behold, the dog will just sit there and look bewildered. Consequently, Scrum gets the blame and the chapter of agility is either closed or “adapted,” with the company running Scrum in name only.

How can you teach your organization to “fly”?

Managing Your Employees vs. Providing a Vision

Change can be taught by one of two methods:

You demand that the student follow your exact instructions. It will hurt, and it will cause muscle ache, frustration and exhaustion. Yet, sooner or later, the student will learn the right technique and will favor it over other techniques, feeling the difference. This method is often used in sports, especially because the wrong moves can cause serious injuries. You start with what the student already does and offer a path of small improvements. This method is preferred if the student simply cannot perform the optimal technique at that time. Singing is a prime example: if you demand perfection, the student will never finish his or her first song; the learning curve is simply too steep.

Having played chess for many years, I prefer the second method and tend to approach problems as I would approach a game. When looking at a company’s agile transformation, I see the current situation as the starting position and the agile ideal as an approach to “win.”

Many preparatory moves are required to get to the finishing move, which in this case would be the implementation of the solutions that Scrum offers. It is like walking through a labyrinth where you are sometimes moving away from your actual goal, having to take one step back to move two steps forward.

Encouraging your organization to “fly” is not necessarily a bad idea. But this should be done by providing a vision and leading your coworkers through the process of change. In this way, they can deal with the actual implementation through evolutionary change instead of having management trying to give exact instructions or ignoring the knowledge and abilities within the teams.

How Should You Navigate the Maze of Agile Transformation?

When I first read about introducing Scrum in a company, I found it excessive, or maybe a type of “showing off” that the literature proposes to have the team executing the transformation use agile themselves as their project management methodology. It sounded like a salesperson proclaiming that their product can be used anytime, anywhere. Yet, after some experience in the industry, my view on this has changed.

The point is that the significant challenge of the agile transformation is that the requirements are not fully defined. Every single organization is different, so there is no standard way of introducing Scrum to a company. This makes it a perfect candidate for evolutionary change--- navigating through these unknowns in small but steady steps.

The First Rule of Teaching Scrum Is to Not Talk About Scrum

The first thing I tell people I coach about Scrum is to forget everything they have previously heard about Scrum. I am in no position to know better than they do what their problems are, or to think that “my” methodology would help them. Scrum is not a magical cure. Management gets too quickly enamored with the idea that there is a method that, once it’s been introduced, will solve their problems. Since this simply isn’t the case, the question remains, how can organizations achieve real change?

In my opinion, change can be achieved only by means of mutual trade. You can win over the other side if you offer an advantage. The simplest way to connect your team with the idea of Scrum is to give them a helping hand. Do nothing else but have them start by writing down impediments, and set up regular meetings where you offer solutions to their problems.

If your team is not yet very experienced with recognizing impediments, you can lead them cautiously by asking direct questions and engaging them in discussions about why some work shows no progress. The more impediments you gather, even small ones, the easier your job will be in the next step. This list of impediments will become the golden key you need to---step by step---warm the team up to the idea of agile thinking.

Next, conduct interviews in the company to evaluate its current status in terms of agile maturity. There are many checklists available online; personally, I find the 50 points from Atlassian very helpful.

After this initial evaluation, categorize the gathered impediments according to the list. If needed, add additional categories for the remaining impediments that do not fit. For example, you might also want to evaluate the agile maturity of external suppliers which need to be integrated into your process.

Once this categorization is done, you can skip all points for which your team has not encountered any impediments. Without empirical evidence to support a certain change in your organization, there is no reason to “improve” the agile maturity in these other categories.

Obviously, the other points impede your team as well. But if there is nothing directly visible for the team, there is nothing you can do about it for now. Remember, you are implementing Scrum to solve actual problems of the team, not to create a PowerPoint presentation for management!

Not only will this give you an invaluable compass in the sea of possibilities of what you can change, but it will also provide you with empirical evidence to support any decision you are making.

We have established our current position by evaluating the status of the agile transformation in your company. We have also established a goal and have identified which of the points we should work on. Now, the real strength of the list comes into place: intermediary stages. Instead of just listing ideal situations, it shows the steps leading there. They represent small stories that can be worked on in individual sprints and thus can serve as a metric for your agile transformation process.

Summary The agile transformation is a complex project itself. The ideal approach to a complex project is agile and evolutionary. Analyzing the current situation and tracking progress with a good metric is key.

How do you navigate through the process of agile transformation? What metrics do you use to track progress? Let me know in the comments below!

Part of a Scrum Master’s Job is to Lose It

Two weeks ago, a developer on our team told me that he wanted to have a sprint planning to go over a code change that he and another developer had been discussing (most of our work is done through Kanban these days).

A sprint planning session would have been overkill for what he was proposing and the number of people involved, but I was very pleased to hear him make the suggestion nonetheless. Last week, I proudly congratulated that same developer when he told me he had passed the Professional Scrum Master (PSM) certification exam. At this rate, he will hardly need me in a couple of years (if he even does right now).

The Scrum Guide states that one of the Scrum Master’s responsibilities is to “[coach] the development team in self-organization and cross-functionality.” Implicit in this statement is the notion that a Scrum Master should work him or herself out of a job.

A coach helps people understand and do what they still can’t understand or do themselves, with the expectation that they will eventually be able to. This is what nutrition coaches, fitness coaches and business coaches do. Therefore, a Scrum Master who serves as a coach should help the development team grow to reduce their dependence on the Scrum Master.

This is not exactly the same as helping individual contributors move into management. Some people want to become leads, managers or executives, and that’s fine. Some don’t, and that’s also fine. You should not force someone into a job role that they do not want.

But since a Scrum Master is not a traditional manager (though the name of the role continues to inspire that misconception), but rather a facilitator, you should expect a development team to continue to grow their skills that help them communicate and work with customers, business stakeholders and other development teams. That should be part of their natural career progression.

Of the three roles in a Scrum team, arguably the one you could most easily do without is the Scrum Master (although you would technically no longer be following Scrum). This does not diminish the Scrum Master’s importance, nor does it mean that the Scrum Master’s role ever really goes away, as Mike Cohn points out in this article.

It is, however, a reflection of the fact that the product owner and the developers must have hard technical skills in order to get their work done, whereas a Scrum Master is essentially a collection of coordination skills concentrated in a single person. You do not expect an experienced product owner to eventually develop coding skills, nor do you usually expect a developer to decide which backlog items are the most important to a company.

But you do expect both of them to become progressively better communicators, planners and collaborators. And that’s really all a Scrum Master does within the scaffolding of the Scrum framework: Foster better communication, planning and collaboration between the business and the developers.

Remember that your goal as a Scrum Master is not to still be chasing resources in five years the same way you do today, but rather to have guided the team to a point where you are their point of escalation instead of their first resort whenever they hit a snag. Coach the team on the importance of planning so that a sprint planning session is no longer just an hours-long ordeal to be endured, but something so natural and necessary to getting quality work done that they bring it up themselves.

By helping the team understand and do what you understand and do, you create a virtuous cycle that helps your current team members, future team members and other teams that your developers will eventually be part of.

Do you agree with my assessment of the Scrum Master’s role? Let me know in the comments section below.

The Essence of Agile

One thing that has changed for me over the last few years is that I find myself working with people for whom agile has become the norm. Indeed, I have even begun to work with people who have never done waterfall. My frames of reference are changing; I am starting to find that comparisons with waterfall don’t carry very much weight these days.

Ten years ago, I was working as a test manager on multiple projects, some waterfall in delivery approach, some with agile aspirations that were experimenting with elements of Scrum. I wrote a piece entitled “The Essence of Agile” to see if I could get to the heart of this new way of doing things.

Here it is:

"Essence of Agile" sounds potent, doesn't it?

Since the Agile Manifesto is already a succinct summary, then its essence will surely pack a powerful punch.

It sounds like something that I might be able to sell. So, before I go any further, I'd better think up some tag lines for my marketing campaign.

"We build software. We build it fast. We build it right. That's agile."

I like that one because: It's snappy, it's bold and it delivers the message that we know what we're doing.

"We build software. We deliver it incrementally. We adjust when we need to. That's agile!"

I like that one because: It's honest, it empowers the customer and it delivers the message that we know what we're doing and are willing to discuss it.

"We build software. You may not get what you want! You may not pay what you want! But you'll get something! THAT'S agile!!"

I like that one because: honesty, humour and exclamations! Knockout!

However, building software is an exercise in engineering, not marketing, so maybe I should put some effort into the product itself. Or at least consult Wikipedia on the definition of the word “essence:”

"...essence is the attribute or set of attributes that make an object or substance what it fundamentally is, and which it has by necessity, and without which it loses its identity. Essence is contrasted with accident: a property that the object or substance has contingently, without which the substance can still retain its identity."

As a way of building and delivering software, “agile” looks to me like the application of common sense in a sequence of coordinated actions designed to deliver a pleasing result.

In the whole short history of software development, we may well consider that all methodologies have been attempts to apply common sense in a sequence of coordinated actions designed to deliver a pleasing result. So, it may be argued that agile methods are simply the natural outcome of smart people working together to build useful software at a reasonable cost.

If we were to pay someone to estimate the dollar cost to businesses and governments of failed software projects, their fee alone would make us yelp.

So how loud would we be yelping if and when we knew the dollar cost of failure?

Maybe we could estimate it using the “software project under-estimation” method: Think of a large number. Now double it.

This is to say nothing of the impact to human lives, societies and communities of failed software projects.

The attributes that make agile fundamentally what it is are: "common sense" and "coordinated action."

This is in contrast to pure common sense which can be suggested, mooted, opined, considered and even written down without ever being translated into a verifiably actioned result (i.e. saleable code).

This is also in contrast to pure action whereby 10 developers or two architects or maybe one developer with a smartphone start to "bash" out what we all hope will one day become saleable code, whilst a project manager and a handful of business analysts engage in long and detailed discussions with the people who want the software built.

Somehow, not everyone is quite exactly available at the same time, so they fly around a lot and talk about how the software will look and review their decisions. Those decisions are then re-reviewed and re-decided with the provision that any decision made can always be unmade, and then made again later, because that is what agile is all about.

Fortunately, the developers never actually meet the business analysts, so they are able to get some real work done without having to refer to outdated and changing requirements.

This is great news for the testers who are able to catch up on their blogging commitments, speaking tours and internet-based self-teaching programmes.

The essence of agile is direct and frequent communication based on a combination of data about how we are measured against what we’re aiming for. The goal in this communication is to evaluate what we did, what we need to do next and what is preventing progress.

It sounds simple, but communication is the key, and it is the hardest component to perfect.

What is useful about the agile approach in this regard is the emphasis on regular, focused conversations in a facilitated format.

We constantly have to check our assumptions and agreements with each other. Have you noticed how easy it is to go off track and how quickly it can happen, even when everybody “knows what they’re doing,” the team is “experienced” and the client “knows what they want?”

In fact, in those cases it is especially easy to get side-tracked. I may know what I’m doing, but is that helpful to our goals right now? The team may be experienced, but what are the lessons of that experience that are going to be useful this time around? Do we have the skills, willingness and courage to learn what is needed as we go? The client may know what they want, but have they asked for what they want? And, how much control are they expecting to exert over what can change over the life of the project?

Taking daily doses of the essence of agile minimises the key killer of software project value:

Doing the wrong thing at the wrong time even if we do end up getting paid for it.

We Can’t Maintain a Sustainable Pace with Many Small Projects

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I prefer to think about this agile principle as: “Anyone who contributes to the success of the product should be able to maintain a constant pace indefinitely.”

The main two groups that I like to bring under the umbrella of “anyone” are subject matter experts and senior stakeholders. These groups are usually outside the development team, but need to be available for frequent conversations with the product owner and to provide timeous feedback at iteration reviews.

We often find that multiple projects are suffering because “anyone” is frequently unavailable, usually due to other priorities. 

In this post, I will highlight how starting too many projects can put an unreasonable strain on those inside and outside of the development team and lower the team’s chances of successfully delivering products.

We Often Need to Split Resources

Obviously, every project that we start needs resources and those are usually limited, meaning that new projects need to be resourced by allocating portions of people’s time.  Suppose we split someone’s time equally across three projects; that means that the person in question will be unable to work on two out of the three projects around 66 percent of the time, or 3.3 days per week.

Being unavailable for that much time is undoubtedly going to have a negative impact on velocity and quality. We can incur up to a 40 percent penalty in productivity associated with multitasking on complex tasks. A quick search on the internet shows just how widely accepted this argument is.

Our Teams Can’t Improve

Another downside of splitting resource and creating teams specifically around projects is that we lose the chance for our teams to continually improve via building relationships, knowing one another’s strengths and weaknesses and solving complex problems together.

According to Robert C. Martin in his book “The Clean Coder”, “Banks and insurance companies tried to form teams around projects. This is a foolish approach. The teams simply cannot gel.”  

He claims that we can’t even call these creations teams and that there is no such thing as half or quarter of a person and suggests that it is better to assign multiple projects to an established gelled team, who will work together to figure out the best way to get them done.

We Hinder Our Chances of Essential Engagement

Users, sponsors, subject matter experts and senior stakeholders all have jobs to do outside of our projects. Furthermore, the same people tend to be in demand for each small project that we start due to expertise or seniority. This is especially true if those smaller projects are related to a common product or strategic goal.

The more projects we start, the more demands we are making of these people, meaning that they can no longer work at a constant pace and can no longer be available for teams when required. Even when they are willing to work lots of overtime, they can’t be in two places at one time. So, through no fault of their own, they become huge blockers for all projects that depend on them. 

We Introduce Avoidable Dependencies

If we create lots of small projects that contribute to a common product or strategy, we will introduce the overhead of managing dependencies that are avoidable simply by either creating larger projects or allocating projects to an existing gelled team. It’s better to eliminate rather than manage dependencies wherever possible. 

We Risk Perpetual Change

We need to be careful to ensure that the projects we are running concurrently are not delivering changes to the same users. The success of our products will ultimately be decided by our users, so we don’t want to place them in a perpetual state of change, making it impossible for them to get their jobs done without working sustained longer hours.

We should be more concerned with significant process or cultural change here, rather than the well-managed continuous delivery of small software updates, which many users welcome.

We Cause Excessive Overtime

We have seen that starting many projects can put strain on those inside and outside of the development team. The diagram below shows the vicious cycle that we can become trapped in as the negative symptoms of sustained excessive overtime lower our quality, morale and productivity, which in turn leads to more negative symptoms. Thus, the cycle is begun anew.

Choosing the Best Option When Starting Projects

Imagine for a minute that we’re property developers and have purchased two properties that we want on the rental market within 12 months. Each requires six months of dedicated renovation at a cost of $2,000. Property A will receive $2,000 per month in rent compared to the $1,500 Property B will receive. We can choose from three seemingly sensible approaches. The table below shows each approach and how it may broadly impact our profit.


Property A

Property B


Profit (24 months)

Simultaneous: Team works on both properties an equal amount within each iteration





- $8400









Alternate Iterations: Team focuses on each property for an entire iteration alternatively














Linear: Team finishes Property A before starting on Property B














In his book “Agile Portfolio Management,” Jochen Krebs states that we could safely apply a 40 percent penalty to the “simultaneous” approach and a 15 percent penalty to the “alternate” approach, which increases our costs while reducing our income period.

Over a period of 24 months:

The “simultaneous” option is by far the worst and actually results in a loss of $8,400. The “alternate” option is considerably better and results in a profit of $8,100. The “linear” option is by far the best and yields a profit of $30,000. As we prioritize Property A over Property B in terms of pure business value, we finish on time and on budget. Even if we reject the switching penalties completely, this option remains most profitable because we can begin harvesting income from our most profitable property after six months instead of 12.

Kreb suggests that in reality the switching penalties can be much higher on complex projects and increase as the number of active projects grows, which makes the argument for the linear approach even more compelling.

Try to Be Professional

In the previous section, we saw that prioritizing and focusing based on business value offers an earlier and higher return on investment (ROI). It is the professional thing to do, so we need to at least try to be professional when making these decisions.

I say “try” because being a professional is difficult and often requires us to say no to our managers. However, just because it is difficult doesn’t mean we shouldn’t do it. Again in “The Clean Coder,” Robert C Martin agrees:

“Slaves are not allowed to say no, and laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no.”

In my next post, I will demonstrate how to use a balanced agile portfolio, so that making professional decisions and saying no to good managers becomes easier.

In the meantime, feel free to share your thoughts on having many active small projects in the comments section below.