Category Archives: Series

This category is for sets of related posts that cover themes too large to fit into a single blog post.

Ask an Agile Coach: What is an Agile Coach?

This installment of the Ask an Agile Coach series is a question normally asked by persons outside my field, but lately I have been asking it myself:

What is an Agile Coach?

Good question. I am not sure anymore.

The more I encounter others who call themselves Agile Coaches, the more I think I may not be up-to-date on what that is supposed to mean.

As I have historically interpreted it, an Agile Coach is someone who first actually established a proven track record of successfully leading a series of Agile adoptions as part of the actual teams. The insight, perspective, and expertise gained through that effort are what enable them to coach others. Multiple Agile teams in varied settings challenges what a person “knows to be true” and (hopefully) beats some humility into and the dogma out of them.

I have been under the impression that an Agile Coach also understands software development and the technical practices that support an Agile team. One must understand why testing, automation, code review, and pair programming exist. One must know what it feels like to work both with and without these things, know why professionals should adopt these practices, as well as when one or more of them are not a fit for the culture. It must be very strange to have management bring in a coach who tells you to do these things but cannot show you how.

I also thought that coaches should understand how to apply an Agile process in a way that stresses cross-functional participation. If what a coach is doing isn’t helping the company to function more effectively as a whole, I fail to see the point. Agile Software Development is neither a defense mechanism for engineers nor a tool for more effective exploitation by management.

It feels weird to have to point this out, but I believe a coach should understand Agile estimation and planning techniques, especially the ones laid out in Mike Cohn‘s books. Estimating and planning are among the most painful parts of software development, and one of the most fulfilling parts of coaching for me has been mentoring groups in Agile estimating and planning.

I also think an Agile Coach is someone who can say no. Agile Software Development is a challenge at best, and a cultural nuke at worst. There are places where the introduction of Agile process and practices would wreak havoc. I suppose the toughest part of this is that it requires a willingness to turn down paying work.

I am seeing things these days that make me think my idea of what an Agile Coach is might be incorrect. If it is, I might need to stop using that word. It doesn’t mean what I think it means.

Ask an Agile Coach: What Team Members can be shared across multiple Scrum teams?

Welcome to another installment of Ask an Agile Coach. Today’s question centers around how to structure teams in light of constrained skill sets in an organization:

What technical roles, other than QA, can be successfully shared across scrum teams? DBA, UX, etc.? – @jakejgordon

Strive to have people in dedicated teams; only share in order to get work from concept to customer.

Any software application of substance requires a collection of specialized skills. A healthy, cross-functional team will have a pool of diverse talent: programming (in at least one language, but often more), testing (QA), database administrators (DBA), business intelligence (BI), user experience (UX), operations/infrastructure (OPS/INFRA), and others. However, some of these skills are not used enough to occupy a single person’s work from week to week on a single team, so persons with those skills are allocated across multiple teams.

Recall that, with Scrum (and other Agile processes as well, though Scrum is most explicit about it), the process is designed to provide empirical process control in software development. The reliability of velocity as a measure of throughput depends upon the stability of the team. Therefore, an organization should try to structure its teams to consist of people dedicated to the workloads they serve. When team members are allocated across multiple teams, their available hours for each team can vary from sprint to sprint. Since these people are usually specialists like BI or UX, this variation is happening with the most constrained set of hours available for Sprint Planning. Any user story in a sprint that requires these hours is at risk of carryover if the team planned against hours that turned out to be unavailable.

The undesirable result of this variation is an unstable velocity and increased carryover of user stories in sprints. This in turn erodes the reliability of planning and estimation activities. The team shows itself to be unreliable and unable to deliver on commitments, eroding confidence and trust with stakeholders and management.

The primary risk with sharing team members is that Scrum Masters and management often do a poor job of accounting for how those peoples’ time is allocated and managed, which inflames the symptoms described above. Bear the following points in mind when sharing team members:

Include all your cross-functional team members in user story writing, estimation, and Sprint Planning sessions. User stories that account for all the effort needed to go from concept to customer are more reliable and not as prone to surprises during delivery in a sprint. Prefer the bad news of resource constraints over the surprise of planning against naive user stories.

Avoid sharing a team member across more than two teams. Once a person has to divide his or her effort across three or more teams, estimates and available hours become unreliable. Furthermore, the more teams a person has to participate in, the more their time is wasted in switching their mind between contexts. They also end up in recurring events like Sprint Planning, Sprint Reviews, Backlog Grooming, and Retrospectives for each team, leaving a meager number of hours to do actual work. If a person has to be shared across more than two teams, that is a sign that another person with those skills needs to be hired.

Use the valuable information from Sprint Planning and tracking to inform the budgeting and hiring process. Is QA/BI/UX constantly a shortage in Sprint Planning? That is the gentle, loving tap of the clue bat on the collective skull of management to stop hiring more software developers and allocate the salary budget in a manner more appropriate to the actual work being done by the group. Hidden costs of effort are being uncovered as a result of properly applying the transparent, reliable process that is Scrum, and that is a good thing.

Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.

Ask an Agile Coach: Should I count partially complete user stories in my velocity?

Hello readers, apologies for the lack of posts lately; lots of work at hand. Today’s Ask an Agile Coach question comes from a comment on the last installment, which is rephrased here. In one form or another, I have gotten this question for years now:

Should I count partially complete user stories in my velocity? For example, if I have a 100-point story that’s almost done, should I add 80 points to my delivered points total for this sprint?

The answer is no, you should not.

Remember that Scrum was designed to enable empirical process control for software development. The team is committing to work in fixed intervals, with the intent being that a team becomes quite proficient at knowing how much work they can move from concept to customer within that fixed interval. To that end, the points that go into velocity are points delivered. Delivered points come from stories that are completed. When stories are incomplete, they are carried over, and velocity is lower than expected for the Sprint. Hopefully, these points plus the additional work pulled in will cause the next Sprint to have a higher number of delivered points and the two values will level one another out.

If a team or Scrum Master insists on counting part of a story’s points in velocity, they are masking a symptom and thus choosing to ignore the underlying causes. This short-circuits the process and the valuable feedback it provides.

If a team finds itself with carryover continually affecting velocity in a negative manner, it is usually an indication that the team needs to improve their ability to plan and commit to work within a Sprint.

One area to target is honing the ability to break work down into thinner vertical slices of user-oriented functionality. If stories are perpetually 50-80% done at the end of a Sprint, revisit the team’s approach to user story writing and trying to carve smaller functional slices (but not so small that you violate the INVEST heuristic from Bill Wake; an alarming number of practitioners have fallen into hyper-granularity in their stories).

Another area to address is the cross-functional team’s (and your Scrum team is cross-functional, right?) understanding of what it takes to go from concept to customer. If stories seem to invariably look smaller or the team seems to perpetually overcommit, it may be that some of the more vocal team members are expressing estimates that reflect a myopic focus on simply the writing of code instead of all the tasks involved in completing a given story. Encourage the other cross-functional members to speak up in User Story writing, Sprint Planning, and Backlog Grooming about what they need to do to complete the stories in question. This has always resulted in more accurate story sizes for me over the years.

Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.

Agile with External Clients: Testing Is Not Optional

Today’s installment in the Agile with External Clients series covers the topic of testing. A decade after The Agile Manifesto and over 16 years since Scrum and XP came on the scene, I still encounter a large number of teams where the use of testing is lip service at best and non-existent all too often. In this context, testing means the use of frameworks like xUnit et al to create of a suite of unit, integration, and functional tests that exercise a body of code by executing it and making assertions about the outcome of that execution at multiple levels of focus and granularity. Of all the practices of Agile software development, both process and technical, testing is the one people most readily acknowledge the value of while at the same time avoiding it altogether. So, let me make this quite plain:

Testing is not optional.

Testing does not slow you down; it allows you to speed up. It is the fundamental feedback loop in the creation of software. Testing is one of the strongest means of minimizing and eliminating waste by virtue of how it allows you to catch defects as early as possible. This is true both for errors introduced directly in the code being created and indirectly through breakage of existing code relies upon or integrates with what is being made. Manually exercising your code by running it locally and following along in your debugger is not an adequate substitute, but rather a companion to the judicious use of testing.

While this lesson applies to any Agile group, it is especially critical if you want to run projects for external clients using an Agile approach. Recall that for many clients, you may be their first encounter with Agile software development principles. Their historical context views “testing” as an afterthought, a separate process that does its best to verify that what was built approximates what was documented. That makes testing a separate value proposition and one to cut if cost or timeline become an issue.

Given the disappointment with phased approaches to software development, it should come as no surprise that the testing “phase” has a hard time living up to its potential. At that point, there’s already an entire project of sunken cost in analysis and development. Feedback on things that aren’t working as expected are taken as bad news, since some of the software was developed months if not over a year ago. If you read reports from testing groups that have gone over waterfall applications at the final testing phase, they all seem to fall under the theme of “Things That Would Have Been Great to Know at the Time I Could Have Done Something about Them”.

An Agile approach that includes the technical practice of unit, integration, and functional testing restores what we have been missing for decades in classical approaches; we now have feedback and information at the time when we are best able to act upon it. It gives us a flexibility and confidence to move swiftly in implementing new features and responding to inevitable change without recklessness or irrational optimism.

This is particularly true in the case of working with external clients. If a team is effectively applying testing, the lack of mid-to-late-project “surprises” is refreshing. Functionality whose implementation can spin on a dime without tearing the ship apart astounds clients who’ve become accustomed to changing their mind or acting upon new information being a quite painful and costly activity. If User Stories are the most astounding process practice, then Testing is definitely the counterpart as the most profoundly beneficial technical practice.

Having testing be an inseparable thread in the fabric of how you deliver software can separate you from the rest of the pack who claim to be the “Agile gurus” in your market. However, the absence of testing doesn’t merely deprive you of that benefit. As changes are introduced to the system and allowed to pass for days if not weeks unnoticed, your team invariably runs aground on one or more of those issues. You find yourselves in uncomfortable conference calls explaining how this iteration is going to have only half its stories delivered due to things that have surfaced on stories that had already been declared complete in previous iterations. Unchallenged assumptions arise late in a project to bite the team on the ankle, making the project less flexible should the client require nontrivial changes to the architecture.

As clients observe this behavior (and believe me, they notice), they come to the conclusion that maybe this Agile business is no different from everything they’ve seen before. Your group is just another one claiming to have “the secret”, while their impression is that paying a premium for experts doesn’t really deliver what it promises. And if that’s the case, maybe they should have just gone with the lowball bid.

Ask an Agile Coach: How do I handle the effect of carryover on velocity?

Our previous installment of Ask an Agile Coach had a new question in the comments:

As for the case when some of the user stories didn’t get completed, what happens to the user stories which were partially completed–say, 80% finished–but didn’t quite make it? How do you keep your velocity metric from getting hosed?

Practitioners have asked me variations of these questions many times over the years. I’ll paraphrase them into a single question:

How do I handle the effect of carryover on velocity?

When we gather data about something, there’s an innate temptation to filter the data to effect a desired outcome. It is often subtle; sometimes we don’t even realize we are doing it. This is a form of sampling bias, a term from the field of statistics. I love this sentence from the Wikipedia article on sampling bias:

A biased sample causes problems because any statistic computed from that sample has the potential to be consistently erroneous.

You handle carryover by letting it accurately affect velocity, whether that effect is positive or negative.

The purpose of tracking velocity is to provide feedback on how well a team can estimate, break down, and execute work within a fixed interval. Carryover implies a need to improve in one or more of these areas. When a team has a drop in velocity, be sure to talk about it in the retrospective. Are stories too big and bulky? Do tasks sit for days on the board waiting for the next handoff? It the team consistently over-committing during Sprint Planning, hoping for unrealistic throughput?

Allowing a skewed velocity sets a team up for disappointing its stakeholders. If velocity looks higher than reality (inflated velocity is far more common than deflated velocity), stakeholders are going to have expectations that cannot be met. Embrace the bad news, and use it to reinforce the message that our only hope is to get better at working together as people.


Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.

Ask an Agile Coach: What do I do with a sprint that ends with only incomplete stories?

Today’s Ask an Agile Coach submission comes from Jake Gordon via Twitter:

Anyone (@barryhawkins)  have any good articles on reaching the end of an iteration with only partially completed user stories? #agile

What do you do with a sprint that ends with only incomplete stories?

When a sprint ends and every story is incomplete, it is typically a symptom of one or more of the following underlying causes:

  • The stories were all larger than the team had estimated due to lack of cross-functional participation in the story writing and estimation process.
  • Team members kept switching between stories instead of focusing on single ones, completing them, then moving on to the next in priority. Minimize work in process (WIP).
  • Core parts of the process are being left out, such as a highly-visible task board, a burndown chart, effective daily stand-up meetings, etc.; as a result, feedback and handoffs are unnecessarily delayed.
  • The team is working on a platform or problem domain that is new, and its estimations are commensurately less accurate, leading to over-commitment.

When a sprint like this happens, effective retrospectives are essential. Ensure that all parts of the process have transparency. Visibility into how work flows from concept to customer is necessary for inspection. Use the insights gained from inspection to guide an incremental, sustainable rate of adaptation. Strive to eliminate waste and improve communication.

A single sprint where nothing gets completed is a warning sign that should not be ignored. Multiple sprints where nothing gets completed calls for a full-blown intervention. If you can’t get out of that rut on your own, seek external assistance.


Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.

Ask an Agile Coach

I never have a shortage of people with questions about applying Agile in the myriad possible scenarios of software development for business. This ongoing series focuses on answers to those questions.

If you would like your question to be anonymous, please let me know when submitting. I’d recommend email or a Twitter DM since you kind of let everyone know it’s your question if you use the other methods of contact. :-)

Have a question? Submit it via Twitter, LinkedInFacebook, or email to blog at barryhawkins dot com. I look forward to answering them here!

Agile with External Clients: Master User Story Facilitation

The Agile with External Clients series continues today with the topic of requirements facilitation and management, with user stories as the primary vehicle for the task. This article’s mantra is captured by one of my favorite phrases around Agile, which comes from the last sentence of the Agile Alliance website’s entry, What is Agile Software Development?:

…to craft the code and the team such that the inevitable requirements churn was not a crisis.

This is the core difference for me between Agile Software Development approaches and the phased, non-iterative processes that dominate much, if not most, of the industry. Over the years, the most effective tool I have had in my arsenal for transitioning groups into more iterative, collaborative approaches to gathering, refining, and prioritizing requirements has been user stories. When I say user stories, I am referring to the format and philosophy laid out by Mike Cohn in his indispensable book User Stories Applied: For Agile Software Development. I am not referring to the user stories as defined in Behaviour-Driven Development (BDD), but that is another topic for another time.

As a consulting or professional services group, your clients will rarely see your team using the more technical and development-centric aspects of Agile and Scrum, unless you embed delivery teams on-site at the client. Even then, the focus of their interaction with your team is translating needs into working software. In light of that, everyone on your team needs to master the art of user story writing and facilitation.

For your clients to truly understand the power and flexibility of an Agile approach, they need to feel the difference between handling requirements in Agile and however they have been doing them before. If they are accustomed to heavy up-front design, analysis, and specification, they need to see how this approach doesn’t require that they pretend to know the future, just enough to know the core of what they build and how much they want to initially invest. Together, you can knock out those key pieces of functionality and decide what else to add collaboratively, with the invaluable insight of seeing part of the application working already.

If the client has been handling requirements with a complete lack of process, with managers or stakeholders delivering requirements by walking up to a programmer’s desk, expert user story facilitation can show them how a bit of lightweight structure and cross-functional interaction serve to flesh out requirements in a way that weeds out those painful gotchas that so often plague the last stages of a project. A product backlog of concise, easy-to-read stories also paints a clearer picture of how much functionality and effort they are throwing into this project. I have found this provides a context for discussing choices and scope management with clients like this who are accustomed to a more chaotic mode of operation.

To master user story facilitation, your team members need to focus on a few key skills. First, team members need to be excellent at writing user stories, and the only way to do this is practice. Pair newcomers with veterans so they can watch and learn from them. Do you have internal projects for frameworks you develop and maintain? Make yourself express the work as user stories to get realistic practice so that your group doesn’t have to start their learning in front of the client. After all, you have a very narrow window to solidify trust with clients; more on that in another installment.

Second, team members need to develop prowess as user story facilitators. They must guide and encourage open discussion in a cross-functional group. This requires exceptional interpersonal skills, which should come as no surprise. Use the The Principle of Slices Instead of Layers to guide the group out of the tendency to express effort in terms like “the dev work”, “QA’s part”, and “the DBA tasks”. Guide the group toward expressing effort in bits of user-centric functionality that will involve all the cross-functional tasks as emphasized in The Rule of Concept to Customer. Are the stories centered on a group of services? Fine, the remote client that calls the service is the customer. When a facilitator leads a group through this transition, the result is an approach to requirements gathering and refinement focused on what we are making for our users and accounting for everyone’s contribution in making that happen.

There’s plenty more to say about facilitating user stories successfully, but we’ll stop there for now. Just remember that expertise with user stories will be one of the most direct ways to show customers that this is a refreshing and effective approach to managing requirements that makes the most of their valuable time and the money they are spending with you.

Agile with External Clients: To Run It Agile, Sell It Agile

This installation of the Agile with External Clients series shows the relationship between how an engagement is sold and how that affects a group’s attempt to execute the project using an Agile approach. Let’s start with a maxim for every member of a professional services group or consulting practice to burn into their mind:

The Sold Destiny Principle

The way something is packaged and sold frames the expectations of the customer.

One of my first questions when engaging with a new client is “How is your product/service sold?” This is an important question because of The Sold Destiny Principle. If services are being sold in a way that does not dovetail seamlessly into how those services are delivered, the team builds friction into the way their work is done, heaping frustration upon all parties involved, including the customers.

Many professional services and consulting engagements are sold through a fixed-bid approach. A prospective client drafts a Request for Proposal (RFP) which includes a writeup of what they (think they) want, and firms then take the RFP and respond with a proposal document. Unless a group’s focus is competing on a commodity level, this is a horrible approach. This drives the value proposition straight to price with marginal consideration for skill and quality of the solution delivered. A consulting group can look at an RFP, frame what they believe it would take to deliver a quality result, and the conversation stops there. The customer is then left to decide from a collection of proposals whose differences amount to who is cheapest, which proposal is the most aesthetically appealing, and which groups the customer has worked with in the past. (There is a fourth differentiator, which is how much schmoozing the salesperson has done. This is a horrible and costly way to compete, and generally conveys a lack of confidence in one’s product. But, I digress. Let’s save that for another post.)

The tragedy here is that it appears to the customer that every option carries all the uncertainty and false precision of phased approaches to software development. This is not the case. The salesperson whose delivery team uses an Agile, iterative approach has a keen competitive advantage. If you want to run your projects in an Agile manner, equip your salespeople to press this advantage.

The Agile practice that has not reached out to their salespeople must shoulder most of the blame for the friction between sales and delivery. After all, the salesperson is going on what they have known for their whole career and the approach to which the industry at large defaults. The cross-functional focus of Agile in general and Scrum in particular exists for a reason. Cross-functional participation in the Agile process enables a company to embrace The Rule of Concept to Customer, which most certainly includes your salespeople.

Due to the rigid, transactional nature of a fixed bid process, the contents of an RFP give a false impression. It’s a concrete description based upon a collective conscious from a group that has never seen the very thing they are attempting to describe. The requirements all appear to be must-haves, and are based upon having seen nothing. The truth is that it is a collection of must-haves and might-wants, liberally dressed with a not-so-sure vinaigrette.

An Agile engagement allows the salesperson to say something like this:

“Look, I know this RFP probably has things you know you need, plus some things you aren’t so sure about. Instead of you guys locking yourself into this 6-month heap of work, what if we broke it down into smaller blocks of investment, say 2 months in size? We’ll break these requirements down into the must-haves and might-wants, and get started on the must-haves.”

“Every 2 weeks we’ll show you the working software we have developed so far, and then we can talk about what you want to put into the next 2 weeks. You can switch up the priority on the items, and if you want to push some of them out and pull an equal amount work forward from the lower-priority work, that is not a probelm. It’s your 2-month block to spend as you want in 2-week increments.”

“As we close in on the 2-month mark, we’ll take a look at this together and see if you want to invest in the next 2-month block. If you don’t that is OK. You take the working software you have so far and run with it. If you want to continue, we’re more than happy to keep delivering new working functionality in 2-week slices for another 2 months. We’ll repeat that evaluation and decision process for the third block, and by the end you have a product that you have been able to shape as we go based upon seeing the working solution evolve and deciding what you want to put into it.”

I have seen that approach work very well, and it generates a loyalty among customers and a reputation for being a breed apart among consulting companies. Looking for the best way to run consulting engagements with Agile? Sell them with Agile.

Agile with External Clients

I speak at conferences around the country each year, most often on the topic of real-world, full-blown application of Agile Software Development using Scrum. I always appreciate when folks come to me after the end of a conference talk to ask questions about the topic of adopting or applying Agile in various scenarios. I usually end up having at least a couple new challenges to my assumptions, which helps me further inspect and adapt my approach to coaching and mentoring.

I will almost always have at least one person who presents what they think is the tough question, the one area where Agile and Scrum simply cannot work. The question, in the form an assertion, usually goes something like this:

“This stuff is all well and good when you are working inside a company and your clients are the people that work with you in the same company, but our clients are external customers, and we have fixed-bid projects, which is why we cannot use anything like this.”

The embedded question in statements like the one above is, “Can Agile, and Scrum in particular, be used when you do professional services work for external clients, even with fixed-bid projects?”

Yes, you can.

The person who presents me with a statement like that is usually dumbfounded when I respond that at least a third of my clients are consulting practices and professional services firms that do exactly what was just described. Not only can you do it, there are many scenarios where you should do it. Using an Agile, iterative approach to professional services engagements can be a formidable sales tool and competitive advantage.

In the coming days I will be sharing some insight on the nuances of adopting Agility with external customers based on my years of experience working with clients who have done that very thing.