6

I'm part of a development organization which has traditionally been using Scrum principles. We have 3-week sprints, at the end of which we produce a software artefact which our customers install on premise, and at their own discretion. Most customers have chosen to skip every odd sprint, and thus only install every 6 weeks.

Now we have a new, large customer, with several branches which will - or already are - use our software. Each branch has slightly different requirements, and a tight schedule to production.

What we're seeing since a few months:

  • Our development team spends less than 50% on backlog tasks
  • Daily business is heavily influenced by ad-hoc support tickets (which can concern defects, database cleanups, training the users, or simple cause analysis)
  • Every week we build service packs for already delivered releases. Thus a defect is committed to master, but then cherry picked to one or several older branches.
  • The time required for above support tickets and service packs will increase in the next 2 years, after which it hopefully will decline again
  • Our customers tend to not give us quick feedback, we have a feedback loop lag of sometimes several months

-- Edit reg. branches --

We do develop on origin/master. But say we're currently developing release 5.0.12, and have a bug fix or feature which the customer urgently wants on 5.0.10. In this case we cherry pick the patches to 5.0.10.1 and 5.0.11.1. There are no customer-specific branches, everyone gets the same software.

-- End of edit --

I'm pretty sure Scrum is not a good fit anymore for this kind of work. I'm not proficient with DevOps, but my understanding is that it is heavily built upon rapid and frequent deployment. If my understanding is correct, that also wouldn't fit.

Are there any best practices how to deal with this? Should we:

  1. Split support and development, and keep Scrum for development? (a dedicated support team is planned)
  2. Switch to Kanban (but keep ad-hoc support and development mixed)?
  • 3
    No process or methodology is going to fix "sour" relationship with your customer(s). It feels to me, that at the moment, relationship is one-sided, with client dictating what he wants and you doing exactly as he wants. It is fine to please your customer, but you should have some say in what is done too. – Euphoric Jul 30 '18 at 7:45
  • I'm not sure whether we can really help you here, but if your work doesn't fit a fixed time box like sprints in Scrum, then the agile/kaizen thing to do is change your process to fit your requirements. Two thoughts regarding your suggested solutions: (1) what would be the impact on morale and efficiency of splitting maintenance from development? Two teams working on the same code base without clear ownership could lead to conflicts. (2) Kanban doesn't force you to completely mix development & maintenance. You can use swim lanes to limit how much of each kind you are currently working on. – amon Jul 30 '18 at 7:51
  • 5
    The problems you highlight will not magically be solved by switching away from Scrum. In fact, Scrum is doing its work by making it felt where there are impediments to working in an optimal way in your organization. Those problems are part of the organization, not the methodology you choose. – Bart van Ingen Schenau Jul 30 '18 at 9:07
  • What percentage of your support issues are bugs? As how many of them result in a code change to fix a defect and how many are questions/scripts etc? – Liath Jul 30 '18 at 9:47
  • 1
    @Liath, last month we had 16% of support issues tagged as defects. We have a large number of issues (28%) originating from release management issues (eg. version containing fix was not yet installed), plus a substantial part for training (19%). – Simon Jul 31 '18 at 8:14
7

No. Scrum is designed to fight exactly the issues you are experiencing.

You could switch to a reactive approach fixing bugs as they are reported as quickly as possible, but this comes at the cost of predictable completion dates and often the stability of your software.

I would say you should push back, ensure all requests go in the backlog and are prioritised. Increase the amount of time spent testing, ensure that what you release is exactly what was asked for and has no bugs. You are better off doing a single monthly release with zero defects, than 4 buggy weekly releases.

However, I would also say, 3 weeks is too long for a sprint. Move to 1 week sprints.

Stop Cherry Picking! Merge bug fixes in to branches. Try to move towards a single codebase, not away from it.

Hire more people. whatever methodology you choose there are only so many hours in the day. If you have more work, you need more people.

Re: Sprint length

With any sprint system the turn around time as at minimum three sprints, ie the customer sees the result of sprint 1, has a play, suggests changes which go on the backlog during sprint 2, which are maybe maybe completed in sprint 3.

In this specific case the customers don't always install every sprint, and dont get back promptly so they would be looking at installing after 6 weeks, reporting problems say on weeks 9-11 for implementation by week 15 and then installation of the fix on week 21. That's almost at 6 month cycle.

If you have a week long sprint, then a customer can install on week 6, get their requests in for week 9-11 and install the fixes on their next 6 week cycle on week 12. A much faster cycle.

Going shorter than a single week sprint isn't practical in my experience. Just in terms of the cadence of business and a working week. 'done by next week' is acceptable, 'done in two weeks, because we are working on your other stuff atm' is understandable delay. 'done in 4 weeks, because SCRUM' is unacceptable.

  • You suggest moving to one week sprints but don't explain why. Could you explain why you think one week sprints are superior to three week sprints in this specific case? How does shortening the cycle help? – Bryan Oakley Jul 30 '18 at 12:42
  • @BryanOakley added some more on this issue – Ewan Jul 30 '18 at 13:00
  • Great input, thanks! The 1-week sprint would also much more reflect our actual work style, because the customer does indeed push new tasks into our sprint on a weekly basis, demanding delivery (via service pack) within 7 days. – Simon Jul 31 '18 at 8:18
4

I am not sure you have quite precisely put your finger on exactly what the problem is, especially due to having taken on the new large customer. Are you starting to miss sprint goals/ deadlines? Are you seeing quality suffer? Are you seeing throughput/ velocity drop? Are you losing new prospective customers to competition because you are no longer working as much on your backlog tasks (which I assume are related to your roadmap)? What has changed, other than the fact that due to the new customer, your work mix has changed to more maintenance/ bug-fix type of work? And that you are concerned your lead time to fix issues might go up in the near future?

Having a large number of customers who are giving you feedback is a good thing! And not being able to - at least temporarily - work on your product roadmap is not a bad thing. Perhaps, this is the time to put your house in order, learn about and implement DevOps, get your test automation in place, reskill some of your team members.

Here, Kanban can help you in doing so. You don't have to give up Scrum, but use Kanban on top of that (Scrumban as many people call it), to help you improve and resolve issues. Kanban can help in several ways -

  1. It can help visualize your process - and work - on a Kanban board in more detail than is perhaps currently being done, to help you highlight which steps in your dev and deployment process might be the bottlenecks.

enter image description here

  1. It will start giving you data on your current performance to help you benchmark important metrics such as lead time and throughput and help you setup improvement goals. More about Kanban metrics here.

enter image description here

  1. If you are worried about increased lead time, due to too much work, Kanban recommends implementing WIP (work-in-progress) limits that you can implement at each stage of your workflow, to encourage your team members to finish what they already have on their plate before taking up the next work item. Limiting WIP will help you improve throughput and reduce cycle time.

enter image description here

  1. Kanban also gives you the ability to visualize and manage different types of work - customer work, backlog or roadmap work, technical debt, etc. - using different swimlanes on a Kanban board. That way, both the team as well as your stakeholders, get a full picture of just how much work there is across these different categories, that the team can take up when they have spare capacity. Kanban's "class of service" categorization of work into Expedited, Standard, Fixed Date and Intangible, helps everyone also understand what might be the cost of delay associated with each of the work items the team is expected to do, and perhaps discard stuff that has low or no cost of delay.

enter image description here

Given the complexity of your current situation, you could implement WIP limits both at column-level and for specific swim-lanes.

  1. Before you do any of this, you, of course, need a discussion - multiple discussions perhaps - with your dev teams and your stakeholders to understand what and where the problems are, and what you need to do to resolve them. These should help you come up with explicit policies - something else that the Kanban Method recommends - to deal with the backlog tasks vs. customer feedback, perhaps changing your sprints to every 2 weeks, and making a customer release only every 3 sprints, making capacity allocation to each type of work, taking a regular look at your overall backlog and prioritizing the top 5 or 10 items to be taken up next, etc.

There is no question that Kanban can help you analyze and improve your current dev management practices. You don't need to necessarily give up Scrum for that. If you'd like to learn more about Scrumban, you can look up here.

HTH - all the best!

2

There are a few things in your question which make me think that this is more than a process problem. There are already some great answers about work item management.

I agree that measuring Lead/Cycle times is the best way to analyse support efficiency but make sure that you measure these times from when the customer opened the ticket until it's closed in the customer's environment. Vanity development metrics mean nothing, all they'll do is make dev look good at the expense of the customer.

I agree that sprints are the best way to solve the work and allow you to pivot. I'm not completely sold on the 1 week sprint suggestion, that depends on how much effort is required to deploy at the end (you may want to look into automating deployments through something like Octopus).

However the big point I wanted to raise which no one else has is your comment about multiple branches.

From what you describe you have multiple branches of your code base which any fixes then have to be merged between the two. You're moving in the wrong direction here, what happens if you need a new flavour of your software? What happens if you take on a new client? Your source control will grow and grow and make it less and less manageable.

You need to move towards trunk based development (or at least short lived feature branches). You can use feature toggles/roles/configuration to customise your software for each client/project.

Doing this will:

  • Reduce bug fixing/feature implementation overhead
  • Allow you to consolidate your testing down to a single branch (making testing more efficient)
  • Allow you to build a proper CI pipeline where EVERY build is regression tested
  • Allow you to develop a proper deployment process without quirks of individual branches

The easier it is to push code out, the easier it is to develop features. But also the easier it is to deploy fixes. This means that the support work your team are currently facing becomes easier. You don't know what's going on, deploy more logging. You've found a bug which needs to be resolved today, don't DLL patch it, just deploy a new version.

One final point. You're concerned about the amount of time going into support work, you should be, it's a lot and every interruption costs you guys time. Define the criteria for work to be brought into the sprint and, if it is, push an equivalent work item out. My suggestion would be to have your "P1 criteria" the same as your 24 hour callout criteria. After all, if it's not important enough for an analyst to get out of bed at 2am it's probably not important enough to sacrifice the most important work on your backlog.

When measuring record the SPs of the work which you planned in and was completed. The missing space represents the interrupting support work. Your concern should be "how much of the planned work did we deliver?", support issues you didn't drop everything to resolve can be planned in but do so against your backlog items.

TLDR

  • Measure how long it takes between a customer raising an issue and them closing it
  • Move towards a trunk based development model
  • Consider automating deployments
  • Agree P1 criteria with the business, that's what interrupts your sprint
  • Thanks @Liath. I've edited the post to more closely describe how we manage branches. My understanding of Scrum is that in perfect Scrum, there are no service packs. Just the next release. Cherry picking bug fixes and even new features onto older releases is causing unnecessary overhead. I'm not sure how to deal with that. – Simon Aug 2 '18 at 5:27
  • Yeah, I used to do something similar. It usually ends up with clients cherry picking "we want that but not this" and you need a time machine or a horrifically complicated branching process to keep up. Your teams' time is better spent on work, not branching. Roles/Feature toggles are definitely the way to go! – Liath Aug 2 '18 at 8:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.