“No Heroics. If you need a hero to get things done, you have a problem. Heroic effort should be viewed as a failure of planning.”
― Jeff Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time
I have looked at the concepts behind Scrum.
There are many projects which are Agile in name but chaos in reality #HoskWisdom
What is SCRUM?
Start with Wikipedia SCRUM definition
Scrum is an iterative and incremental agile software development framework for managing product development
Scrum is a framework which shares values with the Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
SCRUM and Agile for a time was seen as a magic solution to IT projects, a way to deliver a project successfully and quickly. There has been a backlash and growing discontentment with Agile and SCRUM.
Here are links criticising Agile/Scrum framework
My experience of working on Agile projects is many of those projects are Agile in name but turn out to be a Waterfall-Agile hybrid often called WaterScrumFall.
Delivering Software with Water-Scrum-Fall
Here is a good point to compare WaterFall and Scrum
Agile vs Waterfall: Comparing project management methods
My experience of mixing Waterfall and Scrum is those projects struggle but not because of the way of delivering the project, these projects struggled because of people and the collaboration between the customer and the project team is weighted to one side (customer), successful projects are always a collaboration. The mix of project style wasn’t the sole cause of the problems with the project.
Mixing Agile/Scrum with Waterfall removes the benefits of Scrum removing many of the opportunities to inspect and adapt. One of the major disadvantages is the loss of transparency and time-boxing events.
The Scrum guide online is a simple 16 pages and is adamant you may not change any meetings, artifacts or meeting lengths
Hosk Experience of Agile
I worked on many Agile projects in name but only one was Scrum project which adhered to all the rules.
The project which stuck to all concepts was successful and enjoyable. Estimating, the retrospective and the daily scrum all worked well and the team bonded. One of the benefits of a Scrum project is the transparency and clear understanding and regularity of the Scrum events and artifacts.
The Agile project in name but not in execution were disorganized and lacked clarity and direction. The people on the project were not sure when things were happening and the purpose of events.
Little consideration of project was suitable for Agile\Scrum framework or if the customer could execute an Agile project.
One of the most frustrating part of a poorly executed Agile project is a daily scrum which goes on and on and on. They should not go exceed the 15 minute timebox
Good practices
I have worked on Agile and Scrum projects but not thought about the concepts and ideas behind it.
What is Scrum and Agile
“Adaptive methods are called Agile. There are many Agile frameworks. The most famous Agile framework is Scrum.”
The Scrum Master Training Manual: A Guide to the PSM Exam
By Nader K. Rad, Frank Turley
Agile is a framework and Scrum is a flavour of it. The focus on adaptive, prepares the customer the project will need to adapt and change. The longer the project continues, the more you learn about the business requirements and more feedback from the customer on the iteration/solution created.
Scrum forces customer to prioritize the items on the product backlog, you can add the high priority items to the sprint, which should give the most business value.
The priorities and scope changes with time and feedback, Scrum acknowledges this will happen and encourage
Change is inevitable but customers don’t expect or like it when it happens to their project. #HoskWisdom
When should you use Scrum?
- You should use Scrum on projects where its suitable to do incremental and iterative development.
- The product owner must have a good understanding of the business
- Where a product is hard to define upfront
- Where the customer is willing to devote time to the project
- Customer is willing to make quick decisions
Agile Manifesto
I mentioned the Agile manifesto earlier but lets focus on two points.
Customer colloboration
Successful projects involved a good relationship between the project team and the customer. The project should be a collaboration between the customer (business knowledge expert) and the technical team (solution experts).
Projects which don’t work well involves unsuccessful relationships between customer and project team dominated by one side, instead of a collaboration, failed projects are often involve one side dictating the solution.
When the customer (business experts) dominate you often end up with poor technical solution.
When the technical experts dominate the product doesn’t help the users achieve the business requirements or contribute to business goals.
Working Software
Sometimes people forget the goal of an IT project is to create a working solution to help the users achieve their business goals.
The Agile manifesto puts it right up front and focuses on getting a working product to the customer quickly to enable open and honest feedback. Scrum welcome customer feedback which might disrupt the current iteration.
The difference between the planned product and working software can be huge and the sooner the customer can see it and try it the sooner the product can be changed to give the customer an effective product.
Software innovation, like almost every other kind of innovation, requires the ability to collaborate and share ideas with other people, and to sit down and talk with customers and get their feedback and understand their needs.
Bill Gates
Development Team
In Scrum all developers are equal, have the same title and are all focused on delivering the sprint.
The development team are self organised and cross functional, enabling them to deliver a sprint without any outside assistance.
Scrum focuses on team work and empowering the development to find solutions to problems.
Progress monitoring
Splitting the projects into sprints allows the project to never fall to far behind schedule and if it does the customer knows quickly and a discussion can be had. This limits bad news to never being too bad before it‘s discussed with the customer (if it‘s bad).
Burndowns and velocity monitor the speed of the project and daily scrums make sure everyone is pulling their weight and problems are cleared.
The daily scrums ensure there is constant communication in the sprint team, progress is monitored and problems are raised with solutions found.
Any problems only have the potential to be one sprint long.
Product backlog
The product backlog is a prioritized list of requirements to be done. A list of deliverable’s grouped into sprints and prioritized (sprint backlog)
The concept of a prioritized list of deliverables avoiding prioritising and say all the deliverable’s are all high priority.
The sprint backlog of a sprint is the items are not changed once the sprint is started. This means the customer cannot add new items to a sprint and cause the sprint to be delayed. This process stops users squeezing more functionality in and extended sprints.
The working software and feedback keep happening at the end of every sprint.
Successful projects involved a good relationship between the project team and the customer. The project should be a collaboration between the customer (business knowledge expert) and the technical team (solution experts).
Projects which don’t work well involve unsuccessful relationships between customer and project team, instead of a collaboration, failed projects are often involve one side dictating the solution.
When the customer (business experts) dominate you often end up with poor technical solution.
When the technical experts dominate the product and hurts the users achieve the business requirements or contribute to business goals.
Sprint events
Each sprint has a number artifacts
Sprint
- The items to be delivered during the sprint
Sprint planning
- Done at the start of the sprint by the whole sprint team. The estimating is done by group vote, which gives an accurate average
Daily scrum
- A daily 15 minute meeting
- progress is monitored
- impediments are discussed and resolved
- standup so not to take too long
Sprint Review
- Showing the user the functionality of the sprint
- Feedback
Sprint Retrospective
- Discuss what worked well in the sprint
- Discuss what didn’t work well in the sprint
Looking at the framework all the events and activities seem like a great idea and are likely to help a project be successful. They give opportunities to inspect and adapt, to get feedback.
The reason many Agile projects go badly because often steps are missed and the Scrum team don’t understand what they are doing or why they are doing it.
Retrospective
One method for improving a team and individuals is to analyse past performance and work out what worked and what didn’t. This reflection often doesn’t happen because people don’t have time or don’t want to do it.
Scrum ensures you learn from past performance by scheduling a retrospective after every sprint. It looks at
- People
- Relationships
- Process
- Tools
What worked, what didn’t and how it can be improved for the next sprint.
Review
This quote is inspiring and scary
“We welcome changes in Scrum and encourage them to be demanded, because it increases satisfaction of the customer and will create a final product that better matches the needs of the customer“ Jeff Sutherland
The quote comes from the book – Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity
The quote initially seems like it could create a nightmare project with customer potentially giving lots of negative feedback but the goal of the project is create a product which is effective for the end users. Reviewing the product and getting feedback is a core part of collaboration with the customer and will increase the chance of creating a product the customer wants.
Considering the concepts of Agile and Scrum
Looking a Agile/Scrum I can see many aspects of successful projects. If you flip it round and look the common problems with IT projects
- Product not doing what the customer wants or needs
- Projects falls behind schedule
- Customer changing, adding or removing requirements
- Customer and developer team are not collaborating well
- Communication between the developers
Scrums uses many tools and techniques to resolve many of the common problems with IT projects. The goals of Agile projects are positive and if executing well the benefits can be great, faster projects, working product shown to the user and feedback given often.
“Scrum incorporate the concepts of continuous improvement and minimum viable products to get immediate feedback from consumers, rather than waiting until the project is finished“
Jeff Sutherland
Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity
Common language
A benefit of Scrum is it gives a common language for everyone to use. Common rules and processes must be followed by the customer and project term as outlined by the Scrum framework itself which insists on it.
It makes the customer prioritise requirements and stop adding or changing requirements half way through a sprint.
Summary
Scrum is made up of many good practices such as adaption, incremental/iterative development and getting feedback as soon as possible.
A goal of Scrum is to get feedback from the customer on a product as quickly, so can be changed to create a product useful to the customer.
The individual components of Agile/Scrum are good practices which makes me wonder why it generates such negativity.
Many companies sold Agile to customers as a super weapon to lowers costs, deliver projects quicker but Agile is suited on projects which can be delivered incrementally and where people are trained and experienced delivering Agile\Scrum projects.
The Agile framework reminds me of someone who has got a hammer, suddenly all problems look like nails and all projects look like Agile projects.
Many companies did Agile/Scrum projects without training people in the framework, if you don’t have some people with experience the project could hit problems without someone to guide the project back on course.
Companies need to make sure employees are given time to learn new skills and are not on project work 100 percent of their time. Agile projects can be relentless and it‘s possible the tasks are all focused on sprint backlogs with no maintenance, code refactoring, builds or house keeping tasks factored in.
Resources
The Scrum Master Training Manual: A Guide to the Professional Scrum Master (PSM) Exam
This ebook is free and gives a good overview
Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity
Written by Jeff Sutherland who was one of the creators of Scrum
Scrum and Xp from the Trenches 2nd Edition
You can buy it from Amazon or you can download it for free here
Confessions of a Scrum Master
free download here
Like this:
Like Loading...
Hosk's Dynamic Blog 