“It's time to ditch Definition of Ready ?"
It is a bit of a controversial article and I have my own views. However, the author seems to share his vows through this article around Definition of Ready.
As a Product Owner, I needed help from another team. My request was quite simple: to send a file they were already producing over SFTP to a third-party. I added an item to their Product Backlog with all the bells and whistles: title, description, business value and acceptance criteria.
The ticket was refined and planned for the next Sprint. The team contacted me and told me everything was clear. They asked if I could provide the SFTP credentials of the third-party.
I immediately asked the third-party to provide us credentials to the different environments. Unfortunately, the third-party did not respond before the Sprint started.
When I was checking my e-mail in the office on Monday morning, I found out my Backlog Item was removed from the Sprint. I would need to wait another two weeks.
When I asked why they removed it, they answered the ticket did not meet their Definition of Ready and was removed from the Sprint as a result.
Two main arguments are commonly used to support the use of a Definition of Ready:
- Making clear to stakeholders what we need from them in order to make Backlog Items clear.
- Preventing Backlog Items from being unclear before the team starts working on them.
1. Scrum already prescribes what makes a Backlog Item “Ready” for Sprint Planning
Willem-Jan Ageling pointed out to me that Scrum already prescribes what makes a Backlog Item “Ready”.
Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. — Scrum Guide
In the Scrum Guide it is explicitly stated what makes a Product Backlog Item “Ready”. If the Development Team believes it fits in a Sprint, then it’s ready to be worked on.
2. Product Backlog Items in Scrum already contain enough information to get started
A Product Backlog Item should possess the following information according to the Scrum Guide:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”. — Scrum Guide
3. Sometimes just a title may be enough to start working on something
Imagine your Sprint has started and someone from the Development Team notices a big production issue. She discusses it with the team and quickly adds a Backlog Item to the Sprint with just a title. She starts working on it immediately and clarifies the description as more information becomes available about the underlying problem.
4. It’s already up to the Development Team to change the Sprint Backlog during a Sprint
You don’t need a Definition of Ready to stop messy and unclear Backlog Items from being added to the Sprint.
Imagine a Sprint has started and somebody wants your team to work on something during the Sprint that is too vague. You don’t need a Definition of Ready to prevent this from happening.
The relevant passage from the Scrum Guide:
Only the Development Team can change its Sprint Backlog during a Sprint. — Scrum Guide
5. Definition of Ready conflicts with Agile way of working
Let’s take a look at 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
With these sentences in mind that capture the essence of Agile, how does a Definition of Ready fit in?
Read the rest of the article
here
"What comes after Scrum? - Ken Schwaber"
Scrum is not the be-all and end-all process for software and product development. As many of you have noticed, it is barely a process, only a framework. You have to provide all the development, management, product management, and people practices.
So, what does Scrum provide? It provides a labeled- environment within which complex development can be successfully managed (where the unknown is greater than the known). Scrum provides containers that allow teams to focus on one aspect of a complex problem at a time. The containers are short-time boxes so that risk can be managed.
Scrum can be replaced or superseded by anything that also supports its underlying principles:
1. Self-organization – people doing complex work are much more effective organizing themselves and the work than someone who isn’t doing the work.
2. Bottom-up intelligence – figuring out how to do work is a management activity best performed by the people doing the work, since the work is unpredictable, with many twists and turns.
3. Empiricism – it is hard to plan what you don’t know, so we instead see what has been accomplished, and then figure out what to do next. We do this frequently to control risk and determine the best path to our goal.
4. Transparency – we periodically have to know what is actually happening to make effective empirical decisions.
As stated in bible of process control (“Process Dynamics, Modeling, and Control”, Ogunnaike and Ray, Oxford University Press, 1994) , there is no bad process. However, sometimes processes are applied to inappropriate situations. Scrum is an empirical process built on lean principles. It is most appropriate for optimizing complex work.
I welcome anyone who comes up with the next great process, one that does all of the above even better than Scrum. I’m still waiting.
Read the original article
here
Large-Scale Scrum(LeSS)
HOW TO AVOID WRITING NEW LEGACY CODE
(Excerpts from Practices of Scaling Lean and Agile By Larman and Vodde)
“We promised this release to our key customer, and the only acceptable commitment from R&D is the first of February,” said an angry email sent by a director to the management of the product group we were coaching. We read it in disbelief and wondered about the only acceptable commitment. We decided to ignore the email—for now— and get back to normal work—coaching a developer in refactoring a legacy component that was hacked together last release to meet that deadline.
Many companies are stuck in a vicious cycle of forced promises and See unrealistic commitments. In today’s time-to-market era, customers force’ them to promise too much. “If you cannot deliver by the end of the year, we will buy from your competitor who will make that promise.”
Sales people or executives could respond by being transparent and by working toward a mutual beneficial long-term relationship (customer collaboration), but instead they check whether the contractual penalty for being late is tolerable (contract negotiation) and reply, “Yes, no problem, we can do it!” After which the same cycle starts within the organization. The executive orders the head of R&D to “do it” and “make it happen” because “it is a customer promise.”
The promise travels through the organizational hierarchy to the developer, who cannot pass it on any further.
How does the developer react? Charles Lecht [Lecht67] already warned us over 40 years ago: The developer will “feel the obligation to respond out of respect, fear or misguided loyalty” and reluctantly commit to the deadline. The developer opens his secret toolbox and does everything possible to make the short-term deadline by using tools such as hardcoding, copy-paste-modify programming, skipping testing, working overtime, and other quality-destroying shortcuts [Schwaber07a]. Nobody notices the use of these ‘tools,’ and so the deadline is made. Management rewards developers for their hard work and applauds their “great teamwork” and “fighting spirit.”
These quality-destroying shortcuts result in bad legacy code, which slows down the development and the organization falls behind its competition. A predictable scenario unfolds. They need to reclaim the market and therefore make new promises, starting the vicious cycle all over again. The technical debt—the legacy code—makes development go slower. The learning debt—lack of renewal in developer skills—compounds this slowdown.
No comments:
Post a Comment