--- title: "Scrum is not enough. Try ScrumP" url: "https://osherove.com/blog/2007/9/11/scrum-is-not-enough-try-scrump.md" canonical: "https://osherove.com/blog/2007/9/11/scrum-is-not-enough-try-scrump.html" published: "2007-09-11T04:46:44" updated: "2007-09-11T04:46:44" tags: ["Agile", "Agile Related"] author: "Roy Osherove" description: "I'm a firm believer in the idea that a good development methodology always has two parts intertwined. The first part is the Process . That's basically everything that has to do with the customer, requirements,…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Scrum is not enough. Try ScrumP By Roy Osherove September 11, 2007 In [Agile](https://osherove.com/blog/category/agile), [Agile Related](https://osherove.com/blog/category/agile-related) **Historical article** · Originally published September 11, 2007; technical details may be outdated. I'm a firm believer in the idea that a good development methodology **always** has two parts intertwined. The first part is the **Process**. That's basically everything that has to do with the customer, requirements, iterations, planning etc.. . A process like Scrum is a perfect fit for this part. But the second part is the **technical supporting practices**. Things like Unit testing. continuous Integration, TDD, Pair programming and basically anything that states how developers work on a day to day basis is part of that. Following a process like Scrum is a good start, but if you take a look at the ideas behind Agile Development you quickly find that process is not enough.  Something technical has to be there to make sure the process is indeed feasible.  **Example: Handle requirements that keep changing (Embrace Change)** It doesn't really matter how well you work with scrum, how short your iterations are and how simple your backlog is. When you need to change a part of your code because something has changes in the requirements or your understanding of them, you're faced with the prospect of breaking existing code. If you break existing code and don't know that you did, it won't be long before your iterations and changes wreak havoc in your code base and your development time per feature will slow down considerably because you keep bumping into unexpected bugs during testing (hopefully!). Unit tests are a great example of a technical practice that supports an Agile process. If you had unit tests on that project you could change the code and see the places where you broke something and fix them quickly. you'd have a much easier time going into the code base and start messing with it knowing that you know the consequences of your actions. **Embracing change over time without unit tests is next to impossible,** no matter how small your iterations are. **What about continuous integration?** THe idea is to get feedback quickly that you broke something in the code base. If it takes you a month to find out you broke someone else's code or it won't compile at all, that's a lot of code under the bridge that you need to sift through to find the problem. If your iterations are short you can't really afford to have such a lengthy integration phase. it needs to be every day or you risk finding yourself between a rock and a hard place soon. (Automated build with [FinalBuilder](http://www.finalbuilder.com/)) **Smaller iterations are next to impossible without a good integration\\testing\\build cycle.** Jeremey Miller posted [that people seem to like Scrum over XP](http://codebetter.com/blogs/jeremy.miller/archive/2007/09/08/scrum-is-fine-but-don-t-leave-the-xp-at-home.aspx). People need to realize that Scrum and XP are two sides of the same coin. Successfull companies I've seen implemented parts of **both,** or a variation of them. I like to call these hybrid processes **ScrumP** (Scrum-pee but in a good way!) as the combination of both of these methodologies and the idea of combining process and technical practices. BTW, in the comments to Jeremy's post [Dave Woods](http://blogs.solidhouse.com/david.woods) suggests that people like Scrum of XP since it's a easier Sell. I wholeheartedly agree. Managers really don't like to hear the word 'Extreme" when all they want is for people to just work better. But I think "selling" Scrum and then adding in parts of XP without doing this officially is a much more suitable solution since everyone feels more comfortable doing it, especially the managers. ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Sep 16, 2007 ### [Mocks and Stubs - The difference is in the flow of information](https://osherove.com/blog/2007/9/16/mocks-and-stubs-the-difference-is-in-the-flow-of-information.html) - Sep 13, 2007 ### [Throw-Away Tests Vs. Tests that Last](https://osherove.com/blog/2007/9/13/throw-away-tests-vs-tests-that-last.html) - Sep 4, 2007 ### [Video: Agile Israel - Introduction to Agile, Scrum Planning](https://osherove.com/blog/2007/9/4/video-agile-israel-introduction-to-agile-scrum-planning.html) - Aug 29, 2007 ### [Reminder: Agile Israel meets TODAY](https://osherove.com/blog/2007/8/29/reminder-agile-israel-meets-today.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/