RSS

Tag Archives: Agile

Questions a Scrum Master Should Ask Before Joining an Organisation 


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

Having been a Scrum Master for several years and having led 3 large and many small Agile transformations, I have come to appreciate the Scrum Master role more than anything else. Depending on the organizational setup, organizational maturity and Scrum maturity the Scrum Master role can be very challenging. Even if organization is conducive of Scrum, the role is challenging. 

Starting a new role as a Scrum Master for any startup or new organisation can be daunting. Whether you are new to the Scrum Master role or have a wealth of experience, joining a new team means getting up to speed with new people, processes and products. 

A smart scrum master needs to ask appropriate questions before joining a company. Before coming to a decision, the scrum master should clearly evaluate the current situation within the startup.

The scrum master role has been gaining popularity with the widespread adoption of Agile. Startups adopt Scrum at an ever earlier stage and look for professionals to help them out. There are some important questions a scrum master candidate can ask to find the right startup company for their skill set.

In order to get a good idea of how your new Scrum team are operating, I have collated list of questions for you to ask. This list of questions covers all the various topics you are likely to want to know more about, so gather your new Scrum team and ask away!

Here are list of favourite questions for candidates to ask *employers* when interviewing as a Scrum Master:

– What is the biggest challenge Scrum team(s) are currently facing?

– What Is Your Current Software Development Process?

– How much support does the scrum teams have in the organization?

– Why Are You Hiring a Scrum Master and Not a Project Manager?

– How do your team(s) currently feel about working with Scrum?

– How will we validate the success of this team and the product they’re going to build?

– Is the Product Owner empowered to make important decisions?

– What do you think will be this Scrum Master’s biggest challenge?

– What support from a Scrum Master is most important to you?

– Does each dev team currently have a Scrum Master and Product Owner?

– What is the Product Owner’s take on agile product development and planning?

– How would you rate the organization’s Agile or Scrum maturity on a scale of 1-5? Why did you give that score?

– What do you see as the biggest opportunities for your Scrum team(s) to improve?

– How big are your dev teams? How many developers and testers are on your dev teams?

– How many teams does each Scrum Master manage in your organization?

– What Is the Leadership Style of your organisation ?

– How long have the team(s) been working with Scrum?

– Is the team cross-functional enough to deliver a valuable increment?

– What does success look like in this position, and how do you measure it?

– How does the company practice its values and the values of Scrum?

– What’s the attitude of the company’s leadership towards Agile and Scrum

– What’s the last thing your team disagreed on, and how did you resolve that disagreement?

The answers to these questions will give an overview of what to expect upon joining a startup company. A good scrum master should be able to identify the situations where a startup needs a project manager instead of a scrum master and not take on unnecessary responsibilities.

 Do you have any go-to questions you always like to ask?

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
 

Tags: , , , , , ,

Top Books to guide your Scrum Master journey


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me. 

Scrum is the most popular Agile framework. It is simple to adopt, but implementing it with success could prove to be challenging. The only way to overcome the “glitches” that may appear in the process is to understand its fundamentals and discover practical techniques that will help you get past any obstacles.

Anyone who has ever taken on a role of Scrum Master will tell you it is much harder than it looks. The responsibilities are massive, the traps are common and the organisations are unwilling to change. Agile Project Management requires a deep level of skill and understanding. It doesn’t lend itself to a step-by-step manual that you might find in a book.

That is why I have made a selection of top 20 Scrum Master books you should read if you are thinking of becoming a Scrum Master, or even if you are already one. I strongly believe below list of books are a game changer for the pre-game, game and post-game phases of the Scrum methodology.

  1. The Scrum Guide by Ken Schwaber and Jeff Sutherland
  2. Scrum: The Ultimate Beginner’s Guide To Learn And Master Scrum Agile Framework by Hein Smith
  3. The Great ScrumMaster: ScrumMasterWay by Zuzana Šochová
  4. Agile Retrospectives: Making Good Teams Great by Esther Derby
  5. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
  6. Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
  7. Scrum: A Pocket Guide by Gunther Verheyen
  8. Scrum Mastery: From Good To Great Servant-Leadership by Geoff Watts
  9. Learning Agile: Understanding Scrum, XP, Lean, and Kanban by Andrew Stellman & Jennifer Greene
  10. A Scrum Book: The Spirit of the Game by Jeff Sutherland
  11. Fixing Your Scrum by Ryan Ripley and Todd Miller
  12. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins
  13. Agile Software Development with SCRUM, by Ken Schwaber and Mike Beedle.
  14. The Scrum Field Guide: Practical Advice For Your First year by Mitch Lacey
  15. Managing Agile Projects by Sanjiv Augustine.
  16. The Scrum Master’s Path 2 books in 1. A Guide for Servant Leaders Navigating Growth and Change Using SCRUM and the Agile Project Management
  17. Fun In Scrum — A Visual Approach Towards Mastering Scrum Fundamentals by Souvik Seal
  18. Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, Barry Overeem
  19. Agile Estimating and Planning by Mike Cohn
  20. The Elements of Scrum by Chris Sims & Hillary Louise Johnson

You can find few more suggestions here : https://agileforgrowth.com/scrum-master-books/

Learning is a lifelong process. Improving oneself is never a bad thing. Scrum helps us to adapt to changes and dynamics of the market. The same can be said for Scrum Masters. If you don’t work on yourself and seek to improve your knowledge, skills, and experiences, you’ll be stuck.

Hope this list of books help you select the best fit book for your agile and scrum learning. Do remember to comment down below your favourite book on the topic that might help other readers. If you have already read any of the above books do not forget to comment down your review and learnings from the book. 

Any book suggestions, drop it in the comments!

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
Leave a comment

Posted by on July 10, 2022 in Technical, Work Place

 

Tags: , , , , , , ,

Master the Scrum Master skills


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me. 

The real-world challenge most organizations face today with the role of the Scrum Masters is – Developing Scrum Masters that have the required competencies and skills to perform the job well. Most Scrum Masters underperform due to lack of full range skills.

A Scrum Master is the person who champions a project and meets the expectations of the client. Also, he is responsible to build a team of highly innovative members. To define the Scrum Master key skills is somewhat difficult because he performs the role of management as well as the team leader. The major role of the Scrum Master is not telling his team members what they should do but to support and motivate them.

A Scrum Master who is able to help build high performing and innovative Scrum teams, and coach people can be a valuable asset for the organization. Great Scrum Masters will definitely contribute towards improving the business agility and helping organisational system as a whole.

Scrum Masters play a unique role. They are go-betweens that work with both development teams and the Product Owner to ensure the best quality work. While they have an exhaustive list of responsibilities, they are not project managers. Since Scrum teams are, by definition, “self-managed”, Scrum Masters hold a place of leadership, yet have no more authority than any other person on the team. However, it is the Scrum Master’s responsibility to make sure that everyone on the team is following the correct protocol. They are essentially the coach, the referee, and a team member all rolled into one.

From sprint planning to servant leadership, Scrum Masters help Agile developers, product owners and other team members perform at their best. A successful Scrum Master is expected to motivate the team members and increase their potential. For this, Scrum Master requires some skills that he should develop in himself. These are the skills that will help him in the career development. To become a successful Scrum Master and make a transition to the Scrum Master roles effectively, one will need below-mentioned Scrum Master Skills:

Agile and software development knowledge
Learning to build Scrum knowledge
Good at Execution of Scrum
Remove Barriers and Keep the Team on Track
Technical Familiarity
Share Experiences and Encourages Collaboration
Project management tools expertise
Introducing Engineering Practices
Leading and Facilitating Change:
Communication and Good Listening Power
Teaching and Coaching Abilities
Conflict Facilitation
Decision Making & Problem Solving skills
Empathy & Shielding the team when needed
Having Agile Mindset, Growth Mindset

I need your opinion to add 3 top Scrum Master skills that’ll be valuable in 2022.

A Scrum Master who learns, leads and listens, and applies their knowledge of processes and associated tools where needed, is in the right position to make the team run efficiently. These Scrum Master skills support rapid, predictable delivery at every iteration. And that kind of software delivery is ultimately why the team chose Scrum.

Finding the right Scrum Master can make a world of difference in the success of a development project. Both hard and soft skills come into play here. Scrum Masters must be able to strike a healthy balance in order to be a strong leader.

I think irrespective of the technological advancements there will still be a need of skilled Scrum Masters. An effective Scrum Master can help Scrum Team deliver results that are an order of magnitude better than mediocre Scrum Teams. Though the responsibilities of the Scrum Master may adjust with the time.

The conclusion is that the Scrum Master removes impediments, guides the team members in Scrum practices, and protects them against the outer interferences. Thus, the Scrum Master ensures the sustainability of a project by taking appropriate actions. In addition, Scrum Master organizes Scrum events whenever required and plans Scrum implementation. With the above-mentioned scrum master skills, scrum master improves the skills of his team members, which, in turn, increases the productivity.

So, here you have the scrum master skills to become a successful Scrum Master. You don’t have to be a full-stack developer to become a Scrum Master, but you should be creative and quick with a whiteboard marker.

References : https://agileforgrowth.com/blog, https://www.whizlabs.com/blog

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
Leave a comment

Posted by on June 29, 2022 in Technical, Work Place

 

Tags: , , , , , ,

Definition of Ready is when the team says: ‘Ahh, we got it ‘


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

By seeing the title Many Agile Practitioners will already starting bombarding with comments saying that the term “Definition of Ready” isn’t described in the Scrum Guide and same as user stories and the Acceptance Criteria embedded in it. Perhaps, you may consider the Definition of Ready is an integral part of the backlog refinement activity, instead of using the Definition of Ready as a sequential and phase-gate checklist. Backlog refinement is an ongoing process, therefore it’s not restricted to an event but considered an activity.

You would have witnessed multiple situations where despite the team’s best efforts, diligence and meeting quality goals (Definition of Done) the customer is disappointed with the results of your teams work. Do you know the Reason ? It is very likely that the refinement process din’t work as well as it should.

In this Agile world, from time to time, end users will have ideas or concepts for a new feature. The concept will be expressed as one or more feature items, and get added to a product backlog by the product owner. The team, working together, will figure out how to turn this concept, expressed as one or more epics and subsequently refined them into smaller and clearer user stories as a real product feature to be included in the next sprint for implementation.

The product owner could work together with the team to define an artifact called “Definition of Ready (DoR) ” for ensuring that items at the top of the backlog are ready to be moved into a sprint so that the development team can confidently commit and complete them by the end of a sprint.

As you know the quality of PBIs has a direct impact on the productivity of the development team – positively as well as negatively. The DoR is kind of the “DoD for the Product Owner”. It helps the PO to know what to do to a user story before he/she can hand it to the Development Team in the next sprint planning meeting.

“If the development team does not have a clear understanding of the Product Backlog Items (PBI), the development effort and time tend to increase significantly, which in turn causes the Sprint to miss its Sprint Goal or not deliver what stakeholders expect.

The Definition of Ready is an important part of the agreements that a Scrum Team develops at the beginning of the work. Different teams will have different Dentition of Ready, and some require less. i.e., some teams just describe the value to the user, prioritize, and write how to demo. Other estimates and communication are in the sprint planning meeting and etc.  

The concept of  Definition of Ready (DoR)  is not quite as common as the Definition of Done (DoD). The DoR defines when a product backlog item (e.g. user story) has been worked out to the extent that it “may” be included in the sprint. The DoR is intended to ensure that product backlog items are sufficiently prepared for the sprint and that the workflow does not have to be constantly interrupted during development because things are unclear that the team cannot clarify itself.

How is the Definition of Ready used? 

As part of the Product Backlog Refinements, the Scrum Team checks whether the next PBIs are ready. If not, it works out the details.

 The Definition of Ready helps the development team understand what to deliver as a result. Based on this understanding, the development team answers the question of whether they can deliver the result. A Product Backlog is “Ready” when it has enough Product Backlog Items at the top that meet these criteria.

What does a definition of ready look like? The Scrum Guide does not specify anything here. Bill Wake was one of the first to define criteria as a checklist. The INVEST matrix.

  • Independent and immediately actionably – Product backlog items are independent of each other in the sprint so that they can be reprioritized and better estimated. In addition, unnecessary planning effort for their implementation is avoided. All prerequisites are resolved before the start of the sprint. The implementers give the feedback that they can start.
  • Negotiable – PBIs are negotiable so that the details can be discussed and better or cheaper options can be identified.
  • Valuable – PBIs bring added value to the customer so that only requirements that add value are implemented and only what is needed is implemented. Backlog items that are not finished provide no value.
  • Estimable – PBIs are estimable. In this way, it is recognized whether the implementers understand the backlog item professionally and technically.
  • Small – PBIs are the right size to be implemented in one iteration.
  • Testable – PBIs are testable by the customer. You have acceptance criteria.

Definition of Ready for a user story:

definition of ready deals with the user story, wherein the user story is ready to be taken into a sprint. It doesn’t need to be “100 % defined” covering all the acceptance criteria. However, it should be “ready enough” only when the team is confident that they can successfully deliver the user story. In other words, “if something is good to begin”.

  • Well-defined User story 
  • User story acceptance criteria defined
  • User story sized by the delivery team
  • Scrum team accepts user experience artifacts
  • Performance criteria identified
  • The Person who will accept the user story is identified
  • A Team is able to ‘demo’ the user story.

Definition of Ready for a sprint:

  • The Sprint Backlog is prioritized
  • The Spring Backlog contains all defects, User Stories and other work that the team is committing to
  • No hidden work
  • All team members have calculated their capacity for the Sprint
  • Fulltime on project = X hours per day
  • All User Stories meet Definition of Ready

Advantages of Definition of Ready:

  • Measure a backlog item’s “ready” state.
  • Help the team identify when the product owner or another team member becomes overwhelmed.
  • Keep the team accountable to each other.
  • Reduce pressure on the team to commit to estimates before stories are “Ready”.
  • Reduce “requirements churn” in development.
  • Definition of Ready helps in minimizing the Rework on a user story.

Sample Definition of Ready (DoR)

  • PO and Dev Team need to have talked about the story at least once.
  • User Story is clear.
  • User Story is testable.
  • User Story is feasible.
  • User Story defined.
  • User Story Acceptance Criteria defined.
  • User Story dependencies identified.
  • The story must be broken down enough to fit in a single sprint.
  • User Story sized by Development Team.
  • Scrum Team accepts User Experience artifacts.
  • Performance criteria identified, where appropriate.
  • Scalability criteria identified, where appropriate.
  • Security criteria identified, where appropriate.
  • A person who will accept the User Story is identified.
  • Team has a good idea of what it will mean to Demo the User Story.

The Product Owners can use Definition of Ready as a guide when preparing for user stories for upcoming sprints. For a team, it is used as a checklist to make sure that there is an increased chance of success in delivering the completed user story, and that there are enough thoughts involved in building the user story before they start to deliver it. So finally, Definition of Ready brings back the focus to backlog grooming meetings and lookahead planning activities. 

Definition of Ready helps in minimising the Rework on a user story.

References: Scrum Events de, Knowledgehut, It-AGile de, Visual-Paradigm, techagilist & AgileIze

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
Leave a comment

Posted by on May 27, 2022 in Technical

 

Tags: , , , , ,

Retrospective ideas to try with your team


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me. 

Retrospectives are popular in the team-working world of the Lean & Agile community. The purpose of the sprint retrospective is to find areas for improvement. The meeting sets out to identify potential pitfalls and past mistakes while finding ways to avoid them in the future. It’s also an opportunity to reflect on what was successful and therefore should continue.

Retrospectives are used frequently to give teams the opportunity to pause and reflect on how things have been going and then, based on those reflections, identify the improvements they want to make. Conducting Retrospectives frequently and regularly supports a team to continuously improve their performance — but what’s the best way to go about it?

Whether you are an experienced scrum team or brand new to agile retrospectives, switching up your techniques is a great way to ensure your team never has to sit through another boring retrospective. However, with so many retrospective techniques out there to try, picking the one that best fits the unique needs of your team can be hard. 

Here are top retrospective ideas that you can add to your Scrum toolkit.

Liked, learned, lacked, longed for (4 L’s) If you are part of a team that thinks the only failure is not learning, then this is the technique for you. 4L´s is the perfect retro technique for teams at the end of a project or between projects. This technique has the team explore what happened in a current sprint or project but also what they hope will happen in future sprints. For organizations that want to remain agile and consistently evaluate processes and find a long-term solution to a systemic issue, 4Ls is an easy way to collaborate and strive for continuous improvement. 

Sailboat  sailboat retrospective will help any team struggling with staying aligned from sprint to sprint. A ship sailing to the island paradise sets the stage for valuable open discussions at the beginning or middle of a project. Sailboat discussions improve team alignment and provide valuable feedback on project goals, issues, and assets. Get everyone on board! 

Speedcar Speed Car is a simple activity for helping the team identify things that make them move faster, and things that slow them down. This is a common retrospective activity for data gathering. It is an alternative to keep the team engaged while slightly changing the format.

Starfish (smalllarge) This agile technique dives deeper into team habits by examining what to start doing, stop doing, keep doing, do more of, and do less of. Use this technique when your team is in need of a systems overhaul or needs more innovative ideas of workflow. Starfish works best for long-standing teams or projects in the process where teams are a bit more familiar with each other. 

Stop, start, continue Start, Stop, Continue is one of the most popular retrospective techniques, and for good reason. Whether you are using the traditional Scrum sprint model or just starting to implement retrospective Start Stop Continue is a great way to examine the systems and habits of the team, as well as reprioritize team goals. 

Mad, sad, glad When your team is feeling burnt out or emotionally drained, or even if something is just a little off with morale, a Mad, Sad, Glad retrospective can give you the insights you need. Particularly effective in the middle of larger projects this retrospective template gives managers insights into what team members need to remain happy in their workplace. A simple column-based retrospective, this agile technique will have teams focusing less on specific goals and on the emotions of the team. 

Token of appreciation This is a great activity for acknowledgement, increasing the team morale and putting the team on a good mood. A tasty advice is to use a box of chocolates as a token of appreciation. Participants pass the box around and give a chocolate as they appreciate their colleagues. It works both as an opening and as a closing activity for a meeting.

Drop-add-keep-improve  DAKI technique is a way for Scrum team members to think about what they should stop (or drop) doing, what they should start (or add) to their processes, what they should continue doing, and what they should keep.  Continue often refers to processes, and keep frequently refers to tools.  Remember to ask team members to consider  individuals, interactions, processes, tools, and their Definition of Done when participating in the Retrospective. 

One word retrospective The one-word retrospective technique is often considered as a checking exercise, to get the team members ready for the retrospective. But if the team has major problems, then this one-word exercise check-in and the discussion that follows is the retrospective! It is an effective way for the team to discuss what is hampering them, and agree on how to deal with it and get it out of the way. And that is what retrospectives are all about!

KALM (Keep, add, more, less) KALM is a retrospective activity that fosters the conversation about current activities and their perceived value. It helps team members understand each other’s perceived value off such practices. This is a common retrospective activity for data gathering. It is an alternative to keep the team engaged while slightly changing the format.

Team Happiness Radar Organizations around the world are beginning to recognize the importance of mental health and happiness on overall team productivity and lasting success. Running regular Team Happiness Radars can help you recognize the team’s morale and recognize points of improvement. When done in combination with a column technique, this retrospective can help your team create lasting culture changes. 

Lean coffee style Don’t have a specific goal or topic for the day’s retrospective? You need Lean Coffee, another agile favorite, is a basic template to use when you don’t know what to do, but still want an effective retrospective. The Lean Coffee agile retrospective has teams examining the status of the team’s assignments and looking into where issues are developing and what hold-ups are preventing the team’s momentum forward. By discussing common topics of concern the team can create relevant action items for improvement on a range of topics. You never know information can spill out in a Lean Coffee retrospective session.

Below are the list of references and also If you are interested to try more Retrospective ways, please find the below links.

Retrospective Techniques

100+ Sprint Retrospectives Ideas

FunRetrospectives

Remote and Distributed Retrospective Meetings

14 Types of Ideas for Sprint Retrospective Formats

Conclusion

Regardless of whether you follow an agile framework for project management or not, a retrospective meeting acts as a fantastic opportunity to pause and reflect. Your team will gain a comprehensive view of every increment, and quickly identify areas for continuous improvement. The quality of work delivered to the business will be stronger, productivity will increase, and so will the happiness of your team.

The Sprint Retrospective is extremely useful when used correctly.  After every Sprint, the team identifies at least one improvement idea to focus on during the next Sprint.  Remember, even minor improvements can result in an astonishing amount of change over time – so don’t neglect this valuable process!

Need more retrospective ideas? Keep following my posts on Agile.

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
 

Tags: , , , , , , ,

Are the 3 daily standup questions actually effective? 


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

I have been an Agile coach for more than nine years and have worked in various Indian, American & European companies that develop software locally and internationally using Scrum. The clients of these companies have adopted Scrum and participate in the Daily Scrum meeting, assuming the role of Product Owner.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It’s not an opportunity to get a report on where the team is up to. It’s not an opportunity to ensure everyone is ‘busy’. Unfortunately, the three questions just tend to reinforce this perspective.

  1. What did you do yesterday?
  2. What will you do today?
  3. What (if anything) is blocking your progress?

The purpose of the 3 daily scrum questions is relatively simple and obvious. These questions are asked routinely first thing in the morning, which allows teams to assess: (1) how they performed in the last 24 hours and (2) what the next 24 hours look like.

This article tells the story of our experience implementing a shift in approach during the Daily Scrum meeting. We went from a typical approach centered on each individual to one centered on each story of the Sprint Backlog.

The 2020 version of the Scrum Guide dropped the classic “three questions” of the Daily Scrum. Yet many teams stick with the practice, even when it doesn’t produce the collaboration that is the hallmark of a valuable Daily Scrum. When a Scrum Team I worked with said that their Daily Scrum was lackluster and unproductive, I challenged them to design a better one. The new pattern we created shifted the focus from individual action to team collaboration toward the Sprint Goal.

Smarter questions for the Daily Scrum

Scrum isn’t prescriptive about the way Developers run their Daily Scrum. Importantly, going ‘around the room’ and ‘standing up’ isn’t required. Some useful questions to raise at the Daily Scrum include:

Questions about scope

  • Do we need to change some of the work we have in the Sprint so we achieve the Sprint Goal?
  • Do we need to change some of the tasks we decided need doing?
  • Do some of the backlog items we chose need to be put aside because we now know they don’t help us achieve the Sprint Goal?
  • Do we need to negotiate scope with the Product Owner to help us achieve the Sprint Goal?

Questions about collaboration

  • Does anyone need their work peer reviewed yet?
  • Does anyone need help today?
  • What pairing activities will we do today?
  • Whose turn is it to pair with the new team member?

Questions about transparency

  • Have we updated the board to show our actual progress?
  • Is the Sprint Backlog up to date?
  • Is the status of work up to date?

Questions about metrics

  • How are we tracking toward the Sprint Goal? Are we where we thought we’d be?
  • What do our burndown metrics say about our progress?
  • What does our cycle time metrics say about whether we’ll complete the work by the end of the Sprint?
  • Questions about Done
  • What work is in-progress that we can work on today and get to Done?

Questions about learning 

  • Did anyone learn anything yesterday that means our work for today needs to change?

If the traditional “three questions” Daily Scrum doesn’t provide value for your team, try something new. Create a collaborative discussion focused on making each day a valuable step toward the Sprint Goal.

If you came across similar situations , please share your experience in the comments section.

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
Leave a comment

Posted by on May 3, 2022 in Technical

 

Tags: , , , , , , ,

Kanban is awesome but it has to be managed well


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

Delivering work in a quick and efficient way could be a challenge. The Kanban Method suggests an approach of managing the flow of work with an emphasis on continuous improvement without overburdening the development team that focuses on productivity and efficiency.

Kanban was initially invented as a way of managing Just in Time (JIT) manufacturing processes. The next chapter in Kanban’s history introduced new principles and practices to make it more efficient for knowledge workers. It is a method designed to help you optimize workflow and use your team’s full capacity. In this article, we will discuss what is the Kanban Method, how to implement it, and what are the most important Kanban analytics charts.

By using Kanban, you can evenly distribute your most important tasks and eliminate any wasteful activity or useless information. The method can help you solve your productivity problems using visual cues that are easy to understand by your team. The Kanban Method is one of the simplest to implement, with no immediate structural changes and prescribed ceremonies. As long as you continuously analyze and manage your flow of work, Kanban can enable exceptional results.

No matter which agile framework is used – Scrum, LeSS or SAFe or other the Kanban Board always helps to make the work progress and impediments of teams visible to everyone and so supports the core agile values – transparency, commitment to do the right things and courage to achieve common goals.

8 Benefits of Using Kanban for Software Development - Kanban Zone Blog

Kanban Principles

The Kanban method is a pull system – this means that work is pulled into the system when the team has capacity for it, rather than tasks being assigned from the top. Kanban can be used to improve processes and workflow efficiency without making any changes to your team structure.

Prior to applying the Kanban Method within your business, it is important to first understand and adopt its fundamental principles:

  1. Start with what you are doing now – Kanban doesn’t require a particular setup and can be applied directly to your current workflow. This makes it easy to implement since there is no need to change your existing processes. The benefits of Kanban are gradual, and any process improvement is adopted over time.
  2. Agree to pursue incremental, evolutionary change – Sweeping changes can unsettle teams, disrupt flow and damage performance. Kanban is designed to incur minimal resistance by encouraging continuous, incremental and evolutionary changes.
  3. Respect the current process, roles, and responsibilities – There should be no organizational changes at the outset. Kanban recognizes that existing processes, roles, and responsibilities may have value and are worth preserving. Instead, Kanban encourages incremental change to avoid emotional resistance.
  4. Encourage acts of leadership at all levels – Kanban promotes leadership and decision making between all members. If the lowest-ranked team member has a bright idea, it should be acknowledged and embraced. Everyone should be fostering a mindset of continuous improvement (Kaizen) – in order for your workers to reach optimal performance.

The structure of a Kanban board

A Kanban board is one of the most practical tools that you can use to manage your projects in a simple and clear way. Kanban can help you visualize and maintain your tasks and workflows, signaling potential bottlenecks for each project or workflow stage. This is why they are used by several agile in-office and remote teams across the world to manage tasks with flexibility.

There are many Kanban boards online that you can use to balance your resource demands. You might already know about other tools such as Trello or Kanban Tool, but you must be aware that Kanban boards are most effective when they are part of a more advanced project management software. Such platforms can help you track time and maintain real-time collaboration with your team.

With Kanban, you can limit the number of tasks that are allowed for each stage to avoid overloading your employees or leaving them with no tasks. Likewise, Work in Progress (WIP) limits can be set for a more effective workload distribution among your team members. This guarantees that each task will be completed before the team moves on to the next one and that the focus on the “In progress” tasks is never lost. You can also turn the completion of a task into a priority to get a better idea about your overall workflow.

A basic Kanban board, be they physical or virtual, are created using these three main elements:

Kanban for software development

Kanban Board: 10 basic rules how to use it in an effective way

Kanban boards were first used in the late 1940s at Toyota’s factories to balance supplies with production. Workers could share the inventory levels of materials through a card named “Kanban” (meaning “signboard” in Japanese). Each card had the requirements for the necessary materials written on it and would then be moved to the warehouse were instructions were carried out. This helped teams communicate easily across the entire manufacturing process.

Now Kanban is used to visualize and speed up your project’s workflow, improve team collaboration, and identify possible obstacles. 

Even though the look, structure and usability of the Kanban Board is well known the rules how to apply it effectively in order to unfold its full potential is something left for teams to find out.

Rule #1: Keep it simple

If you use the Kanban Board for the first time start with the basic structure with columns To Do, Doing, Done which everyone understands and is able to intuitively assign tasks to. Once you get acquainted with this basic structure you may thing of extending it by additional categories given that these categories add a real value – help the team to remove impediments faster and perform tasks more effectively.
Use simple plain language without abbreviations and “team jargon“ when you define tasks. This will make the Kanban Board to a universal tool for reports and communication across across teams and hierarchy levels.

Rule #2: Common structure and level of details across all teams

Use the same Kanban Board structure (column definition) agreed at the rule #1 across all teams.If a team suggests to introduce a new category (column) align with all teams if this category makes sense for everyone. If it is accepted as a common value-adding category adjust the common Kanban Board structure accordingly. Otherwise commonly refrain from it.

Rule #3: Manage flow – By observing and analyzing flow efficiency, you can identify any problem areas. The main goal of implementing Kanban is to create a smooth workflow by improving the lead times and avoiding delays. You should always strive to make your process more efficient.

Rule #4: Agree on a time box

Even though the original Kanban methodology does not apply time-boxing to the work visualization but rather see is as a continuous flow, we recommend to do so. A common agreement on a certain time box with duration from one to four weeks – applied to the categories To-Do, Doing, Done and valid for all teams helps to achieve the same level of details in task definition across multiple teams. „Speaking the same language“ simplifies integration and synchronizes the deliverables of teams. Keep the time box duration fixed unless all agree to change it for an important value-driven reason.

Rule #5: Revise it regularly

Revise the Kanban Bard on a regular basis: Plan the „To-Do“ list for the next time at the end of the current time box by moving the parked tasks from the „Backlog“ column and not-completed tasks of the current time box from the „Doing“ column to the „To-Do“ column. Always keep the status of all tasks up to date at so that the Kanban Board can serve as a tool of transparency and work synchronization. Move a planed task from the „To-Do“ column to the „Doing“ column when you started the task and from the column „Doing“ to the „Done“ column when you completed the task on a daily basis.
Keeping the Kanban Board up to date is not a responsibility of a single person such as Scrum Master, Team Lead or similar. It is a responsibility of each team member who execute tasks.

Rule #6: Improve collaboratively – Kanban requires constant evaluation, analysis, and improvement. When teams have a shared understanding of the process, they are more likely to reach a consensus should any problems arise. The Kanban Method suggests that various models of scientific approach are used to implement continuous, incremental, and evolutionary changes.

Rule #7: Accessible to everyone

The Kanban Board should be placed so that everyone who is involved in task execution, planning and revision as well as all stakeholders can easily see it anytime they like. This helps to avoid status requests from stakeholder and saves the team’s time for productive work.

When you work with an analog Kanban Board it should be placed in a room where everyone has access to and the most people have the shortest way to reach it. A digital Kanban Board should be stored in a shared folder (e.g. Sharepoint) with the write access for the team working and a read access for stakeholders.

Rule #8: Purpose over tools

When you use the Kanban Board for the first time, start with an analog board on a wall. The reason for this lies in the rule of simplicity. All tasks are posted as post-its on the wall. This gives you a good overview and helps to draw your attention to relevant tasks. There are several good tools on the market such as Jira Agile BoardTrello etc. which not only provide basic Kanban Board features but also allow to track the progress with fancy customizable reports, e.g. Burn-Down charts, Average task duration, Number of tasks in status „Doing“ and „Done“ by team assignment, Number of tests planed vs. completed within a time box.

Rule #9: single south of truth

Avoid creating several Kanban Boards when you can achieve your goal with just one. Duplicating Boards and tasks leads to either extra effort for the team of keeping the boards in sync or to a disconnection of the tasks between two boards. The impact of the disconnection may be huge – from misinformation and misunderstandings to confusions and delays.

Rule #10: Visualize workflow – The first and most important task is to understand the current flow of work – what is the sequence of steps to execute in order to move an item from request to a deliverable product. This is done using a Kanban board with cards and columns: each column represents a step in your workflow, and each card represents a work item. Every item moves through the flow from start to end. By observing this process, you can easily track progress and identify bottlenecks in real-time.

Rule #11: team achievement over personnel achievement

Do not assign and track a task to a person, rather assign it to a team. The team should be able to complete the task independently from other teams or managers.

Doing it on a team level encourages the team spirit and mutual support and establishes psychological security which is inevitable for the success of a project.

Rule #12: Make process policies explicit – The process should be clearly defined, published, and confirmed for everyone in the team: people won’t feel motivated to be part of something unless they think it will be useful. When everyone is aware of the explicit policies, each person can suggest improvements that will improve your performance.

Rule #13: continuous improvement

Brainstorm with all teams at least once in a quarter what can be improved about your Kanban board and implement improvement measures which are value-adding for the team.

Rule #14: Use feedback loops – In order for the positive change to occur, regular meetings are necessary to provide essential feedback to the entire team. The frequency of these meetings varies, but the idea is that they are regular, at a fixed time, and that they get straight to the point.

Rule #15: make these rules be known and agreed by everyone

A great rule which nobody knows, the reason for which nobody understands makes it just а deadweight. A rule which is known and understood by everyone moves mountains.

Assure that everyone who starts working with a Kanban Board understands the commonly agreed rules and is given a possibility to contribute to their further improvement.

References: Agilon GmbH, Nave, Paymo

Please feel free to share your story and any lessons you learned, you experienced, you came across in your life in the comments below. If you enjoyed this, or any other other posts, I’d be honoured  if you’d share it with your family, friends and followers!

If you wish to follow my journey outside of my writing, you can find me on Facebook (https://www.facebook.com/MunnaPrawin) Instagram(MunnaPrawin) and Twitter(@munnaprawin1)

 
Leave a comment

Posted by on June 21, 2021 in Technical

 

Tags: , , , , , ,

Scrum Vs Kanban


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

Article by AXA XL Team…

Which framework works best: Kanban or Scrum? If you are on the verge of a brand new project, I bet this question has posed quite the challenge to your mind. Today Kanban and Scrum have grown in popularity and have taken the place of the previously popular waterfall method.

Agile –  Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Cross-functional teams work on iterations of a product over a period of time, and this work is organized into a backlog that is prioritized based on business or customer value. The goal of each iteration is to produce a working product.

Scrum – The approach followed here is breaking down a complex task into simpler smaller manageable pieces which are easy to collaborate upon by the respective owners of the scrum.

Kanban – It is a Continuous improvement, flexible process. Kanban helps visualize your work, limit work-in-progress(WIP) and quickly move work from “Doing” to “Done.” It is a framework which utilizes visualization technique, limiting the number of tasks to be taken in “Work in Progress” column.

Scrum Vs Kanban

Kanban and Scrum are both iterative Agile development models, the goal is to get the most important tasks fully done (including testing) as soon as possible. The product should be potentially shippable at the end of the iteration. The difference is with Scrum the end is a set date, with Kanban it could be anytime the features that need releasing are done. In Scrum you plan a fixed period of time and with Kanban you plan just in time.

ks1.jpg

Roles –

  • Scrum is dependent on the scrum owners and is worked upon by them respectively. Scrum has three clearly defined roles.
    1. The product owner advocates for the customer, manages the product backlog, and helps prioritize the work done by the development team.
    2. The scrum master helps the team stay grounded in the scrum principles.
    3. The scrum team chooses the work to be done, delivers increments, and demonstrates collective accountability
  • Kanban is independent of cross-functional team members and parallel roles. The whole team owns the kanban board. Some teams enlist an agile coach but, unlike scrum, there is no single “kanban master” who keeps everything running smoothly. It’s the collective responsibility of the entire team to collaborate on and deliver the tasks on the board.

Release cycle –

  • Scrum makes use of sprints whose duration varies from one week to two weeks. The user stories are then taken up for development, testing and bug fixes. Nowadays, it’s common to have ad-hoc releases in scrum, but it’s long been a best practice to release at the end of each sprint. Teams set an objective for each sprint, the sprint goal, and either approves it for release in the sprint review meeting, or don’t
  • Kanban does not follow any cycle and the process is continuous in nature. In kanban, updates are released whenever they are ready, without a regular schedule or predetermined due dates. In theory, kanban does not prescribe a fixed time to deliver a task. If the task gets completed earlier (or later), it can be released as needed without having to wait for a release milestone like sprint review.

Tracking parameters –

  • Scrum makes use of velocity in planning upcoming sprints taking into account the complexity and number of user stories completed in the previous sprint.
  • Kanban ensures limiting of user stories in “Work in Progress” column to avoid bottlenecks. It tracks the time taken to finish a task from the starting to the end.

The scope of improvement –

  • Scrum does not encourage changes in ongoing sprints.
  • Kanban is open to any changes before the completion of the project. It is flexible in nature.

Fit factor –

  • Scrum is suitable for projects with clearly defined user stories. Acknowledgement on the same by the client for timely completion of the project makes it a fit.
  • Kanban being flexible in nature allows variations in priorities on the basis of the current scenario.

Pick process –

  • Scrum picks the entire batch of user stories from the product backlog for development.
  • Kanban follows the maximum number of tasks allowed in the columns to maintain the sanity of the framework and to avoid bottlenecks.

Delivery –

  • Scrum follows delivery based on sprint planning and prioritize based on the specifications given by the client.
  • Kanban follows the continuous delivery model based on business needs.

Key metrics

  • Scrum – Velocity i.e. the number of story points completed in a sprint—is the central metric for scrum teams. It guides future sprint commitments, or how much work the scrum team takes on in future sprints. If the team completes an average of 35 story points per sprint (Velocity = 35), it won’t agree to a sprint backlog that contains 45 points.
  • Kanban – Lead time and cycle time are important metrics for kanban teams. The deal with the average amount of time that it takes for a task to move from start to finish. Improving cycle times indicates the success of kanban teams.

The above points are easy to remember if you are able to visualize working on them. Ideally where the scrum follows a rather predefined set of principles. Kanban is backed up by the principle of flexibility. It allows you to track tasks that are of utmost importance for delivery.

What Is Kanban? ks3

In order to simplify the manufacturing process and increase efficiency, in the 1940s Toyota implemented just-in-time manufacturing—effectively, making only what is needed, only when it is needed, and only in the amount that is needed.

Kanban is great for teams that have lots of incoming requests that vary in priority and size. Whereas scrum processes require high control over what is in scope, kanban let’s you go with the flow. Let’s take a look at the same five considerations to help you decide. What makes Kanban interesting is this aspect of it – that you could be continuously developing, integrating, testing and releasing at a cadence that you feel comfortable with – and so the whole concept of Continuous Delivery becomes much more ‘natural’ with Kanban.

How Does Kanban Work?

The only essential materials for kanban are a marker, sticky notes, and a board. Create “cards” from the sticky notes representing work items that have to go through several phases, from start to finish. Then draw columns on the board for each phase the cards need to go through, with a number at the top of each column that indicates the maximum number of cards (i.e., work in progress) that can be in that phase at a time. This number probably will and should change as your team improves its ability to gauge and reduce bottlenecks. The columns could simply be labeled “to do,” “doing,” “waiting,” and “done,” or they can be more process-specific, such as in the examples below.

Another helpful thing many teams do is dividing the columns in two, with one lane for “doing” and one for “done,” as you can see in the software development kanban example above. This way, it is clear to whoever is in charge of the following column to know when they can pull another card and begin working on it.

ks 2

The beauty of this system is that it helps you detect where bottlenecks are. The work-in-progress limit stimulates conversations about process problems. In the examples above, you can see some columns are at capacity and some are not, but none has more cards than prescribed.

 

Please feel free to share your story and any lessons you learned, you experienced, you came across in your life in the comments below.

 

 

 

 

 
1 Comment

Posted by on March 22, 2019 in Technical

 

Tags: , , ,

Steps to Introduce Test Automation


Today, software testing is an integral part of the development process. To reduce the time spent on testing, many companies opt for test automation. However, automation capabilities move beyond speed increase and include test coverage enhancement and overall QA costs optimization in the long run.

Assume, You’ve just started a brand new role at a company and the very first task you’ve got in front of you, is to implement test automation.

Now, this company has never done any kind of test automation and right now is relying on a hodgepodge of methods to test and measure quality.

Where do you start and how do you begin such a momentous task? I’m glad you asked.

We’re going to be talking about the general, fundamental concepts surrounding test automation – not specific tools or frameworks you need to use because those will vary based on what your organizations unique needs.

shutterstock_727680178

Analyzing applications to determine which can be automated

If your organization is working on 3 applications, it is not necessary that each should be automated. We have to see the various factors while selecting any application to automate.

The application which should be automated must have these factors:

  1. The application should not be in the early stages of its development. (The application should have all or some modules which are stable and tested by manual testers)
  2. The UI of the application must be stable. (The UI must not change frequently)
  3. The manual test cases of this application should be in written form.
  4. Basic application flow should have been already tested and working

The main goal of automation is to make sure that if the application is bug-free in one build, it should remain bug-free in the next build. The manual tester should not waste their time in finding regression issues, these issues should be identified in automation.

Educate on myths & misconceptions

Educating management, and other groups, about these particular myths and misconceptions surrounding test automation, gives you a shot at success. It provides the understanding and opens lines of communication that will benefit you and your work.

The myths & misconceptions include things such as:

  • You can automate 100% of your tests.
  • Automation allows Management to reduce test staff.
  • One tool is all you need.
  • Automation will speed up the testing process.
  • Anyone (untrained/unskilled) can do automation.
  • Open-source tools are “free.”
  • “Codeless” and “Scriptless” tools can do all the work.
  • Automation can be created quickly.
  • Only hire a Software Design/Development Engineer in Test (SDET).
  • Automation provides an immediate return on investment (ROI).

Determine the scope

Any process starts with the definition. Therefore, before implementing test automation, you should determine the automation scope. When starting tests development, a QA engineer should first define the order according to the tests’ priority rate.

Prepare to automate

Having quite profound experience in test automation, I can say the following: automated tests should cover the most stable part of the functionality and the one that is tested for about 3-4 times per week.

As a rule, smoke tests (or other regression tests) are chosen for that very purpose.

Select tools for automation

As soon as the scope is defined, a QA engineer should select test automation tools. The tested interfaces define the package of applied tools. Different types of interfaces presuppose different tools’ range.

There is no any one-size-fits-all solution. The choice of a test automation tool will depend on the technology the software is built on. For example, QTP does not support Informatica. That means the tool cannot be used for the software. We prefer the most reliable and proven solutions: Selenium WebDriver, Coded UI, Ranorex, TestStack.White, Appium, Xamarin, and many more.

Having decided upon the tools, testers get to framework implementation.

Training the Team

After tool selection and resource hiring, the next step is logically the training of the resources. If manual testers are converted into automation engineers, they have to be trained on automation terminologies and concepts. If automation architect is hired from outside, he must get knowledge about the product to test, the manual testing process and what management is expecting.

Give resources some time to try different things until they finally come up with a winning automation strategy. Train them on the tools which organization is already using bug tracking software and requirements management software.

Good training and strong communication between manual testers, developers and automation team is really necessary.

Develop the framework

The framework is the basis for further automated tests’ development. It provides an opportunity to optimize test development efforts by re-using the code. You can utilize any of the ready-to-use frameworks presented on the market, like the Robot framework for Selenium.

The usefulness of frameworks is hard to underestimate. Thanks to frameworks, it’s possible to maintain consistency of testing and improve re-usability. You can also count on minimizing code usage and improving the structure of tests, which is a perfect scenario for long-term projects.

Configure the environment

All the tests run in the environment, which is to be well-configured. Upon this step, you should create and support the environment to successfully run automated tests and store the results.

Test automation will require test data, which means you are to prepare the set of files and test accounts beforehand. Otherwise, you tackle risks that may damage the process and provide you with irrelevant test results.

Test automation process

Developing an Execution Plan

The execution plan includes selecting which environments the scripts will be executed. The environment includes OS, Browser and different hardware configurations.

For example, if the test case demands that it should check the website in 3 browsers, namely, Chrome, Firefox and IE, then the automation team will write the script in such a manner that it will be able to execute in each browser.

Start to automate

Eventually, when all the preliminary preparations are done, testers can get down to automated test development. A regular process of providing new automated tests includes the following points:

  1. Selection of the manual test case according to the stated priorities
  2. Code writing for the automated test
  3. Adding the automated test to the debug test execution
  4. Adding the automated test to the test execution for newly created builds.

Writing Scripts

When the framework is designed, the execution plan is known and resources are trained on the new tool, now it’s the right time to start writing scripts.

Scripts should be written in an organized manner with proper naming convention. The source code should be maintained in a source control to avoid code loss. Version control and history should be maintained. Test automation is just like software development. All best programming practices should be taken care while writing the scripts.

Reporting

The reporting feature is usually provided by the tool. But we can create custom reporting mechanisms like auto-emailing the results to management.

We can create reports at the end of each execution in the form of charts and tables if management needs it. The management should always be informed about the test case coverage, that means which manual test cases are covered in automation and which of them are remaining.

Maintenance of Scripts

If best programming practices are followed and framework is good, then maintenance will not be a problem.

Maintenance usually occurs when there is a change request an application. The scripts should immediately be updated to cope with that change to ensure flawless execution.

Monitoring

When the tests are launched, they should be monitored. You cannot let them go along without tracking the process. While monitoring the automated test, remember to take into consideration the following aspects:

  1. Automated test coverage, cost per test
  2. Useful vs. irrelevant results after test execution
  3. Cost per test
  4. The scope of support in comparison with the number of executed tests
  5. Economic effect (ROI, return on investment).

Tracking the process, keep in mind, that test automation is much more than computers launching test programs. It is also delivering information about quality.

Ultimately, mastering automation can significantly increase your business value. Automation includes many factors that need to be understood and addressed before the start of the process. Follow the main points to avoid the risks and get your benefits.

The Final Word:

Following the steps discussed above will help you in successfully implementing automation testing seamlessly in your organization. Once the process is in place, you need to follow the best practices. Whenever there is a change/update in the application, the scripts should be checked and updated as required. Have you tried introducing automation to your testing process? Share your experience in the comments below.
 
Leave a comment

Posted by on February 21, 2019 in Technical

 

Tags: , , , ,

 
%d bloggers like this: