- 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.)
|Do you have a need to be better?||
|Are you willing?||
|Do you know what the commitment is?||
|Are you still willing?||
|Can you make the commitment?||
|Can you stick with the decision through the awkward initial phases?||
|Do we trust each other enough to be transparent about what is working and what is not working?||
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 Software Requirements Gathering Techniques
Related Q&A from Betty Luedke
Expert tackles the daunting task of searching through requirements documentation to discover the most important parts of the documentation while she ... Continue Reading
Using defect tracking tools to manage requirements assumes the wrong idea about what requirements really do. Expert Betty Luedke explains how to ... Continue Reading
Software requirements are often subject to change; using a sound estimation process helps greatly to manage change. Requirements expert Betty Luedke ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.