| Business |
Looking for a fantastic explanation about Scrum and Agile, but don’t want to wade through a bunch of whitepapers, convoluted diagrams and confusing explanations with words you’ve never used before?
Well, look no further! Here, you’ll find the answers to questions like, “what is Agile project management?” And, you’ll learn how you can implement Scrum to help your team.
Do you know what the business expects from your current development? Do you have any idea about the most important features for the success of your project? You need a vision that describes who needs the product, why they need it and expected benefits. This vision is shared by stakeholders and the Scrum team.
Throughout the project, functionalities at the top of the product backlog are the ones with the highest business value. They are refined and discussed with the team.
Every day, Scrum teams ask themselves: “Is this project going in the right direction or do we need to adapt?”
Do you really believe a client is always able to express exactly what they need at the beginning of a project? Maybe the solution they are thinking about in order to solve their problem is far from ideal. But how can you help them discover what they really need before the project is finished and its too late? Agility introduces the idea of iterative development, and Scrum is implementing it with the concept of short iterations of time (2 to 4 weeks) called a sprint.
Agile and Scrum embrace failure as an opportunity to learn.
At the end of each sprint, the team presents the client with what has been done. This means showing real working software, not just some slides or talking about a concept. Practitioners of Scrum believe it is the best way to share a common understanding to get the valuable feedback that is needed.
Every day, Scrum teams ask themselves: “Is this project going in the right direction or do we need to adapt?”
Scrum will make you reconsider the role of management. In fact, a manager will turn into a servant leader!
A manager’s job is to make sure that the people within the team possess the skills required to complete the project, as well as a good work environment. Then they need to step back and trust that their team is doing their best to reach their objectives and continuously improve.
But, managers in a Scrum world cannot disappear completely. They still need to help remove the obstacles the entire team might face, in order to progress.
Are you always involved with the same kind of technical tasks? (For example, only front-end development, only back-end development, only database, etc.) What about working on multiple projects at the same time? Do you sometimes lose focus and have to switch context in order to integrate your work with people who are working in other teams?
In a Scrum team, there is no more of that! No more multi-project and horizontal development: the team is collocated and dedicated to a single product backlog. Developers are full stack developers, who own a feature in a sprint from top to bottom, developing it as a vertical slice.
A good Scrum team is built for the long run; the product backlog may change after a project is finished, but the team will stay stable and move on to the next project.
Is your team often putting in overtime? And if yes, why? Well, the answer is probably because there are fixed deadlines that need to be met! But is this really a proper way to work? (Hint: it isn’t.) Scrum follows the Agile Manifesto principle about sustainable pace: Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The idea behind this principle is not that Agile people are lazy. The point is to provide visibility in the mid- to long-term.
The only solution is to maintain a sustainable pace through time. If people put in overtime to meet a deadline in one sprint, then they should be able to compensate in the next.
Agile and Scrum embrace failure as an opportunity to learn. Whether you fail because of something technical or because of a problem in your process, there is nothing wrong with that.
The real problem is when you fail, time and again, without searching for “why,” and without taking actions to prevent it.
Scrum has a dedicated ceremony to discover what went wrong during an iteration and to look for potential improvements: the retrospective. The Scrum Master is responsible for creating a welcoming, blameless environment where team members can exchange opinions. This meeting is crucial for the team and requires the most groundwork from the Scrum Master.
The Scrum Master should bring two things to a retrospective: a plan and a toolbox. Depending on what the team expresses during this meeting, the Scrum Master might have to adapt his/her plan.
As a beginner, you will often follow the 5-step retrospective from Esther Derby, picking innovative activities found online. Don’t worry, though, with time and experience you will create your own activities, and you’ll do what is right for your team.
Speak a common language for transparency’s sake, and put the focus on face-to-face communication for efficient exchanges.
A ubiquitous language about the business and the process must be shared by the Scrum team and the stakeholders in order to better understand all the visual tools and the sprint outcome.
Promote enriched and clear conversations about quality expectations. This way specifications, designs, and architecture are able to emerge easily from the Scrum team.
"Why are there so many questions to create a new user?! I just want to sign up!” It’s a legitimate question when the form in front of you contains too many fields.
This is where YAGNI comes in, which stands for “You Ain’t Gonna Need It”. Combine the VDD and short iterations to develop the minimal version of your features with a pragmatic code design.
Product Owners: challenge your business!
Developers: challenge your product owner!
You can then use feedback from your users to efficiently build features that fulfill your needs.
“Individuals and interactions over processes and tools.”
This quote is actually the first statement and first value of the Manifesto for Agile Software Development. If anything, Scrum is about people and the way they work together. It focuses on the team members and their interactions, both within the team and within the rest of the organization.
Scrum also favors experimentation and knowledge sharing. Don’t hesitate to share your successes and your failures. And remember that you are not alone. There are a lot of Agile and Scrum communities with experienced practitioners who are ready to help.
We just mentioned above, the first value of the Agile Manifesto, but there are three more. Scrum reinforces these values.
1. Working software over comprehensive documentation
In the Sprint review meeting, the team shows the concrete result of their work to the stakeholders by giving a demo of the working software. This is aligned with the second value. The product produced at the end of the iteration should always be potentially shippable, which means it could go into production.
2. Customer collaboration over contract negotiation
In a Scrum team, developers are encouraged to speak face-to-face with stakeholders and users. They collaborate with them on a daily basis. The product owner is particularly involved in this collaboration and paves the way for the team to better understand what the users need.
3. Responding to change over following a plan
Scrum embraces uncertainty and treats it as an opportunity. Planning short iterations allows the team to refocus its work on a regular basis. Your business just changed because a new competitor entered the market? Well, ok, no problem; a Scrum team can adapt quickly.
This piece is brought to you by Agile Partner, a Luxembourg-based IT service provider that strongly believes in the Agile methodology and provides software development and training.