RSS

Tag Archives: Agile & Devops

Master the Scrum Master skills

29 Jun

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

Advertisement
 
Leave a comment

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

 

Tags: , , , , , ,

Are the 3 daily standup questions actually effective? 

03 May

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: , , , , , , ,

What to do you do when a sprint is cancelled?

20 Apr

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.

During my stint as a Scrum Master, I have experienced multiple cancelled Sprints. I have always tried to use these as learning opportunities.

Though Cancelling the sprint isn’t a frequent situation. In Scrum framework it’s at the discretion of the Product Owner(PO) to cancel the sprint if PO realize that the sprint goal and plan isn’t adding value to the product. In Scrum, only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

“Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.” — The Scrum Guide.

Sprint cancellations, might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense. When a Sprint is cancelled, product backlog is updated with latest priorities any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

A Sprint may be cancelled in the event that an organisation has to adapt to an abrupt situation. In a way it enhances agility. It generally occurs when there is something more valuable or urgent that requires the team’s commitment and focus. A Sprint doesn’t get cancelled if the Scrum Team discovers it cannot meet it. Calling for cancellations often, reveals however that focus and commitment is lacking. Perhaps even the Sprint timebox is too long for the team to timely adapt to the changing conditions in the market. It could even reveal a lack of vision, or that the Product Owner’s vision for a Sprint isn’t respected by his or hers management.

Valid Reasons the PO Might Cancel A Sprint:

  1. A better technical solution is found that makes the current Sprint’s activity throw-away work.
  2. A major technology change occurs.
  3. Fundamental and urgent external changes invalidate the Sprint Goal or the Product Goal
  4. Company’s vision is changed
  5. Product strategy is changed
  6. Company’s business strategy is changed
  7. Market conditions are changed
  8. Customer needs are changed
  9. Product owner realize the value of the identified goal is obsolete
  10. Another poor reason to cancel a Sprint is when a Sprint Goal is already achieved early and there is still time remaining.

When Product Owner cancel Sprint, all the work done until that moment is evaluated and remaining work items are pushed to product backlog for further analysis. The time, efforts and at times work done might be considered waste and Product Owner takes the accountability of any such business impacts. 

When a sprint is cancelled, It is biggest challenge for Scrum Master to handle to situation. When a sprint is cancelled team morale is likely to drop off significantly. Team members are likely to have a negative reaction to the PO and the product. Its where Scrum Master communication skills comes to play.

Most teams are unlikely to be able to start a new sprint immediately. Instead opting to maintain a sprint heartbeat consistent with what they are used to.

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 April 20, 2022 in Technical, Work Place

 

Tags: , , , , ,

Lessons from Devops Experience – 1

25 Oct

WHAT’S DEVOPS?

Wikipedia defines DevOps as:

DevOps (a clipped compound of “development” and “operations”) is a software development method that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.

I like to simplify this definition by saying that DevOps is when you’re not only responsible for developing the application but you’re also responsible for running and supporting the application in your testing and production environments. As opposed to the traditional way of developing where you have the luxury of developing the application then throw it over the wall to the Ops team.

DevOps came as a response to shortcomings of the traditional way of separating development and operations activities. If we look at Damon Edwards’ article What is DevOps?, we will find a description of the traditional way, the way it worked, and what shortcomings it has. Also Mike Loukides, in one of his articles, does a great job in describing the history of the relationship between development and operations, and why we need DevOps in its modern form. I strongly recommend you read both of these articles.

devops-hero-1-87966cfbc9c5713ae047551c7b22985c

KEY COMPONENTS OF DEVOPS

From my experience, there are several key components or principles when implemented then we are set for a successful DevOps experience. Those components and principles are:

  • Automated Delivery Pipeline
  • Configuration Management
  • Regular Integration
  • Automated Monitoring & Health Checks
  • Firefighter Role
  • Infrastructure as Code

When you first look at this list you may say: “We’re already following those principles without doing DevOps”. That might be true but DevOps adds emphasis to the fact that the development team needs to be responsible for defining, understanding and implementing these components. In other words, DevOps encourages developers to dive into aspects of software delivery that Ops would traditionally own. It’s worth mentioning that from a project management point of view, DevOps tasks and stories should be treated the same way we treat those that solve direct business problems like generating a report, or providing a log-in page. That is, DevOps work needs to be well-defined, prioritized, planned, executed and tested just like other user stories or features because the same team of developers will be working on them. Unfortunately, I won’t be able to go into details about this aspect of DevOps management in this post. In the following sections, I will explain a bit what each component is all about.

1. AUTOMATED DELIVERY PIPELINE

First, let’s talk about the “pipeline” part of this terminology. We want to create a process that defines what needs to happen in what order from the moment new code is published to source control to the last step of making that code available to customers in production. That is, the pipeline is an ordered list of well-defined and stable steps that start with pushing new code and ends with that code being in production. The second aspect of an Automated Delivery Pipeline is automation. Once our steps or recipe for delivery is defined, we need to script and automate it.

2. CONFIGURATION MANAGEMENT

When we deploy the same artifact like a web application WAR file to different environments, how do we ensure that the application in Development environment is only using the Development database and that in Production it’s only using the Production database? Or more generally, how do we ensure that the application is only talking to resources specific to the environment in which it’s running? Configuration management is the answer to this problem. There are two approaches to determining what resources an application should use; we can either determine those resources at run time or at deploy time. Both approaches rely on externalizing those concerns from source code into a configuration file. Hence, it’s called configuration management.

3. REGULAR INTEGRATION

Integration in this context is simply to deploy our application to an environment where it will interact with other applications and components in the ecosystem. Agile software development puts strong emphasis on having a feedback cycle in order to validate the solution we’re implementing is indeed solving customer problems and to also detect issues early on. Having a regular schedule of integrating our application is essential in creating a feedback cycle. When our integration cycle is tighter, so would our feedback cycle.

4. AUTOMATED MONITORING & HEALTH CHECKS

Since DevOps involves operational duties, we want to know about problems before they are reported or noticed by users so we can solve them before they impact our users. We need to develop the ability to periodically and automatically check the health of our application and react appropriately when it’s in a bad state in a timely manner.

5. THE FIREFIGHTER ROLE

When the development team takes on the “ops” duties as part of implementing DevOps, it means that the team will have to deal with issues not only related to the business functionality they implemented but also with infrastructure issues, monitoring alerts going off, impaired servers and services, etc. These issues are interruptions to the team’s development activities which can result in reduced velocity and loss of concentration. An approach that I like to employ is to define a Firefighter role and rotate it among the team. All issues that crop up are directed to the Firefighter and she is tasked with resolving the issues.

Dealing with issues that crop up are opportunities to get first-hand experience at how the application actually works in real life and those insights will certainly help the application to evolve and mature.

6. INFRASTRUCTURE AS CODE

This could be the most recognizable part of DevOps but I intentionally list it at the end to emphasize that it’s not the only aspect. Over the years, many good practices came out of developing software for business problems that are widely adopted but many of those practices are not employed to infrastructure as commonly. Treating infrastructure as code does not only mean to write code for infrastructure but it also mean to apply the aforementioned best practices to infrastructure code.

CONCLUSION

All of the previous DevOps components discussed in this post are not to be treated in a “all or nothing” manner. Instead, it’s better to take them one by one. We can pick one to understand, design and implement. Once we are satisfied with its benefits, we can move on to the next one.

This list of components is not intended to be a definitive list but they are what I personally experienced to be most influential. If you have other components or principles you believe should be included, please let me know in the comments section. I’m very interested in hearing from fellow “Dev Operators” about their experience. As a follow-up to this post, I will be publishing a second blog post that will shed more light into the aforementioned components.

By Akrem Saed

 
Leave a comment

Posted by on October 25, 2017 in Technical

 

Tags: , , , ,

 
%d bloggers like this: