Agile SCRUM should be seen as a Practice and not a Process or Methodology.
Practice, or process, or methodology what’s the difference?
Following a process and methodology are generally viewed by most people as following something without question, as that is what everyone else is doing. The original intent or goal of these often gets lost, and bureaucracy takes over. Even if the process and methodology state they should be reviewed, because they are reviewed mostly from the perspective of the process rather than the original intent or goal, the focus of the review ends up on the wrong thing.
So I thing practice is a much more representative way of describing SCRUM and the intent behind it. SCRUM is described as a development framework, within Agile practices, that asks teams to practice and perfect their skills by planning, executing, delivering, then inspecting so that they adapt the next time round. (Kind of sounds like the Continuous Improvement ethos ”Plan-Do-Check-Act” associated with processes doesn’t it).
Practice is about doing something, learning then doing it again, and so on, always getting better.
So what are the basic SCRUM processes, I have represent them below in a slightly different way to a lot of the diagrams you will see out there. For me the practice part is often not shown but just implied, the feedback loop from Team Retrospectives is essential and should be flashing in my view!
In the end of the day it is quite simple, that”s the beauty of it, and if it starts getting complex stop and question what you are doing. (In another Blog I will talk about enterprise or multi-team SCRUM)
You have a Product Backlog that the company leadership has helped the Product Owner(PO) to prioritize the features that are of the maximum value to the company”s customers. Now getting to this is a whole other practices but for now let”s just assume that market, technical architecture, significant events and feature needs are all taken into account.
The first step is for the team to work with the PO, in the Planning Meeting, to take the top of the Product Backlog and estimate how much can be done in the next sprint. Now ”done” means releasable to the customer…tested, deploy-able and meeting any organizational standards that have been set.
Once the Sprint Backlog, again in priority order, is agreed the team explicitly commits to have the work done, key here is ”Team” and ”Commits”. From this point forward the team owns the outcome and how it gets to the ”done” point.
Next the Sprint Iteration starts, iterations must be from 1 to 4 weeks, yes I say ”must”. Under this I would as what you get done, over this and I would ask you how much waterfall documentation (waste) you create to manage the work.
Within the sprint iteration the team works done the sprint backlog from highest priority to lowest, again ”team” and ”highest to lowest” are the key phrases, the focus should be to get backlog items ”done” and deliver the maximum value by the whole team.\nTeam member should organized themselves based on the most effective way of getting work ”done”, not always the same thing as job title.
Within the sprint iteration there is a ”Daily Standup” that all members of the team attend, each member answers 3 questions:
- What have you done since the last Daily Standup?
- What will you do between now and the next Daily Standup?
- What impedes you from performing your work as effectively as possible?
There is no problem solving or investigation in this meeting, it is time boxed to 15 – 30 minutes depending on team size. The Scrummaster who runs the meetings for the team, will follow up with discussions and actions for any issue raised.
At the end of a Sprint Iteration there is a Sprint Review meeting is held where the team demonstrates what they have reach ”done” on during the sprint to the Product Owner and any other key stakeholders from outside of the team. If it is not ”done” it cannot be shown, Powerpoints, documents, etc. do not constitute functionality are not to be presented as work done. This meeting should only take a maximum of 1 hour to prepare for.
Functionality not committed to and not ”done” is highlighted in the backlog.
The Product Owner is asked explicitly if they accept the results of the Sprint. This will trigger the appropriate steps for release of functionality.
After the Sprint Review a Sprint Retrospective is held with only team members present (should include the PO), this meeting is the foundation of SCRUM in my view. This is where the team inspects what they did and discusses how to improve, the lessons learned and improvement ideas are then taken in to the next sprint planning meeting and applied.
The practice of SCRUM is focused on delivering the highest value to customers in iterations that allow teams to learning from each iteration and improve for the next iteration to deliver more value to the customers.
This is the practice of software development not a software development process.