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 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?