Category: Agile Antipatterns

Myth about baselining the Sprint Lengths at the start of the project

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing the a contract – But like everything in scrum, the Sprint length needs to be open for Inspection and Adaptation

Common Misconceptions and negative implications

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing a SoW or a contract.

Recommendations

  • Scrum Guide recommendation is to keep the Sprint Length “Consistent”. Scrum Guide does NOT recommend a “Fixed” Sprint Length. We can change Sprint Length if there are negative implications being caused because of incorrect Sprint Lengths.
  • Considerations for changing the Sprint Lengths
  • Changing Longer Sprint Lengths to shorter Sprint Lengths (say 4 weeks to 2 week)
    • The scope keeps changing during the Sprint and Sprint Backlog becomes a mess. What we started off at the time of Sprint Planning and what we ended up in a Sprint Review is drastically different
    • Teams develop a “student syndrome”. Means – team takes it easy for the first couple of weeks. Then goes for a dash to the finish. The team then ends up working 18 hour days for last 2-3 days
    • The feedback is so drastic each Sprint Review that you need to re-work the whole thing. Think about the Sprint Length if this happens frequently.
    • Teams and PO don’t speak to PO often and communication breaks down resulting in no or minimal feedback during the Sprint.
  • Changing Short Sprint Lengths to Longer Sprint Lengths (say 1 week to 4 week)
    • Teams come under a huge stress. Deliverable every Friday is not easy. The stress levels take a toll and teams get sick of the stress.
    • Innovation goes down with very short sprint lengths. Teams become very “short-term” focussed.
    • Dividing items into smaller units becomes difficult. Beyond a point, breakdown of Product Backlog Items becomes a formality/academic rather than a real need.
    • Spilled-over work to next Sprint becomes common with very short sprint lengths. Teams are unable to create something useful.
    • Motivation goes down because of stress levels or not being able to get the Sprint to produce something usable every Sprint or stakeholders constantly feeling upset about not being able to complete.
  • DISCLAIMERS SO THAT YOU DON’T MIS-UNDERSTAND OUR STATEMENTS ABOVE
    • DO NOT keep changing the Sprint Lengths often. Try a Sprint Length, see if it works. If it does not work, then change. Once you find a length which is solving most of the problems, then stick with it. Be CONSISTENT. Being able to change the Sprint Length does not mean you become random and chaotic in the way you work.
    • DO NOT think that there is a “PERFECT Sprint Length”. There can never be a “Perfect Sprint Length”. See what Sprint Length solves “MOST” of your issues.
    • DO NOT change the Sprint Length when you are inside the Sprint. Just because you are not completing a Scope, does not mean, you change the Sprint Length by extending it. Sprint ends when a Timebox ends. You may think about changing the Sprint Length from the next sprint onwards.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-baselining-the-sprint-lengths-at-the-start-of-the-project/

Myth about Definition of Done being baselined before project starts

definition of done is often looked at a checklist that is set in stone-something not evolving – let us discuss how Definition of done evolves

Common Misconceptions and negative implications

  • Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
  • By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
  • Lot of time then gets wasted in trying to get the product too precise and the releases get delayed

Recommendations

  • Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
  • There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
  • As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
  • However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
  • For example : One could start with a definition of done as
    • Acceptance criteria for functionality is met
    • User Documentation is completed 
    • Integration testing is done
    • Regression testing is done
  • As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
    • Acceptance criteria for functionality is met
    • User Documentation is completed
    • Integration testing is done
    • Regression testing is done
    • Performance testing is done
  • So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
  • By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
  • It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-definition-of-done-being-baselined-before-project-starts/

Myth about Scrum Master being a renamed Project Manager role

A commom question often asked – Can we treat the Scrum Master as “The Project Manager in Scrum World?” – Let us understand how the world differs

Common Misconceptions and negative implications

  • Organizations implement Scrum Master role by renaming all their Project Managers as Scrum Masters just because they want to do Scrum or try Scrum. Scrum Master is the most mis-understood role in the industry.
  • Scrum Master remains the same “Command and Control” role
  • Scrum Master is made accountable for Product Scope, Product Delivery, Product Quality, Product Budgets and Project Timelines. Management holds one neck and that is Scrum Master’s neck
  • Scrum Master becomes a coordinator as the Project Manager used to be

Recommendations

  • Scrum Roles are designed in such a way that the right role takes the right accountability. The Project Management was a centralized accountability model where Project Manger was made accountable for everything. Scrum is a distributed accountability model. The Product is owned by the Product Owner. So, the accountability of Scope, Cost and Time is given to the PO. The Developers is made accountable for the delivery. So, Quality is the accountability of the Developers. Scrum Master is the guardian of Scrum. He/she is a coach and facilitator who makes things happen by making the right role take up the right accountability.
  • As a Coach, Scrum Master is a leadership role who guides the PO and Developers into following the Scrum Framework. Scrum Master makes the PO, Development Team and the Organization aware of the self-organized model, cross-functional teams, product accountability, complexity handling, importance of timeboxing, tools, techniques – in general Scrum framework as a whole.
  • As a Facilitator, Scrum Master makes sure that focus on getting decisions done and progressing towards goal. Scrum facilitates meetings, communications and helps the PO and Developers to come to conclusions. Many a times, the delay in decision making is the major cause of productivity issues. People don’t come to conclusions. Scrum Master’s job is to get the people to conclusions.
  • As an Impediment Solver, Scrum Master reaches to the right entities of the organization and gets right help at the right time so that team can proceed.
  • Scrum Master is a Servant Leader whose job is “to serve”. The accountability of doing the product work is given to  the Product Owner and Developers. Since Project Manager is responsible for Scope, Cost, Time, naturally it becomes a “Command and Control” role. The leadership styles are completely different.
  • Scrum is based on the “Fail-Fast ” model vs the Project Management which is based on “Don’t Fail” model. Scrum encourages the team to fail and let the team learn from mistakes. Project Manager makes sure that as much risk mitigation is done so that mistakes don’t happen. Scrum Master’s job is to allow mistakes and let the team learn from mistakes. Project Manager’s job is to prevent mistakes. They are diametrically opposite in the thought processes.

With so many drastic differences, if the Project Managers are renamed as Scrum Masters, the way people think is no different than what used to happen in waterfalls. Naturally done, we are setting up things for failure if Project Managers are renamed as Scrum Master. Lot of training and mentoring of Project Managers is to be done so that the Project Managers think differently to what they used to do while they were project managers.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-scrum-master-being-a-renamed-project-manager-role/

Myth about Sprint Backlog being a commitment

Common Misconceptions and negative implications

Most leadership and product owners feel that Developers has to commit to a scope during the Sprint Planning. That is, most leadership try to implement the concept of “baseline scope” for the Sprint.

  • By doing this, it prevents opportunities for inspection and adaptation during the sprint.
  • Team gets “locked” into delivering baselined scope instead of trying to find out if they are going in the right direction or wrong.
  • Critical opportunity to inspect and adapt is then lost and deviation is detected during the Sprint Review.
  • Then starts the discussions on “change requests”, “sign offs”, “not being able to give scope properly”When the Developers yields to pressure of delivering baselined scope, the team comes under pressure and naturally working hours increase. More dissatisfaction results.

Recommendations

  • At the time of Sprint Planning meeting make only a forecast instead of commitment. One should have an openness to change if the need be instead of making the team commit.
  • Adapting quickly helps one get more closer to what is required to be done really.
  • Once an attitude develops with the team that “we are adaptable” and “not everything needs to be done as per forecast” teams become more receptive to the change.
  • Sprint Backlog always evolves – and let it evolve. The whole point why we are doing Scrum is because of the “unknown” nature of the work.
  • The reason the teams are reluctant to accept changes in the Sprint Backlog is because they are asked to work late and deliver the commitment and at the same time accept all last-minute changes. One must remember that there is always a cost of the change. However, the cost of the change is taken in terms of a Scope compromise in Scrum. That means if the Sprint backlog changes, something in the Sprint Backlog may have to be pushed to the next sprint or later.
  • One must remember that while the Sprint Backlog evolves, does not mean we are random and chaotic in our way of work. We are handling changes. We are not in Chaos. That means, if the changes are big, and big changes are happening frequently then it is time to either look at how we are gathering our requirements or if the Sprint Lengths are to be shortened.

This article is re-published on WORLD OF AGILE website – https://worldofagile.com/blog/myth-about-sprint-backlog-being-a-commitment/

Myth about Daily Scrum being a status meeting

Daily Scrum is an opportunity to inspect and adapt -its NOT a Status event

Common Misconceptions and Negative implications

Most teams conduct Daily scrum as a status meeting. When this happens, following negative implications result

  • Developers start thinking that this is Scrum Master’s forum
  • Developers don’t take accountability
  • Developers lose interest and start saying “there is nothing to status report every day”

Recommendations:

  • Primary intention of Daily Scrum is to Inspect and Adapt. This is supposed to be a forum where the Developers finds out if things are going in the right direction. If they are not, then it is time to discuss the same and adapt as soon as possible. If required, the scope needs to be adjusted, decisions need to be taken so that the Developers comes back on track.
  • It is good to keep the “Sprint Goal” at the centre when the Daily Scrum discussions are on. This is not about day-to-day tasks. This event is about knowing if we will be meeting the “Sprint Goal” or the business objective.
  • The three questions (while they are not compulsory in Scrum) actually are mis-understood by most teams. The three questions are not about “What did you do?”, “What are you going to do?”, “What are your impediments?”. The tree questions are about Sprint Goal and not about what tasks you are doing . So the correct 3 questions are

· What did I do yesterday that helped the Developers meet the Sprint Goal?

· What will I do today to help the Developers meet the Sprint Goal?

· Do I see any impediment that prevents me or the Developers from meeting the Sprint Goal?

  • Daily Scrum is also an important opportunity for collaboration for the Developers. Scrum Master is actually a facilitator in this forum. Scrum Master’s job is to make sure
    • The Daily Scrum happens
    • Negative things which happen regularly are prevented
    • To make sure that it finishes off on time within 15 minutes and teams are free to go back to work.
  • The only mandatory participants of Daily Scrum therefore are the Developers members and not Scrum Master and Product Owner. PO if at all joins,  his presence is limited to clarifying scope.

This article is re-published on WORLD OF AGILE website – https://worldofagile.com/blog/myth-about-daily-scrum-being-a-status-meeting/