In this introductory post, I want to explain why I am going to write some articles on how to use some Unified Process tools and techniques in the Scrum framework. This article does not provide any recipes yet; it just explains why I decided to help people to augment their Scrum implementation with Unified Process practices.
Don’t get me wrong. I love Scrum. It is a well-designed, elegant, lightweight framework that helps to develop a various range of projects – ranging from a simple website to an ERP system without needless stress. But at the same time, I see how people struggle to implement Scrum on real projects. And many of them are struggling with product ownership. When I realized that, I asked myself, “why don’t my companies struggle with the product owner activities”?
The answer appears to be simple yet complicated. I have also been using the Unified Process in different variations (such as RUP, Open UP) for a couple of decades. It helped me to successfully manage dozens of projects of extreme technological and business complexity. When my company started Scrum transformation, we realized that business analysis and requirement management disciplines, offered by Unified Process, perfectly align with the Scrum. So, we continue to use them, and this helps us a lot.
I noticed that there are two typical mistakes that people make:
1) Misinterpreting Scrum. Scrum is a framework. It is not a toolkit. So, it has to be augmented by tools that support Scrum values by solving the problems or satisfying the needs of the Scrum team. Not every tool may be aligned, and not every tool aligns naturally. But many people make a mistake thinking that if they perform rituals, prescribed by Scrum Guide, the proper result will eventually emerge. No, it won’t. The Scrum, as a framework, effectively helps to make sure that the appropriate tool correctly applied to the proper job. But it is up to you to find the proper tool and learn how to use it.
2) Underestimating Unified Process. Unified Process in whole, how it is often presented and often used, looks too heavy, too formal, and too rigid. It seems very waterfall-ish and not agile at all. The truth is that it does not and does not have to be. It is a very elegant, practical, and highly configurable toolkit.
It is essential to understand that the Unified Process offers a complete set of answers for all situations. It provides the complete checklist of goals, the extensive set of methods to reach the goals, the full collection of artifacts, and the means of artifacts validation and management.
People are often overwhelmed by the formal part of the Unified Process, and forget two important things:
• The set of goals is the only crucial part. The rest is just an advice how to reach it.
• The methods need to be applied only to the extent where the goal is successfully reached.
• The artifacts and their handling are highly configurable and need to be used only to provide details enough in the current situation for the current project.
So, I intend to share my experience of successful adaptation of the Unified Process toolkit for Scrum projects. In future articles, I am going to show you the following Unified Process tools:
• Why and how to analyze stakeholder
• Why and how to analyze problems before simply gathering user stories
• How to use FURPS to make sure that requirements have enough details
• How to use Five Attributes method to prioritize the product backlog
• And much more, so stay tuned…
My name is Nikolay Gekht. I am CTO of Gehtsoft USA, a project and product manager with 25+ years of experience with dozens of successful projects in my portfolio. During my career as CTO, I delivered thousands of hours of lectures and practical training on requirement management techniques and raised many successful business analysts and product owners.