|
Problems / Challenges |
Direct Solutions to Listed Problems / Challenges |
General Solutions |
|
Developer Enthusiasm |
|
|
|
The work is boring |
(find out why it's boring and discover what holds interest … ) |
|
|
Even the term "Technical Debt" is negative |
(don't call it that … ) |
|
|
It seems like a marathon of never ending tasks |
(see "innovation Sprint" … ) |
|
|
For backend fixes, a lot of what the team works on can't be easily demo'd |
|
|
|
Developers can't see the shiny new thing they just built |
|
|
|
The organization can't see it as well as a new feature build |
|
|
|
The organization thinks of the developers as "Resources" and treats them as such, rather than as "People" |
Let teams be more empowered, and let them make some more of their own decisions |
|
|
Quarterly "Innovation Sprint" |
||
|
Team Ownership — they get to decide what to work on |
||
|
Development team gets to provide creative input |
||
|
Depends on which of the two kinds of Maintenance work you are talking about: |
|
|
|
1. Here and Now Bugs Fixes |
Use Kanban |
|
|
2. Planned Maintenance |
Use Scrum (teams can commit and deliver increments) |
|
|
Example of something that works for one organization: the developers who maintain the system use Kanban, along with a Scrum (Scrumban). They plan 2-week Sprints with all the normal Scrum ceremonies including Retrospective. They also plan a % of capacity within the Sprint to be used for "unplanned work" (e.g., bugs). The Scrum part is for the planned maintenance. The Kanban board is for unplanned work. New bugs come in and team members pull in whatever work they want. They limit to the capacity that was planned for that Sprint. |
||
|
Switching Resources from one project to another |
It's about how well the PEOPLE work together (to be successful) |
|
|
|
Every time you swap out peope from one team to another, the new team has to go through "storming, norming, forming" cycle again |
|
|
|
Don't call them "Resources" |
|
|
The Core System is out of our control |
Embedding — Have the Vendor work on-site with you |
|
|
Example: a vendor system needs integration, but there are dependencies, and delays while waiting for components to be ready |
|
|
|
Example: a vendor system has a bug that impacts a system we need to maintain, and it's not easy to determine the source |
|
|
|
Re-work due to delay, and slow progress (need to re-test) |
|
Great Article. Thank you for sharing! Really an awesome post for every one.
IEEE Final Year projects Project Centers in Chennai are consistently sought after. Final Year Students Projects take a shot at them to improve their aptitudes, while specialists like the enjoyment in interfering with innovation. For experts, it's an alternate ball game through and through. Smaller than expected IEEE Final Year project centers ground for all fragments of CSE & IT engineers hoping to assemble. Final Year Project Domains for IT It gives you tips and rules that is progressively critical to consider while choosing any final year project point.
JavaScript Training in Chennai
JavaScript Training in Chennai