Is scrum right for us?
I work in a software department that creates B2B software applications for our many clients. I have been examining the current process (that has been in use for a couple decades) and am as frustrated at its many shortfalls as our developers are. That being said, I'm not sure the best way to go about changing and tinkering, given our department size and the amount of work that is in the system.
Background::::::::::::::::::::::::
The department uses a water-fall process, where the work starts with our systems analysts, who create a requirements document, it gets peer reviewed, then sent 'over the wall' to the development team. It generally sits for a few days in a queue until someone has enough time to 'pick it up'. At that point, the developer then self-assigns the project and then codes it.
While the project sits and the developer codes, the systems analyst (in theory) creates the business test cases which are then ran by the developer when he finishes coding. Sometimes these are out of sync and the tests or the project sits for days waiting for the other to finish.
After tests are complete and submitted back to the analysts, the project enters a nebulous 'testing phase' where the client usually gets to see the project in action and changes the requirements, etc. Projects usually spend an inordinate amount of time here as we lose customer engagement long before tests go back to them.
Each project is generally 10-100 hours total, so our batch size is very small (in comparison to a lot of software out there). The problem is that our projects take about twice as long (in days) in-process as the number of hours we spend on them (so a 30 hour project would take 2 months).
Lastly, our legacy systems are currently coded in a non-object oriented, proprietary scripting language, 99% of projects are solo efforts, with a code-review at the end (we are migrating to Java, but it is going to take awhile).
Question:::::::::::::::::::::::::::::
It seems like for our new/complex/high-risk (ambiguous or unknown requirements) projects, we should implement an agile approach to gain/maintain customer engagement. Even for our larger projects, though, each piece of software is still only 200-300 hours of work.
Is scrum the answer here? XP? I am a scrum master, but am having a tough time figuring out how to get more agile in our process. Thoughts?
Scrum is a framework for developing and delivering complex systems. If the your work consists of relatively small changes, then there is a limit to how complex your scope is likely to be, and to how much inspection and adaptation will be required to mitigate uncertainty.
That's why small changes are typically associated with Kanban rather than Scrum. There's no need to bring complexity under control by working in Sprints and setting goals.
When choosing an agile way of working, you should therefore take the level of complexity and uncertainty into account.
I think that you can greatly benefit from switching to an agile process.
If you would start development from scratch, then Scrum as the agile process could be a good fit. The reason for that is, that Scrum has a fixed set of rules that need to be followed. I made the experience that people generally adopt a simple set of rules (with the help of a well trained facilitator) quite easily when they can start from scratch. Especially if there was no well defined development process existing before.
Your situation is different though. You do not start from scratch. You do have an existing development process. I think that making a hard cut and introducing Scrum would cause a lot of resistance in your company. Kanban can be a good fit because it starts from your current process and tries to do the transition step by step. Therefore resistance is minimized and the chance to successfully change the overall process increases. However Kanban does not have such a well defined set of rules like Scrum. Therefore you have to take care that you really optimize the process and not only conceal weak points without actually resolving them.
I have seen some ScrumBan/Scrummerfall etc. abominations that are introduced by people that do not really understand what optimization and working agile really means. So they continue working the (ineffective/inefficient) way they always did and just give everything a different name, because they "are agile now". But don't get me wrong, there also are a lot of very good implementations, introduced and cherished by great facilitators. :)
I hoping this will help. http://tglomo.info/avCAP/ We created a FREE tool of our current experience at Cisco to help team understand if SCRUM is right for them. Also reviewed and interviewing close to 1200 organizations. As a takeaway we provide you free resources and the beginning stages of a road map. http://tglomo.info/avCAP/
Thanks for your thoughtful response. I am currently leading a change for our organization that will split us into smaller cross-functional teams (vice the current large, skill-based teams) we are in now, and I feel good that we will be able to start experimenting with some of these different Ideas. Do you have any resources you recommend for Kanban adoption/mutation? I have read the book Learning Agile, but it was more of an overview to different Agile approaches.
I recommend the book "Kanban: Successful Evolutionary Change for Your Technology Business" written by David J. Anderson. This is the standard reference for Kanban. This book not only tell about some principles you need to follow but teaches you why it is important to follow them.
This knowledge is also beneficial when dealing with Scrum as both are agile processes that are not necessarily mutual exclusive.