Author: Snehamayee Kulkarni

Scrum Guide 2020 – What’s New?

Scrum Guide 2020 – What’s New?
Excitement is in air. The new scrum guide is out. Like always there is a great curiosity among agile enthusiasts to see how the guide to scrum has evolved.

Excitement is in air. The new scrum guide is out. Like always there is a great curiosity among agile enthusiasts to see how the guide to scrum has evolved.

Over the years Scrum Guide has changed considerably. A very key point to keep in mind would be that “Scrum” has not changed – Jeff and Ken have inspected and adapted the guide to Scrum so that Scrum is articulated clearly and concisely.

Here, in this series, I have articulated my understanding and perspective on how the guide has evolved in its latest avatar. Some Of the themes I want to explore in this series are::::

  1. Purposefully Incomplete – First time, the authors have put it on the paper that scrum guide is Purposefully incomplete. In my eyes, this drive to make things less prescriptive is behind many of the changes in scrum guide.
  2. Some Ideas Formally Included First Time in The Guide – Some ideas and Principles like Lean , product goal , formal specification of commitments are formally included first time in this guide. Some of these were already practiced by many as a beneficial. Now they are included in the guide formally. This formal inclusion helps to further the Scrum cause of focusing on value
  3. Some Changes That Bring in More clarity – Along with concepts formally included for the first time, we can see some small but significant changes. These changes bring a wonderful clarity. Some items in this list are rewording of scrum master being a servant leader or the team being “self managing” instead of “Self organized”
  4. What Has NOT changed – Perhaps the most important theme, I want to explore. Scrum is delightfully incomplete and its a very satisfying exercise to contemplate what has not changed and more importantly why? These are the aspects of scrum that provide the anchor to our thought process.

Myth about Sprint Review being a sign-off event or a demo forum

Teams some times think of Sprint Revierw as a “sign off” from the Product Owner – this reduces the opportunity to get feedback from stakeholders –

Common Misconceptions and negative implications

Sprint Review is thought to be a “sign-off event by the Product Owner” or “a demo forum by developers” by most organizations. This is an INCORRECT understanding of the Sprint Review.

Sprint Review is actually a feedback solicitation forum. The Scrum Team seek feedback from the stakeholders during the Sprint Review. This helps address the deviations. The Product Owner and Developers work together on a day-to-day basis. The Product Owner DOES NOT wait till the end of the sprint to give feedback to the Developers.

Recommendations

  • Product Owner needs to participate during the Sprint and provide feedback throughout the Sprint to the team. This gives an opportunity to the team to work on the feedback by the PO and adapt if required. This also gives opportunity for the PO to get the product ready by the time the Sprint ends.
  • Product Increment is considered as an INPUT into the Sprint Review and not an output as thought by many people. Therefore, sign offs (if any) have to be done before the Sprint Review starts. Also the sign-off – if anyone has to do – it has to be the Product Owner. That’s why the word “Owner”.
  • When the Sprint Review starts, the Product Owner and Developers have to be in sync with what is being shown to the stakeholders. If both the roles are in sync, then Sprint Review becomes an excellent opportunity to solicit feedback from stakeholders – who could be sales teams, marketing teams, sponsors, end-user representatives etc.
  • If one wants to use the word “Demo”, then my recommendation is to use the word during the Sprint when Developers demos the product continuously and seeks feedback from the PO. Demo should be ongoing and day-to-day where-as the Sprint Review is the minimum opportunity to solicit feedback from stakeholders.
  • Some may argue that getting Increment is impossible considering that stakeholder feedback happens in a Sprint Review. What we really recommend is that Sprint Review should be a “minimum” forum to seek feedback from stakeholders. Scrum does not stop you from getting more feedback from stakeholders during the Sprint.
  • The objective of the Sprint is to get a “usable” Increment at the end of the Sprint. This is possible if feedback is taken frequently from stakeholders – at a bare minimum during the Sprint Review. The Product Owner feedback should be day-to-day

Sprint Review therefore, is an informal opportunity for the Scrum Team to solicit feedback from stakeholders and make sure that the deviations are addressed.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-sprint-review-being-a-sign-off-event-or-a-demo-forum/

Busting Myths around Scrum

Myths

Scrum is a framework for solving complex adaptive problems. Scrum does not describe any tools, techniques and best-practices. Most people misunderstand Scrum and make assumptions on Scrum. The set of articles in this section are intended to bust some of these myths around Scrum.

Scrum is a framework to handle problems which are complex in nature. Complex Adaptive Problems are also called Empirical problems. That means for certain problems, knowledge can only come from experience and what you see. so the decisions are based on what you see in front of you. Scrum is an implementation of this principle.

One must understand that Scrum is purposefully incomplete. The tools, techniques and practices are not part of the core Scrum. The reason why Scrum is purposefully incomplete is because Scrum is generic and can be applied to any industry. The tools and techniques are specific to industries and are described in the industry specific methods.

Please refer to the following links to know more about Scrum Myths

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/busting-myths-around-scrum/

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/

Agile Metrics – Friend or Foe

how to create a Metric framework for for your Program – How to choose Agile metrics , How to derive value from your Agile metrics

Agile Metrics is an area that causes quite a heartburn for many agile practitioners. There are strong advocates on both sides of debate. Some people will insist that everything you can measure -you should measure. They will say “only what gets measured, gets improved” .. These people will insist that measuring our progress, helps us to keep on track , to see if we are working up to our potential. They also argue that Metrics help baseline and allow us to have cer

On the the other hand we have people who will have objection to this very “base lining” as they believe the comparison leads to people focusing on Metrics rather than value …They argue that metrics add overheads and often can be manipulated to paint a picture you want to depict. A heavy metrics framework goes against the idea of simplicity.

Both sides have got merit in their point of view. But fact of matter is Metrics are very much here to stay. Its up to us to set up metrics that are lean and still deliver insights. In this section I am going write a series of articles that describe how to set up such a framework. Some of the topic I am considering are:

  • Why Metrics Need To Be Different For Agile Projects? Do we really need metrics for our agile projects?
  • What Metrics are seen to help agile projects?
  • Some Pointers to keep in mind while defining metrics for your projects

Of Course Metrics can never be defined in isolation – they need to be thought in context with your contracts as well as your own scrum implementation.

Agile tester : Skills Needed

In last post we discussed about how the role of a tester changes in agile world. To cope with the changed world, a tester needs to acquire a few new skills. This post discusses what exactly needs to be done

Whenever the two words agile and tester come in one sentence, the next word to be expected is automation. While automation does form a part of the skill repository of tester, its not the only skill they need to acquire to fit in agile world.The diagram above showcases snapshot what needs to be learnt new by a tester in order to thrive in this new world!

  1. Scrum Framework – This category is self explanatory 🙂 A good tester needs to know the framework he or she is operating in. In most of the agile projects – the framework is scrum. The Tester needs to know the same
  2. Common Agile Practices Agile projects use some practices not mandated in scrum. Knowing these practices helps the tester. Some practices like TDD/BDD or Integrating testing in CICD pipeline in fact keep more focus on testing. Testers need to learn these practices well
  3. Agile mindset More than the events and artifacts, agile projects are set apart by the principles and values which the team adheres to. It is critical that the testers really need to understand how the thought process differs. An agile project will focus on getting user usable deliverable out at every sprint. This singular goal drives all activities including testing. A tester needs to now wear the hat where he helps the developer ship out defect free code – The focus now is not finding maximum defects but on ensuring defect free delivery.
  4. Feedback loop A tester in agile project works with frequently changing requirements. This necessitates a ongoing discussion between tester and business community as well as developer. The tester should continually update the business community on the testing impact the new requirements have! He also needs to work with developer to pass on insights that he has from his testing till date. These can be typical defects , areas which the tester think will have down stream impact etc. Testers have a wealth of knowledge that can enable the developer to deliver a best in class code. A tester should be conscious of his responsibility to have this constant feedback going. On the other hand, a tester needs to actively seek inputs on how his tests are impacting project. Are they helping to avoid defects in later stages? or they are just a time waste? Having this feed back loop going in both directions will help a tester to do his job efficiently
  5. Involvement In Events – I have seen cases where test team is absent from events like planning , daily scrum or the sprint review. Tester is very much a part of the whole team and needs to be an active participant in each event.
  6. Automation Automation is the word one hears often whenever agile is mentioned. A tester needs to learn not only functional automation but also need to automate test triggers.