At SSW we have always done Agile. Recently we have started doing Scrum and we have nearly completed our first Sprint ever using Scrum. As you probably guessed from my previous post, it looks like it is going to be a “Failed Sprint”, but the Scrum Team (This includes the ScrumMaster and the Product Owner) has learned a huge amount about working in the Scrum Framework.
Update 16th March 2010
- Kane Mar , suggested a fantastic quote from Kent Beck.
We have been running with a “Proxy Product Owner” for the last two weeks, but a simple mistake occurred either during the “Product Planning Meeting” or the “Sprint Planning Meeting” that could have prevented this Sprint from failing. We has a heated discussion on the vision of someone not in the room which ended with the assertion that the Product Owner would be quizzed again on their vision. This did not happen and we ran with the “Proxy Product Owner’s vision for two weeks.
Product Owner vision: Update Component A of Product A to Silverlight
Proxy Product Owner vision: Update Product A to Silverlight
Do you see the problem?
If the people who tell you what to do don’t agree with the people who evaluate what you are doing, you’re stuffed. – Kent Beck
Worse than that, as we had a lot of junior members of the Scrum Team and we are just feeling our way around how Scrum will work at SSW I missed implementing a fundamental rule.
That’s right, it was me. It does not matter that I did not know about this rule, its on the site and I should have read it. Would a police officer let you off if you did not know that a red light meant stop? I think not…
But, what is this amazing rule I hear you shout..
Its simple, as per our rule I should have sent the following email:
“ Dear Proxy Product Owner,
For the record, I disagree that the Product Owner wants us to ‘Update Product A to Silverlight’ as I still think that he wants us to ‘Update Component A of Product A to Silverlight’ and not the entire application.
Regards
Martin”
- ‘For the record’ - Rules to being Software Consultants - Dealing with Clients
This email should have been copied to the entire Scrum Team, which would have included the Product Owner, who would have nipped this misunderstanding in the bud and we would have had one less impediment.
Technorati Tags: SSW Scrum Silverlight
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
What to read next
Adventures in Scrum: Lesson 1 – The failed Sprint
Explores common pitfalls in early Scrum adoption, highlighting why full team involvement in sprint planning is crucial and lessons learned …
My first Scrum team in the wild
A real-world account of guiding a new Scrum team through their first sprint, covering estimation, story points, sprint planning, and …
Do you have a contract between the Product Owner and the Team?
Explains the benefits of a Sprint Contract in Scrum, clarifying roles and agreements between Product Owner and Team to improve collaboration …
Are you doing Scrum? Really?
Explains recent changes to Scrum aimed at reducing rigidity, clarifying core practices, and providing a checklist to help teams assess if …
Pragmatism crushes Dogma in the wild
Explores how practical use of Scrum fosters adaptability and resilience in teams, highlighting the value of flexibility over rigid rules in …
Debunking the Top 5 Myths About Scrum: Unlocking Agile Success in Your Organisation
Explores and corrects common misconceptions about Scrum, clarifying its true principles, events, planning, and governance to help teams …
Detecting agile theatre with real delivery signals
Why Most Companies Operating Models Fail in Dynamic Markets
A concise comparison of Predictive and Adaptive Operating Models, explaining why traditional structures fail in dynamic markets and how …
Don’t Manage Dependencies, Remove Them
Explains why dependencies are a sign of poor system design and outlines steps to eliminate them by aligning teams, clarifying ownership, and …
The Estimation Trap: How Tracking Accuracy Undermines Trust, Flow, and Value in Software Delivery
Tracking estimation accuracy in software delivery leads to mistrust, fear, and distorted behaviours. Focus on customer value, flow, and …
Flow of Value vs Flow of Work – Misnomer or Useful Shorthand?
Compares “flow of value” and “flow of work” in Kanban, explaining why only validated outcomes count as value and stressing the need for …
Why Outsourcing DevOps Fails, and How Real Engineering Excellence Starts With Your Team
Avoid DevOps vendor lock-in, discover how true engineering excellence starts with partnership, not outsourcing. Ready to transform your …
The Definition of Done is a Commitment to Quality
Defines the Definition of Done in Scrum as a clear, shared standard for quality, ensuring increments are releasable, transparent, and …
Why Your Definition of “Done” Is Holding Back Quality, Agility, and Trust, And How to Raise the Bar
Is your team’s “done” really done? Discover how a clear, objective definition of done boosts quality, agility, and trust in product …
Acceptance Criteria vs Definition of Done: Why Getting This Right Builds Trust and Delivers Quality Faster
Stop confusing acceptance criteria with definition of done, learn the crucial difference to boost quality, speed, and trust in your agile …
How to Evolve Your Definition of Done: Start Small, Grow Smarter, and Build Lasting Momentum
Unlock a smarter Definition of Done, start small, evolve standards, and build team momentum without overwhelm. Discover how progress drives …
Why Most Transformations Fail Without Honest Conversations
Most transformations fail without open, honest conversations that address real issues, making transparency and tough dialogue essential for …
Why Your Definition of Done Is the Secret Weapon for Real Business Impact and Agile Growth
Transform your definition of done into a strategic advantage, deliver real value, reduce risk, and drive business impact with every sprint.