Have you understood Scrum? Or have you understood Scrum?
Review the logical data model with the clients and rework if there are any changes needed
“Complete the system technical architecture document. Submit three interface design specification documents for review. Review the logical data model with the clients and rework if there are any changes needed”— was the Sprint Goal of yet another struggling Scrum teams.
A few days later-
“Can we shorten the scope of the Sprint Goal?” — said one of the Development Team members during the Daily Scrum.
And the Sprint Goal was modified to — “Complete the system technical architecture document. Submit one (not three) interface design specification documents for review. Review the logical data model with the clients (incorporate client comments in the next Sprint).”
A day before the Sprint Review-
“Can we formulate the Sprint Goal closer to reality?” — said one of the Development Team members during the Daily Scrum.
And the Sprint Goal was modified to — “Complete the system technical architecture document. Send the logical data model to the clients for offline review”.
During the Sprint Retrospective, the Scrum Team addressed the issues due to which originally formulated Sprint Goal was changed during mid-Sprint and “pledged” to not modify the Sprint Goal in between the Sprint as it defeats the essence of Scrum.
They also discussed that during the Sprint Planning Meeting, the Development Team should do due diligence before moving the stories from the Product Backlog to the Sprint Backlog.
The Product Owner recommended that the Scrum Team perform the Agile Maturity Assessment of the project and look at areas where they need to improve.
The assessment score was 4 out of 5 points and indicated that the project is on the right track to implement Agile methodologies and Scrum framework.
The Scrum Master “told”: “Let us formulate a more realistic Sprint Goal for this sprint.”
Which came out as:
“Complete the system technical architecture document. Complete (with review) three interface design specification documents. Finalize the logical data model (complete with all reviews).”
Photo by Paul Hanaoka on Unsplash
The system technical architecture document was finally completed in four Sprints, feel free to guess on the remaining.
How did the project receive an assessment score of 4?
Most of the simple Agile Maturity Assessment Models are based on a point system and follow an objective approach. For example, these models may ask the following questions:
- How often do you hold the Daily Scrum Call?
- Do you conduct Sprint Retrospective meetings and capture notes on Confluence?
- Do you run a Sprint Planning session and track the Sprint progress through Sprint Backlog?
- Do you create the Sprint Goal at the start of every Sprint?
- Do you focus on creating a valuable increment after the end of the Sprint?
And so on…
Photo by Glenn Carstens-Peters on Unsplash
When the Scrum Team did their assessment, they scored well on all the above questions as they are religiously following all the Scrum events. They have defined all the Scrum roles and maintain all the Scrum artifacts.
Why did the Scrum team members focus on creating the system technical architecture document?
The client contract (legal statement of work between the project team and the client) mentioned system technical architecture document as one of the payment milestones deliverables.
In turn, this led the Scrum team to focus on delivering system technical architecture document so that they can get paid on completion of the first milestone.
Was the legal contract just an excuse?
Let us look into what the Scrum Guide says about the role of Product Owner;
“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” — The Scrum Guide, 2017
and continues to mention
“Optimizing the value of the work the Development Team performs;”
In this situation,
Did the Product Owner believe that the creation of a system technical architecture document will maximize the value for the stakeholders?
Did he/she consider to optimize the value of the work that the Development Team is performing?
“Scrum Master Service to the Product Owner: Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;” — The Scrum Guide, 2017
Did the Scrum Master ensure that the Product Owner is arranging the Product Backlog to maximize value by prioritizing the system technical architecture document?
“Scrum Master Service to the Development Team: Helping the Development Team to create high-value products.” — The Scrum Guide, 2017
Did the Scrum Master consider that the system technical architecture document is the high — value product that the development team should deliver?
Did the Development Team believe that by creating the system technical architecture document, they are producing value and showing respect to their stakeholders?
Let us look at the Definition of Scrum;
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — The Scrum Guide, 2017
The Scrum Team understood Scrum, and they had defined roles, artifacts, and events as defined by Scrum.
Did the Scrum team members understand the Scrum? Or was it just an artificial implementation of Scrum?
I think the better approach could have been to start delivering value (in terms of product increments) in initial sprints itself. Some people may argue that how can we meet the expectations of the contract then. I would suggest not to hide behind the contractual terms and to avoid making it an excuse to do the things better.
Let us turn the situation a bit here. Let us assume that the Development Team demonstrated the working product prototype. Do you think that the client would have asked the Development Team to stop work on the increment? Do you think that the client would have asked the Development team to create the document first?
I believe "No". I think the client would have preferred working functionality over a non-working document.
Rather, it could have turned into a more straightforward conversation with the clients to review the contractual terms and who knows they never wanted the system technical architecture document in the first place. I believe that we can amend the legal contracts; we have not carved them in stone.
We create legal contracts only to safeguard the interests of the parties involved, and nobody wants to break them intentionally. And I also think the stakeholders certainly will embrace the amendment if they see it more effective and valuable.
Now, let us again look at the two questions that I asked in the title of this article -
Have you understood Scrum? Or have you understood Scrum?
Are you only following the mechanics of Scrum or are you embodying the true spirit of it? If it is former, you may not be able to see the benefits of Scrum framework implementation,
and the world would look like the same as it was earlier before Scrum. If you have understood the essence of Scrum, you are on the right path to deliver maximum value to your clients faster.
Scrum implementation should not be understood as mere following the Scrum events, creating the Scrum roles, and producing the Scrum artifacts.
To call it a successful implementation of Scrum, we should understand the true essence of the Scrum framework. Scrum is founded on empirical theory. Three pillars of inspection, adaptation, and transparency uphold the implementation of every empirical process.
The Scrum team members should learn and explore the Scrum values inside out.
Once the Scrum team members have discovered a way to deliver high productive value to their clients, they can easily handle the impediments of contractual obligations. It is always worth to focus on the outcome than output.