In this series of articles, I’ll share some feedback, insights, and questions about scrum implementation that I’ve gleaned from my experience as a scrum master and an Agile coach (and what my colleagues have shared with me as well)
Scrum Team appears to be a Component Team rather than a Feature Team:
A Component-based Team is a team whose primary focus is on a component or collection of components of the working software product that they are delivering. Here some examples of product/solution technical components:
Presentation/user interface/front-end layer, business logic/application programming interface/middleware layer, and database/back-end layer.
Individual team members in such a Component-based Dev Team begin to work in silos if they focus on individual components while placing a secondary priority on the overall software product.
I know that’s not good … why ?
This results in components with tightly coupled dependencies, reducing the team’s ability to collaborate effectively and create business value for their customers.
Team members should work across technical layers or components, they should evaluate their designs, flows, and the complete end-to-end functionality being implemented, thus reducing waste created during hand-offs -good news right ?- , both technically and functionally: This is known as a Feature Team.
Two benefits of Feature-based Dev Team:
- Improving collective ownership, accountability, and responsibility through increased collaboration, as all developers should focus on features/functionalities covering each technical layer or component.
- Increasing possibilities of delivering a potentially shippable increment of a high-quality working software product with its Done features
Daily Scrum Event = Status Meeting ?
It’s not true. Why ?
Team members should share their progress as well as the problems they are encountering, in order to inspect, adapt, and help each other as a self-organizing team to deliver the desired product increment by the end of each Sprint.
The Scrum Masters should ensure that the teams understand why it is important and how it increases the chances of meeting their Sprint Goal.
Sprint Reviews = Showcase Demos ?
False.
True, demos are an essential component of every Sprint Review, but Sprint Reviews are not limited to demos.
Sprint Reviews should serve as enablers for gathering feedback from stakeholders, during which time they should assess completed Sprints, review their product/solution release planning, discuss last market conditions/trends, and customers satisfaction.
The Scrum Team will evaluate the feedback received and focus on what needs to be done next.
No feedback , How we could inspect and adapt during retrospectives ?
Sometimes, Scrum teams are not speaking enough during retrospective sessions.
Sometimes they lose honesty and openness to share feedback.
Sometimes they feel like Retrospectives are boring and ineffective.
Scrum Teams strive for continuous improvement, but they frequently overlook the Sprint Retrospective Event.
This event is an incredible opportunity for them to discuss what went well, what did not, and whether or not there are any suggestions to improve their Agile way of working and being.
The Scrum Master should create a safe environment in which openness, courage, and trust can flourish. In this environment, the team should share their valuable feedback and speak up. (a good video from Timothy Clark https://www.youtube.com/watch?v=Enrosv7iLTE)
It is also beneficial for the Scrum Team to recognize the good things that occurred during the Sprint and to discuss and decide on action items to improve upon in future Sprints.
What role do testing and quality assurance play within the scrum team?
Some Scrum teams are unaware of the most advanced testing and quality assurance practices.
Scrum is a framework for developing, delivering, and maintaining complex software products; however, it does encourage Developers — as a cross-functional team- to use practices required to improve the overall quality of every software product increment they release by the end of each Sprint.
These activities or practices should be taken into account during an ongoing sprint.
Manual, exploratory, automation, functional, non-functional, smoke, sanity, regression, ad-hoc, continuous, mutation, and other required types of tests should always be performed by developers.
They should also verify that continuous testing is carried out rigorously at all levels: unit testing, integration, system integration, acceptance, and so on.
