Scrum, an agile methodology, offers great advantages for certain software project teams. Expert Betty Luedke explains the basic tenets of Scrum and how they affect requirements engineering.
Q: Hello. We are a very small company interested in Agile, specifically Scrum. I am wondering if becoming certified in Scrum would be really helpful or if I could do without this certification. Requirements gathering has been a sticky point for us, with some people feeling that even though we have some communication issues with requirements (groups not talking with/understanding each other and so forth) that things may just get screwed up with an overhaul. I think we need an overhaul. I look for your response.
A: Let's take a brief look at Agile and at Scrum to see what has attracted your company. The Agile Manifesto provides the overarching principles and beliefs under which Scrum operates. Scrum is an agile method for developing software which, according to author Ken Schwaber in the book Agile Software Development with Scrum, has at its heart:
Commitment: Be willing to commit to a goal. Scrum provides people all the authority they need to meet their commitments.
Focus: Do your job. Focus all your efforts and skills on doing the work that you've committed to doing. Don't worry about anything else.
Openness: Scrum keeps everything about a project visible to everyone.
Respect: Individuals are shaped by their background and their experiences. It is important to respect the different people who comprise a team.
Courage: Have the courage to commit, to act, to be open, and to expect respect.
Even though books and training on Scrum identify the roles (product owner, Scrum master, Scrum team member) and practices providing guidance, the best way to begin to understand this approach is to first observe Scrum in action, then participate in it (perhaps in a training session) and finally experience in your own environment. Of course, having the opportunity to observe, participate in and really experience Scrum is not going to just happen because someone expressed an interest in Agile. It is interesting to me that a decision to "go agile" actually calls for the same type of commitment, focus, openness, respect and courage that is embodied in Scrum itself.
Many companies these days are interested in being "agile," but they have not really embraced what that means. How should agility be reflected in the way we develop systems? How should the project team members work with each other or interact with the business? Has anyone given any thought to an effective way move to this new behavior? Scrum is not for the faint of heart. If practiced as intended, Scrum is a disciplined approach that provides the customer something of value quickly. Many are surprised by the discipline that Scrum requires because previously they have associated a "disciplined" approach with lots of artifacts. Scrum empowers a team to make a focused commitment (for a sprint), enables them to learn from their collective experience (in a sprint review or retrospective), and provides a way to manage the inevitable changes the business needs (by leveraging product and sprint backlogs).
After reading the Scrum values (above) again, I find myself reflecting on part of your statement:
Requirements gathering has been a sticky point for us, with some people feeling that even though we have some communication issues with requirements (groups not talking with/understanding each other and so forth).
It's not the "requirement gathering" part that caught my attention, it's the rest of it. In my experience "communication issues" and "sticky points" that linger are usually symptoms of a project environment that is not fully functioning with the commitment, focus, openness, respect and courage in the way Ken Schwaber describes above. So, things are not perfect, but you knew that already. You certainly have emphasized that you are looking for a "better way" (overhaul) and are raring to go. While your colleagues may agree that things need to be different, they are not sure about the timing and are concerned that things are likely to get worse instead of better.
You know that doing things differently takes courage and the willingness to embrace change. A new approach (Agile…Scrum) will not fix the unwillingness factor. You should expect the initial stages of any change to feel awkward because it is unfamiliar; moving to Scrum will be no different. While Scrum's empirical, chaos-tolerant approach brings freshness to the actual development of software, it does not address the parts of the system development lifecycle where a defined process, such as release management, is more appropriate. Scrum is a leap not into the dark, but into possible new synergies. If you take the Scrum path, you are all on this journey together: you, the other project team members and your business partners. You all will need to have (at a minimum):
An understanding of basic principles and practices.
A commitment to working differently.
Roles assigned and accepted.
Financial and moral support for learning and transitioning to a new approach (training, coaching).
Use the questions below to explore the question "Are you are ready for Scrum?" (Keep in mind that "you" is a "collective you" referring to you individually, your team members and your business partners.)
Ask...
Think about...
Do you have a need to be better?
If you do not have PAIN and need to be "better," why change anything?
If there is PAIN, identify the PAIN
Are you willing?
Willingness goes a long way when making any change.
Do you know what the commitment is?
Have you read about Agile? Scrum?
Have you talked to anyone about Agile? Scrum?
If you have, do you think you got a "day in the life" view that gives you a realistic picture?
Are you still willing?
Willingness without knowledge is not meaningful. Now that you have the knowledge, how do you answer?
Can you make the commitment?
Be honest here, is this something that can work for your team at this time? How will you know if you do not take some training together and then discuss the possibilities and the commitment? What other specialized training is needed?
The product owner is responsible for representing all who have stake in the product. The Scrum master is responsible for the Scrum process. The team (self-managing, self-organizing, cross-functional) is responsible for developing functionality. So, can you all commit to really trying and really learning?
Are you thinking that you may need to customize the approach? Novices leading novices is a LONG road! Who will be our coach? Who will help us understand the practices so we do not morph Scrum into the way we have been working all along?
Can you stick with the decision through the awkward initial phases?
Do you already know that the first part will be messy and full of sorting it all out?
What is your team's tolerance for "awkward?"
Do we trust each other enough to be transparent about what is working and what is not working?
If you got this far in the questions and are still answering yes, then go for it!
If you stopped somewhere along the way, then realize that you have gained good information about those things that could seriously undermine your effort and take you by surprise later.
Summary
I have been in system development, in one role or another, for a long time. I have had my share of successes rise from the direst of circumstances, but I want to share with you my gut reaction to my first serious read about Scrum. I could not put it down. Every page or two, the thumb was up and fist came down with a resounding "Yes!" (Unfortunately, I was on a plane flying somewhere so I could not actually say it out loud, but the feeling was the same.) Had I practiced Scrum at that point? No, but I knew from experience the power of collaboration, transparency and respect. It all resonated; it all seemed possible. Experiencing a team being the best it can be is not only intriguing, but also energizing to the point that failure is not an option. As you can see from my reaction, some of the basic tenets of Scrum are also basic tenets of success.
Hopefully you now have an idea of what is needed to make an informed decision together. Even if you all decide that Scrum is not right for you or that now is not the right time for this change, the mere fact that you worked through this decision together will alter how you work together in the future. However, if you do decide to go forward with Scrum, you are moving to an exciting new place where you will learn to expect the unexpected!
Dig Deeper on Agile, DevOps and software development methodologies
Software requirements are often subject to change; using a sound estimation process helps greatly to manage change. Requirements expert Betty Luedke ...
Continue Reading
