To Scrum or Not To Scrum?

The company where I work we have always practiced a version of Scrum and tried to be as agile as possible, all being resource, time and money prohibiting. Everything I mention in this post I am or have been guilty of at some point. 

Friday I hosted a retrospective with the rest of the development team like we have many times before and tried to come up with some areas of improvement as well as bringing all issue to the forefront, plus a bit of venting from everyone. Some of the main points that had been raised are points below:

• Last minute requirements from the business forcing late code changes and rushed releases.
• Lacking of a product owner/area specialist who was willing to take responsibility for the product being released. 
• Scope to woolly and acceptance criteria being defined by development post implementation.
• A constant small stream of tasks which had been deemed maintenance tasks but had really been small features or tweaks to existing code bases of products.

After some debate and some insightful questions the conclusion all boiled down to development work starting to early. This isn't the first time and won’t be the last time that this conclusion will be drawn. Developers weren't strong enough to kick-back tasks at the business when no requirements had been gathered, and the scope so woolly it left it to the imagination of the developers. Time wasted in meetings post implementation trying to define A/C and testable characteristics, basically constantly chasing our tails trying to fill in the gaps we had previously missed out. 

To Scrum or Not To Scrum

This leads me on the next discussion we had: Why do we practice Scrum?  Do we actually practice Scrum anymore?  What alternatives are there? Ever since I joined the team we have been practising a form of Scrum within the development team and things worked well. Tasks would been defined early enough, 90% of the time we stuck to a standard fortnightly release cycle, most of the time we have Product Owners,  most of the time we have Stakeholders, a Scrum Master, try to release every sprint, the business would define the next sprints work and we would estimate and plan. All had been working well (with the minor hic-up) up until the last few months when development changed.

The business started making decisions faster, being more volatile and reactive, this could be due to the financial/industry pressures within the company and or a greater focus on pushing through new products and services which obviously will hopefully be paying my wages in the future. As the business had become more reactive and proactive in the current market climate the development team had not really thought about how the changes will affect the team and development process. We did not have the mind set to deal with the new changes especially the speed and or the volume. We still are thinking in a very iterative and almost waterfall model (it hurts to say it), letting each specialism within the team take responsibility for that function only, i.e. developers just being developers, testers just testing and leaving our business analyst to just be doing the analysis. This is ineffective and we all needed a little reality check!! WE ARE AGILE, we are proud to AGILE and yet we had failed with one of its most fundamental features. I don't think this had been done intentionally and I think this slip up is a recent problem and not one which had been causing major problems previously. So after much more discussion we came to the conclusion that Scrum isn’t really what we practice and if it is, it is being bent and squeezed to fit our current development cycles and current needs. 

I think one of the biggest problems had been the team struggling with the change and the constant rush of new feature requests which had been splitting the team up (and focus), each pair working on varying different tasks but yet the sprint still being classed and termed like it was a standard sprint.

We were not doing the project work originally planned out and the project work we had been doing was falling way behind due to features and changes which the business had been making at a much greater rate. Our team resource had been reduced and not only are we working on a single large several week project but also on many small tasks on different platforms, different projects and other smaller projects being thrown in a sprint half way through. We had not planned for this, our code base is all messed up, and releases had failed. Larger features being coded against the branch as the trunk is un-releasable due to the original large scale project we had estimated would take several releases. We had been doing project based work for some time now, focusing on larger scale projects defined from the business, incrementally pushing out new features with an overall common goal which had been loosely defined. New features/products were now being elbowed into this and simply placed under the same umbrella of our main goal, even though the goal posts had moved. Trying to please all and trying to be as agile as possible we had simply accepted these changes and not taken into account how it would affect the way we had been happily working for some time. Scrum and ourselves had failed to manage the current working conditions, the business at present did not really need a team who used Scrum, it was too ridged and we had been practicing a very fluid ad-hoc style and it doesn’t fit anymore. 

What’s next?

Kanban or Scrum-ban had been raised as a possible alternative to Scrum and is possibly a much better alternative way for us to manage the ever changing needs of the business. Scrum-ban sounds like it would be a great place to start, “Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use” – wiki. Making the move from Scrum to pure Kanban may not have the same benefit and the change may be too great and too quick for the first step. Changing from Scrum to Scrum-ban hopefully will be beneficial to the development team and if all fails and we revert to the old pure Scrum methodologies then we only land back at where we are now. We need to ensure we retrospectively follow up each change. Making adjustments if required will hopefully mean the move will be a successful one.

As development we have work to do, improving communication and being more agile all around would make our reactivity much better and reducing the problems mentioned earlier. We had improvements to make in our source control management, having three streams not just a trunk and branch, but also a development branch which would improve flexibility of our code base and not render it redundant if features have been half finished or stories had been dropped from the sprint. Team functions need to be less isolated, developers can help out if testers are behind and testers can pair with developers on particular tasks to ensure test coverage is complete.

All in all I looking forward to practicing in a slightly alternative management style and it may just be the making of our team. I’ll report back on the changes made, how they fit in to our development team and the successfulness. Comments and feedback always welcome. 

James.