Agile and Delivering Features

Question

At my company, we have adopted full Agile methodologies and related tools.

We plan our sprints based on a set of customer requested features by the end of the sprint. Commonly, we do not deliver the features requested by the customer by the end of the sprint and we push to future sprints.

This has me concerned because of the bow wave we are creating with a backlog where the backlog grows of problems and features keep getting added. The customer wants both problems addressed and features developed with no relief on either.

I know that Agile means to deliver working software faster.

How does Agile address this case where we have hard deadlines to eventually deliver features that may be pushed ad infinitum?

This has to do with technical debt; however not whether to schedule as a feature or a bug. It has more to do with how long is too long to push features to the right.

I have tried holding sprints open and my team has disdain for this approach because they say it affects their metrics for velocity.

Possible duplicate of [Should technical debt be scheduled as a feature or a chore (or a bug)?](https://softwareengineering.stackexchange.com/questions/78998/should-technical-debt-be-scheduled-as-a-feature-or-a-chore-or-a-bug) — gnat, Nov 01 '17 at 11:56
*"based on a set of customer requested features"* - and are you taking into account *what you can actually deliver*? The point of sprint planning is to commit to a deliverable amount of work so that the engineers and the product owners can agree on what's the highest priority to focus on over that period. If you keep failing to deliver you're right to be concerned, something is going wrong. Using agile methodologies doesn't make you magically faster, the point is to shorten feedback loops. — jonrsharpe, Nov 01 '17 at 11:56
"we have adopted full Agile methodologies and related tools" No, you did not, as there is no list of Agile methodologies that you could consider adopting whole. And that Agile doesn't define any tools to be adopted. — Euphoric, Nov 01 '17 at 12:26

score 7 · Answer 1 · answered Nov 01 '17 at 11:44

Sprints in the main should be the same size - there are occasional exceptions but extending a sprint to complete work is solving the wrong problem.

If you aren't completing sprints - you need to understand why. Are you committing to too much work? Are stories being sufficiently groomed? Are blockers left to fester? Do you have a bottleneck of certain skills? Are developers fully committed or do they have other distractions (other projects, support, admin etc)? All this should be addressed in the retrospective.

Next, you need to address how you carry items over. Are they simply bumped as they are or can the story be split.

The elephant in the room seems to be that you're committing to continuing work on incomplete stories while agreeing to extra work. I'd nip this in the bud right now. You need some form of triage where the customer agrees what the priorities are otherwise your sprints will become more and more unachievable.

'Sprint' degenerates to 'slog' which eventually becomes "death march". Agile does not allow one to outrun problems, apparently. — , Nov 01 '17 at 14:27

score 4 · Answer 2 · answered Nov 01 '17 at 12:38

4

You claim your team is "full agile" but you keep putting things in sprints that won't get done according to your history. You can be agile, but you're not going to be very good at it if your client is not. Your case is a perfect example of how that doesn't really work.

In the Agile Manifesto, "...marketing, or management, or external customers, internal customers, and, yes, even developers—don’t want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures. This isn’t merely a software development problem, it runs throughout Dilbertesque organizations."

Planning a sprint should take into consideration how much work you've been able to do in the past and not how much someone "wants" you to do. That's the trade-off decision. At some point you have to tell the client how much work you can get done and nothing more. If you keep getting less done, you have to promise less. Hire more or better programs.

Do your client a favor and learn how to say no up front instead of after the sprint when you've failed to deliver. Your client's demands are irrational because your company is not helping them manage their expectations.

answered Nov 01 '17 at 12:38

JeffO

36,816
2
57
124

But if they say "No", then the customer will find another developer, who doesn't say "No". /s – Euphoric Nov 01 '17 at 12:44
@Euphoric but if the promised work simply cannot be done in the desired time, by anyone, then those "other developers" fail, and the customer comes back to you, now much delayed and dispirited, but hopefully wiser. I have seen this enough times. You don't need to solve the problem of others making stupid deals, just wait for them to fail. – Nov 01 '17 at 14:30
1

@nocomprende did you really see customer come back? Do you have any details about such cases? After how long they came back? – Euphoric Nov 01 '17 at 14:49
1

@Euphoric - that's not entirely true. You don't have to say no to everything. Customers will ask for many things on any given project and have them rejected.What makes clients more upset is if you keep saying yes and fail. – JeffO Nov 01 '17 at 19:01
@JeffO I do agree that is how it should be happening. But being cynical myself, I often hear about customers who just can't accept the idea that they might be requesting too much. – Euphoric Nov 02 '17 at 06:37
@Euphoris The gist of it is: in your professional life, do you want to be paid for creating software or do you want to be paid for satisfying customer's higher-ups. That's *your* business choice to make. – kubanczyk Nov 02 '17 at 08:26
@Euphoric - customers will constantly push for more features and they'll want to pay less - that's part of negotiation. What I dislike even more, is working for companies that know they are lying to customers. They put the unrealistic expectations on the development team. Often, they don't even bother to push-back on the client. They just take the order and blame the programmers when it doesn't get done. – JeffO Nov 08 '17 at 14:24
@kubanczyk As a software developer, my only choice is working for an employer who says "yes" to any customer. Or flipping burgers. And as much as I would love to work for reasonable employer, I'm having really hard time finding any. /rant – Euphoric Nov 08 '17 at 14:38
@Euphoric I beg to differ. You *can* say no, and customer's higher-ups *can* say no, the rest of people are intermediaries who always avoid risk and usually tends to agree with everyone and everything. You, personally you, delegate all your personal power to some mythical angry god named "employer". Note that I've got a mortgage and two children and I'm not a millennial :) The first and second time I said "no" I had to face some fuss. Since then my intermediaries knew to ask nicely up front. – kubanczyk Nov 08 '17 at 16:19

score 3 · Answer 3 · answered Nov 01 '17 at 12:21

Having a large amount of carryover between sprints is a sign that stories were not properly groomed, fixing this requires a lot of work with the product owner to clarify requirements and create a firm definition of done. Some of this may be how you plan your sprints, they should only be as big as the amount of points you actually delivered in the past, not just everything that a customer wants now. If you have a product owner that wants more in a sprint than you know you can accomplish you need to push back and get the properly prioritized set of stories that fit your sprint size and take on no more than that. In a scrum/agile methodology its the responsibility of the dev team to ensure that they manage the size of a sprint to only be as much as they can do.

You seem to also have a belief that Agile means delivering more faster or your customers have that belief. This is not true in the sense that most people believe it to be. When agile people say they deliver working software faster they are constraining working software to be only what was in the sprint or previous sprints. You can deliver a site that has a working payment system faster, but its not going to have search, reviews, photo galleries, wish lists, etc. Agile guarantees working software faster, not necessarily feature complete software faster (though that can happen with a mature team).

The agile process isn't super great at explaining how hard deadlines are managed, it's generally more implied. It's managed by taking the estimated story points of the feature and using velocity to work backwards to get the latest sprint that these items could go in to deliver on time. If features are not high enough on the backlog to get into sprints before they can be finished on time it needs to be brought to the attention of the product owner so they can prioritize accordingly. Ensuring your backlog can prominently display deadlines for items or having a separate tracker for deadlines that is reviewed regularly during grooming are good ways to keep on top of these things. Your product owner will work with you to prioritize work to meet deadlines that are truly important, sometimes you may need to actually miss a deadline that you said you would for them to understand you can only fit so much in a sprint (I'm not advocating doing this on purpose, but sometimes people need a wake up call or teams are overly dramatic about deadlines).

As far as managing technical debt goes, the only real way that will work is to enforce the boy scout rule of improving code as you go and baking that in to estimates. Pure tech debt stories can be created, but its extremely rare that they ever hit high enough priority to be worked on. Other options like occasional maintenance sprints, or setting X hours a week as clean up/free time/training tend not to work as well since there will be pressure to use that time to work on higher priorities.

Agile and Delivering Features

3 Answers3