I would have a look at Scrumban, it combines best of both worlds Kanban and Scrum.
Kanban gives you a more just-in-time way of planning where you can tackle issues that are incoming as soon as possible. Combining this with the Scrum roles and meetings leads to something that feels very good for maintenance teams.
Product owners should develop the long-term ...
What You're Doing Wrong
[T]he development team personnel eventually end up working on bugs, client requirements etc. This impacts sprint delivery and the development team is now missing the sprint deadlines.
By failing to protect the development team from unscheduled work, and not following the rules of Scrum by calling for an Early Termination and a ...
SCRUM is not an acronym.
You do not need two teams. Try running textbook style Scrum.
It sounds like you're not properly respecting the velocity of the team. If the team does not deliver all of the stories for the sprint then you should attempt fewer stories next time.
You incorporate the distraction of maintaining releases in the velocity of your team. ...
While it may be possible to use Scrum, queue-based frameworks are generally a better fit for support processes. Queues should be designed around response times rather than solution lead times for best results.
Capacity and work-in-progress (WIP) limits should also be clearly articulated. You should also have a clear plan of how to handle situations ...
Some of the things you expect them to do might not be as essential as you think
You are operating under a different paradigm now. Without knowing more details it's hard to judge how much your reaction is due to a completely different approch and how much is due to actually unsustainable practices.
Specifications - Shared understanding is more important ...
Two main options here:
Give the PO help
Give the PO better tooling
The Product Backlog is:
an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.
For a product of significant complexity, the backlog will grow to be non-trivially large. The Scrum Guide puts ...
The backlog consists of PBIs like Epics and User Stories. I really like using User Stories. That's why I'll stick on the term in the following. But be aware that other representations might be more useable sometimes (as @Daniel pointed out in his comment).
A few User Stories can be finished in a sprint. User Stories are broke up in tasks during sprint ...
Kanban is suitable for software maintenance work
Scrum is not suitable for software maintenance. Kanban is.
Kanban was developed at Toyota in Japan to improve the auto assembly line.
David Anderson literally wrote the book on the use of Kanban in Information Technology (IT).
From David Anderson Interview:
The most commonly cited instance where Kanban is ...
Your OP reads a little bit like you're looking for reasons not to engage in this proposal. I am bringing this up because if I am picking up this tone in your writing--and if I am right in my interpretation--then your management will likely also be picking up on the negativity from a business development point of view and that will inhibit your ability to ...
Team project ownership
The team should own all of the code, not individual methods. And I said team project ownership not just team code ownership, because you seem to be having other issues, like documentation and handovers.
The way to fix this is with good practices like code reviews, pair programming, building knowledge and skills that span the entire ...
Lots to parse here. TLDR; Focus on what's important (maintainable code), rather than jumping to an assumed/unverified root cause (lack of documentation).
First, and perhaps most important, is your perspective. From the tone of your Question, it appears to me as if you're not only unfamiliar with Scrum, but disparaging of it. If you come at a ...
There is just no way you could estimate how many people you need to "deploy new features on demand" or "adapt to changing business processes".
That's like saying "please tell us how many people we need to run our business". How would you know?
What you could do is draw from real world examples. Did you have a business change in another system? Could you ...
"100% utilization" is a bad idea; agile projects rely on adequate slack in the process. "Ideal hours" can be bad too, although some practitioners can make a successful case for them in certain situations. Agile projects are about empirical team capacity rather than making sure individuals are utilized at 100% of some theoretical capacity limit.
First of all, you are missing a key point when mixing Agile with plan-driven development.
In scrum you don't level team members based on their availability, rather than deliver complete user stories at the end of a sprint.
You really don't care about that, you deliver stories or not, the more, the merrier :).
Having said that, if you want to account for ...
Leaving supportable code is just as important for an Agile team as for a traditional development team.
It is simpler to describe what an Agile team would try to avoid:
Don't write documentation just because it is the 'done' thing - i.e. only write documentation that you know will be valuable to people supporting the code in the future.
Avoid documentation ...
Rather than trying to predict the maintenance needs, perhaps it would be a better idea to offer a capacity.
For example, something like:
We will make available a Scrum team of 7 people for 3 months. This team will give us the capacity to deal with 2 major production bugs and to add one new feature (of the equivalent size as the advanced search function) ...
Software Maintenance cost survey results
Here is a review of a book:
One of these foundational studies in software maintenance, one of the
most widely referenced, was done by a team at UCLA led by Benet P.
Lientz and E. Burton Swanson back in the late 1970s. They surveyed
software maintenance practices at 487 companies
Corrective Maintenance (bug ...
I've been in similar situations. My experience has been that when you talk about it, customers usually have at least an intuitive understanding of the issue, but will look for any way to avoid the announced cost. They have been working with you for years, have gotten accustomed to a certain rhythm of deliveries, have a feel for how much something costs and ...
The Client is coming to you to solve a problem, and if you have already committed to the work then it is disingenuous for you to want them to update their framework just to make your developers' lives easier, especially if there will be no value added to them, and just an extra expense - I'd tell you guys to pound sand.
The only way it would even be okay ...
I am making an assumption here, that your client owns the software you have built for them. If that is the case, you don't get to make the decisions about what work should be done in the software, they do. Deciding to make platform changes to suit your developers and your organisation and then expecting them to pick up the bill for that is plain wrong.
Operations and maintenance operations are a function of a healthy system development lifecycle. For reference, check out IEEE-12207. That document clearly defines what Operations and Maintenance activities are.
Operations activities are normally defined as largely upgrades and installs. While these can be checklist-driven, they are time-boxed. For example,...
Although I'm posting a response a year after the question is asked, but this seems to be a common question and hope my experience would help some people in taking the right decision for their respective organizations.
According to me, here is a mix that works best for maintenance projects:
1). Define a sprint cycle - week or 2-week cycle depending on the ...
Depending on the total number of developers you have available in your dev and maintenance teams it may make sense to re-combine them into a single team, some or all of whom work on both maintenance and on-going development. You can then handle maintenence in one of two ways.
1) Add all the tasks into the backlog, estimate them and add them to sprints as ...
I would assign a fixed capacity bandwith for each major workstream, and manage this in a timeboxed fashion. In your case, this might be
New user setup
I have written about it here and here on this list. Please check those answers out.
Maintenance team skills are mainly significant recreating the bug, analyis and then coding, testing(unit, regression, UAT, BAT etc...) and deployment. They do the same in the development projects too. Domain knowledge is also very important for Maintenance team. As there is no root cause mentioned not sure why your developers are unable to perform this. ...