How can these problems with agile be solved?

Question

I'm a lead developer and for the last four years I've owned a code base which has steadily been improving in quality. I worked at a fairly small company and we previously worked in small waterfall cycles. Typically we'd do a release of our software every 3->5 months. We didn't use many formal project management methods but we had a good team and everybody was intensely collaborative. I spent the vast majority of my time writing features, fixing bugs and improving the code base as I saw fit. I refactored code when I thought we were starting to see too many bugs in that area and I focused on trying to make our code unit testable and of high quality. QA would pick up our work once features became dev complete but we didn't work in sprints. It's fair to say that things didn't always go smoothly and we did have some quality problems but productivity was very high.

Fast forward to now.. We've been bought by larger company who have already fully adopted agile methodologies. We've had to adopt their processes and some in our team were very keen to move to full agile. Initially, for a period of about 2/3 months our work ground to a halt.

• Decisions that were previously made quickly and efficiently, ad-hoc, by groups of interested individuals became part of the grooming process and we found that design by committee took forever compared to what we did before.
• A great deal of our time was taken up by grooming and planning meetings and at one point I realized that more than 50% of my time was now used for meetings.

Over time, during our retrospectives we've improved this process. One of the things we did was to get individual team members to pre-groom Product Backlog Items (PBIs) so that some of the thinking had been done in advance and we didn't have to spend quite so much time just thrashing out the basics of each item during the meetings.

However, some problems still remain.. Here are the big ones for me:

• Generalization and group think has reduced the extent to which anyone "owns" the code base. This has been really bad and it feels to me like the code base has been left to rot. Nobody can do anything of any significance to it without a massive discussion first and all those little tasks that used to just happen for free no longer happen. Instead specialists who used to do this stuff are busy doing other things which are the sprint priority even though they do them very slowly. There's basically no time left to put serious thought into our code. Over the longer term I think we'll pay a big price for this.

• Developer passion has gone.. Nobody wants to spend so much time in meetings and all the decision making power has evaporated leaving the devs demotivated. Decisions about what development tasks should be undertaken are now often taken by testers or others who don't actually understand the code and so now everybody just drudges on not really enjoying their work like they used to.

• Generalization is wasting our time and damaging our code. Right now I'm trying to learn a new programming language to fix one bug and bugs that I could be fixing in a language I know are being fixed by another scrum team by a guy who I don't think knows the code in that area well enough to be able to efficiently or effectively fix it. This kind of thing has already caused us some quality problems.

So, how can we fix this within Scrum? We can't get rid of the process, but can we change it somehow so that we can work effectively again?

Answer 1

Generalization and group think has reduced the extent to which anyone "owns" the code base.

That's bad. The goal is shared ownership, not nonownership.

Are you using slack time? Or aiming for 100% utilization? If the latter, change to the former.

During the slack time (one hour a day, one day a week, one week a month, whatever), developers are able to work on whatever they want - research, side projects, whatever.

Provided no one's already working on a feature, they could just pick one up and start working on it.

Just make sure you implement a code review before merging that work into the main codebase. You do not want some person going off on their own, doing something, and then shoving it into production code without anyone else knowing what it is.

Also, it was mentioned in comments already, but make sure the prioritization by the Product Owner is done at the story level, not the task level. The Product Owner decides what work gets done. The Development Team decides how that work gets done. If they don't want to have massive design-by-committee meetings to determine the how for each feature, then... that's their call. The Product Owner (nor the Scrum Master, unless s/he is also a developer, and even then the Scrum Master's words should not have any more weight than any other developer's) should not have say in that.

From the Scrum Guide:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

So, if you don't like how you're turning items in the Product Backlog into 'Increments of potentially releasable functionality'... then just change it.

If you're not allowed to, then you're not really doing Scrum. Or Agile.

Answer 2

• Decisions became part of the grooming process and we found that design by committee took forever ...
• 50% of my time was now used for meetings. Nobody wants to spend so much time in meetings.

You should not be spending such an excessive amount of time in meetings. You are likely not timeboxing them. Ideally under Scrum these decisions should STILL be going on ad-hoc between the team members responsible for the corresponding tasks. Backlog grooming is not a design meeting. Its goal is to break items down into a size that can be sheduled a on what should be done (will we have user avatars? will we have multiplayer?) not how (Fidget-Architecture powered by Gadget-engine)

• Group think has reduced the extent to which anyone "owns" the code base. Nobody can do anything without a massive discussion first.
• Developer passion has gone. All the decision making power has evaporated leaving the devs demotivated. Right now I'm trying to fix one bug and bugs that I could be fixing are being fixed by another guy who don't knows the code in that area well enough.

SHTAP! You are seriously missing the point of crosstraining in a scrum team. The goal is that eventually every team member should be able to pick up any task with decent proficiency. But even then it would be insanity to "assign" a task to a team member who can barely do it when a specialist is available. Someone is trying to forcefully turn your team into interchangeable gears instead of allowing a natural cross-training to take place. That person needs to stop immediately!

Shared code ownership does not mean everyone must negotiate every decision with the whole team but that you consult with coworkers who know a piece of code better than you but you don't need their permission to touch it.

Answer 3

We always include a Feature "Technical Debt" in every release. The developers make user stories under the feature regarding code refactoring, code cleanup, framework updates, increasing code coverage etc. The Product Owner is made to understand that these catching up on our Technical Debt stories have to be done first and then we should build functionality on top of the existing code base.

Also, our releases also take 3-5 months. At the end of Release-1, the workload is more on Testing while at the beginning of Release-2, the workload is more on the Product OWner/BA side. These 2-3 weeks between Release-1 closure and Release-2 Dev/Test Iterations beginning, that's when this Technical Debt work kicks off.