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.

Still a place for blogging

A few years ago, my blogging fell off sharply. There were multiple reasons for that. I began to spend my discretionary time elsewhere, including with my young child and playing World of Warcraft with my wife after the little one was asleep. Additionally, I began to lose interest in some of the main topics I had been writing about, in particular my involvement in the Debian project.

At that time, I began to wonder if perhaps blogging had become passé. Jokes about the ubiquity of banal blogs seemed to show up everywhere. I had adopted Twitter and Facebook fairly early, and I thought for some time that perhaps these social networking outlets were the successors to blogging.

They are not.

Blogging has always been a sort of mental sketchpad for me to tease out concepts, observations, and reflections that were too nascent at the time to make their way into a paper or a conference talk. I cannot think of any of those that would fit into a Facebook wall post, much less a 140-character tweet. I would find myself with an idea or thought in my head, but trying to cram it into these newer forms was so daunting I’d just let it pass. If I did try, it felt very constrained, like trying to give directions to your house in haiku or drinking a Wendy’s Frosty through a coffee stirrer. So, I have concluded that a blog still has a place for me, and some recent posts from other folks in my field lead me to believe that I am not alone in that viewpoint.

Any of you who used to read my stuff back when I was active will notice that I am no longer hosting this under the yepthatsme.com domain. My full name was not very prominent anywhere on the site, and now it’s in the URL. This was a change I had pondered before, but the advent of social networking made me certain I should go ahead and make the switch. Anonymity is increasingly scarce on the Internet, and since I’ve said more than enough out there to implicate me, I might as well embrace the trend.

So, welcome (back) and thanks for your time!

The Agile Business Analyst

Agile Business Analysts?

I have recently been fleshing out my thoughts on the role of business analysts in an Agile team. This is something I have historically addressed on a case-by-case basis with clients, but when thinking about it last week at a client site, I realized that I do have a general take on how the role and responsibilities of a business analyst change when a group moves to using an Agile process. Per the usual, I’ll be using Scrum as the example process where needed.

The Classical Roles

Historically the business analyst has had two primary roles. In a process where cross-functional communication and collaboration are minimized, these roles are essential. What little communication that takes place between the business and the software development teams purporting to serve them passes almost exclusively through one or more business analysts. I view the business analyst in a phased development approach as having two roles; Translator and Gatekeeper.

The Translator

The business analyst is primarily tasked with taking the needs of the business and translating them into a written document that is then handed to the software developers and testers. This role’s necessity is based upon some fundamental assumptions. First, programmers and testers are on the whole, too socially retarded to actually talk to the business persons and find out what they want. Second, the business is primarily viewed as being unable to focus its thought long enough to tell the programmers and testers what they need. Since a key value of an Agile approach to software development is to have individuals and their interactions be the driving force rather than processes an tools (see The Agile Manifesto), the obliteration of this role is a primary objective.

The Gatekeeper

Business analysts are also viewed the gatekeepers for requirements in classical, phased software process approaches. This is a somewhat unfair role, since they rarely have the authority to prevent business or technology changes, like a meter maid trying to stop an armed terrorist. It’s even more unnatural since change always happens, so it’s like the meter maid being assigned to an anti-terrorist unit with no additional training, authority, or weapons.

The Agile Roles

Some of the more extreme practitioners of Agile methodologies say that business analysts have no role in an Agile team. I disagree, provided the role of the business analyst is allowed to evolve. The roles I’ve seen them take on as valuable members of an Agile team are Facilitator, Historian, and Journalist.

The Facilitator

A high degree of collaboration and interaction take place between business and technology in Agile Software Development. The business analyst can serve a critical need in these interactions, facilitating communication between business and technology and making sure that critical areas are being covered in an interaction. This can be a more fulfilling experience for an analyst, since they often talk to one side, then go to other to pass on the information, all the while thinking, “Man, this would be simpler if you were both in the room with me at the same time.

The Historian

The business analyst’s documentation skill is excellent for capturing significant information that often gets lost in a team of purely technical people. I have seen some great uses of business analysts in this area. One is to document the system that the team actually builds (not the big, up-front imagined system that is covered in a phased design stage). Another is capturing key technological and architectural decisions and the context in which they were made, so that when a group revisits certain items asking, “Why in the world did we decide to do that?”, they have the means to be reminded or informed why a particular path was chosen.

The Journalist

The business analyst can also be the team’s journalist, making sure the latest information makes it out to all interested parties. One creative approach I’ve seen at a client site is a business analyst who has a project blog. He posts entries after each meeting between the business and technology, documenting what new user stories were created (even scans in the story cards!), a summary of the discussions held, and documents any key decisions that might have been made. Oh, and he provides an excellent executive summary at the top that’s suitable for anyone’s review, right up to the CEO. Tell me you wouldn’t love to have that guy in your Agile team.

More Expensive and Complicated Equals Better: Carseats and Software

So I finally got around to checking out the TED site; I’ve quickly become a fan. One of the first talks I watched was Steven Levitt’s child carseats talk. Both the talk and the feedback comments on the TED site reminded me of things I see in software development. Here’s the video if you haven’t seen it.

Steven Levitt shows in his talk how 30 years of data on car crash fatalities imply that carseats do not outperform regular seatbelts for children ages 2 and up. Anyone who has a child or grandchildren will probably bristle at hearing that; as the father of a pre-schooler, it certainly gave me pause. We spent no small amount of time and decent chunk of money in selecting carseats for our child, thinking we had done our best to ensure our child’s safety. For that matter, it would be illegal for us not to have done so. To see a decent-sized data sample suggesting my child would be better off in a seatbelt at her age is rather unsettling.

By the end of the talk, I took away these observations:

  • This great swath of an initiative was started by a very small yet vocal group of proponents whose assertions received little scrutiny.
  • A solution tailored to the specific constraints of a portion of the audience has been put forth as the de facto solution for the entire audience.
  • There is an ongoing assumption that the more complicated and costly solution must be superior to the simpler, existing solution.
  • Cursory evaluation of a data set without rigorous attention to mitigating factors can lead to wildly inaccurate conclusions.
  • The acceptability of a given solution is often tested against a narrow band of the overall criteria, and the solution is often optimized to pass that test.
  • The likelihood that people will continue to choose the more expensive and complicated solution despite any data is high.

So, software professionals, does any of that sound familiar? It reminds me of numerous initiatives over the years that have led us inexorably to the software productivity morass we have slogged through for years now. I suppose the most heinous case study in my own experience would be J2EE and the insistence that it was the solution that any reasonable business application would choose for a platform. (Before you .Net folks jump on that one, DCOM and later the .Net enterprise stack was much the same.) And who hasn’t read a benchmark or white paper with seemingly incontrovertible data depicted in highly-polished graphics insisting that Product Y is the one solution to address them all?

I noticed that there were comments below the video on its page at the TED site, largely because the negative verbiage of the topmost comment jumped out at me. I took the time to read through them all (there were 36 at the time of this writing), and to my amusement, I saw parallels between them and how people react to questioning and examining our existing practices and means of developing software. See if any of these strike a chord:

  • The idea that what we’re doing might be wrong unsettles some people, and their response is often ferocious and irrational defense of the status quo.
  • Those who have a financial stake in the current mode of operation are less likely to be open to scrutinizing it.
  • There will be some people whose primary objection to the scrutiny is that they didn’t think of doing it first; these people will sometimes attack the person questioning things on the grounds that it’s all a selfish, attention-mongering endeavor.
  • There are some people who will also be open to examining why and how we’re doing things; whether they conclude the same thing or not, they are a welcome presence among the larger mass of those who ardently refuse to entertain the possibility of a need to change.

In recent years I’ve been greatly encouraged by the willingness of companies to question whether or not the heavyweight frameworks and technology stacks are what they should be using. Helping companies slough off high-ceremony processes in favor of right-sized process that focuses on delivering the right software in a timely manner has been some of the more rewarding work I’ve done the past several years. I think we have an encouraging number of people in the industry who are challenging the “more expensive and complicated always equals better” mantra.

For the brave individuals willing to put these questions to the community at large, I hope you find some comfort in knowing that the resistance and rejection you will encounter is a thing to be expected; you are not alone in that respect. Here’s hoping we continue to be open to self-examination, no matter what emotional responses it might provoke or what fear of the future it may stir up within us.

Just When a Wizard Would Have Been Most Useful: Coaching versus Contracting

…Then they stopped, and Thorin muttered something about supper, “and where shall we get a dry patch to sleep on?”

Not until then did they notice Gandalf was missing. So far he had come all the way with them, never saying if he was in the adventure or merely keeping them company for a while. He had eaten most, talked most, and laughed most. But now he simply was not there at all!

“Just when a wizard would have been most useful, too,” groaned Dori and Nori (who shared the hobbit’s views about regular meals, plenty and often).

- J.R.R. Tokien, The Hobbit

I am very fond of the works of J.R.R. Tolkien; it would not surprise me to find that many of you recognize these words from the second chapter of The Hobbit titled “Roast Mutton”. It occurred to me recently that there are parallels between Gandalf’s role in The Hobbit and that of an Agile coach. Now, before my fellow Tolkien enthusiasts leap on their keyboards, bear with me on this. Know that I am not saying an Agile coach is on par with a wizard (OK, with one of the Istari sent by the Valar, but let’s table that so as not to scare off the normal folk, alright?); that should be enough to calm you down.

In the excerpt from The Hobbit at the top of the page, Bilbo and the dwarves have run into their first predicament. Note that it’s not a particularly difficult situation; they just need to find shelter and partake of some food. Fire would be nice, too, if it could be managed. (Mind you, it’s the first day of their journey; they set off mere hours ago fully provisioned and riding on ponies.)

It isn’t very long before the fledgling group finds itself not only without shelter and food, but in the hands of three rather nasty trolls who are deciding how best to eat the entire group. Gandalf returns once things have gotten out of control, and with some subtle adjustments to the situation, the crisis is averted.

Could Gandalf have come back sooner and spared them this entire experience? Perhaps, but in their struggle a few key things happened. First, the group had to work out how to assess tasks at hand and appropriately delegate. To their credit, that effort was partially successful. The most skilled firestarters were assigned to that task, one of the keen-eyed dwarves was assigned to be the lookout. Second, they gathered some field experience that led to the establishment of improved practices, i.e. don’t leave the ponies laden with packs when you make camp, particularly if it’s all your food. (They lost most of their food that night when the pony carrying it bolted and ran straight into a nearby river later that night.)

Third, Bilbo Baggins was called upon to perform his first task as burglar, albeit a fool’s errand that landed them in the troll predicament. While Bilbo was wildly under-equipped for his job, he managed to work through it. That experience began a developmental journey that would prepare him for the great things that would be expected of him later on.

This was not Gandalf’s first adventure, nor was it the first group of people he needed to equip and challenge in order to develop them to a point that they could accomplish their goal. At this point, he’s been in Middle-Earth just shy of 2,000 years. He would have been more than capable of walking them through their entire journey, but to what end?

Agile coaching is a discipline that aims to help teams develop their own use of methodologies like Scrum and cross-methodology practices like testing, user stories, etc. This means equipping teams with just enough information to strike out on their own for a bit, then letting them run with it rather than dazzle them with one’s own mastery so as to appear like the indispensable demigod. Until people struggle with the terse maxims of Agile Software Development, they cannot internalize them. And when the wizard is always around, why bother struggling?

One of my greatest frustrations as an Agile coach is how few companies are willing to take a coaching approach with their Agile adoption. They want you to come in and be the demigod as a full-time contractor. Sure, there are fiscal, political, and seemingly practical reasons that they will cite; I chalk most of them up to being excuses for a lack of willingness to embrace what it would take to face the hard task of nurturing what you have. It’s seemingly easier to just throw more money at more bodies and hope that somehow things will all work out, and surely if you can stumble upon some superstar to wrangle the mess, you’ll eventually be able to browbeat them into becoming a full-time employee.

Don’t get me wrong; in some ways, I benefit from this dysfunction. From a selfish business standpoint, having a single full-time client is certainly easier than juggling multiple concurrent clients and their schedules. As far as actually accomplishing the aim of my business, however, I think it hinders the mission.

One of my aims in working with companies is to be a coach despite being brought in as a contractor. It’s certainly possible, though it is more challenging. There’s not that natural separation of the coach from the team that forces them to take up the mantle on their own. Few things in my work are more rewarding than having a developer come to me and say, “I wasn’t really sure this Agile stuff could work, but now, after going through all this, I wouldn’t want to go back to the old way of doing things.”

Much later in the journey of the hobbit and his dwarf companions, Bilbo is again called upon for a challenging task. His response makes me think Gandalf’s approach has worked:

“…Perhaps I have begun to trust my luck more than I used to in the old days” – he meant last spring before he left his own house, but it seemed centuries ago – “but anyway I think I will go and have a peep at once and get it over. Now who is coming with me?”

- J.R.R. Tokien, The Hobbit

Here’s hoping more people will be willing to embrace the challenging, messy, and altogether beneficial task of equipping teams and allowing them to struggle when necessary, even if it means the occasional scuffle with trolls.

Technology, process, and culture in software development