Category Archives: agile

Posted on

Agile is NOT a Methodology

As we all know, Agile has become a popular approach to software development and product development in recent years, but it’s often misunderstood.

Many people think of it as a methodology, and many call it a framework.

It is neither of it!

Agile is not a methodology.

Agile is not a framework.

Agile is Mindset!

The Agile movement, a movement which has been gaining increasing traction in today’s world, has its roots back in Feb 2001, with the weekend skip trip in Utah

The Agile Manifesto was born out of an incredible weekend-long journey, where a group of passionate individuals from different backgrounds came together, united by a common purpose.

As a result of their efforts, the Agile Manifesto was created, a set of values that we as agile practitioners strive to uphold and live by. These values are essential for a success of agile and form the bedrock of our approach to software development. We recognize that the Agile Manifesto is an ever-evolving document, providing the foundation for a continuous process of improvement and adaptation in our industry.

Agile Manifesto

Furthermore, this manifesto is backed by a set of 12 core principles that provide a strong foundation for its aims and objectives. These principles serve as a guideline for the manifesto, outlining the core values and principles that are essential for its successful implementation.

12 Agile Principles

The 12 principles provide a comprehensive set of guidelines that focus on the best interests of all involved, and ensure that the manifesto is implemented in a manner that is equitable and fair.

Remember, there are 4 core statements that define the agile values, and these are supported by 12 underlying principles.

These 4 value statements (agile manifesto) and 12 principles collectively form what I call Agile mindset!

It is a mindset that strives to embrace change and improvement, a way of living that encourages collaboration and open communication, and a way of building and delivering products in an incremental and iterative fashion, constantly striving for excellence and progress.

This mindset is based on the principles of agility, and by following these principles, teams and organizations can achieve remarkable success.

And, then, there are many frameworks that strive to live by these values and principles. Scrum and Kanban are two examples of such frameworks, that emphasize agility, collaboration, and iterative development, and have become widely adopted in the software development industry.

Agile is Aloha

Remember, Agile is a mindset!

It is not a methodology.

It is not a framework.

Agile is aloha!

Agile is a way of living!

It is a way of building and delivering products, incrementally and iteratively.

It is a mindset!

Posted on

Spare Capacity in your in-flight Sprint..

Step into the Scenario

Scrum Team

Scrum Team

You have a ‘young’ team that is just into it’s second sprint. You are doing two-week sprints, and team just finished first week of current sprint. Three of the team members come up to you, the Scrum Master, and tell you that they have spare capacity. They completed their part of the work on some of the stories and now wondering what to do. 

You obviously don’t want them to be seating idle. What should be your approach? 

Explore 5

In this scenario, it is tempting to just tell them to ‘Pull’ a new story from Product Backlog. But, hold your horses here! 

I would recommend that you (as a team) explore these 5 different avenues.

What to do when you have spare capacity in your in-flight Sprint?

What to do when you have spare capacity in your in-flight Sprint?

Let’s walk through each avenue one by one. 

Swarm

First preference should be on ‘Swarming’. Ask them to help other team member(s) in closing story. Remember, we get points for closing stories, and not for opening more. As I like to say..
[bctt tweet=”Stop Starting, and Start Finishing” username=”beyondCSM”]

Pairing

You could go and pair with another team member. May be pick up new skills, may be learn new approach, may be provide another set of eyes to your colleague as s/he works on driving a story to completion.

If you are short sighted, you will look at pairing as a waste of time (as two people are working on one thing). However, if you are long, you will realize that it is an investment into the team.

Pairing helps in knowledgesharing, spreading the ‘wealth’, and gelling the team as one unit. In some shape, it also improves the quality of the outcome. 

Pay off your Debt!

Got any technical debt, that has been identified earlier and put aside with a reason that ‘we don’t have time’? This would be good avenue to spend that spare capacity on. Work on paying off that debt! 

AIR it out! 

How about looking into some..

  • Automation
  • Improvement
  • Refactoring

Even a small amount of automation would help the team in the long run. 

Pull

I would suggest pulling a new story from your Product Backlog should be the last avenue that you explore. And, if you go this route, make sure to ask and confirm with your product owner. You want to pull the next highest priority story. 

Above all, pulling new story should be an exception, not a norm.

Indicators.. 

We talked about these five avenues to explore. Now, let’s look at the root cause as to why we have this spare capacity in the first place. 

In essence, getting this spare capacity in the middle of in-flight sprint is an indicator on one of these factors at play. 

  • Team is being conservative when committing the stories to sprint [at sprint planning event.] So, you need to facilitate that conversation at the new sprint planning. 
  • Team over estimating the points assigned to the story. Being overcauseous and erring on higher side, the team is assigning more points to the story than it actually needs. 

Remember, this is a new, young team. I would not blame the team for any of these, as this is just part of the learning process. They will eventually figure this out, you are there just help and speed up that process.

[bctt tweet=”What to do when your team has spare capacity in your #Sprint ?  pic.twitter.com/ZOREu5V7Zf” username=”beyondCSM”]

 

Posted on

Advance your skills.. Advance your Career

20 Tips to make you an Awesome Scrum Master

Jack Nicholson once said

The minute that you are not learning, I believe you are dead

The question for you is, Are you still ‘alive’? Are you ok being one among the thousands, or are you the one who wants to stand out from the crowd?

STOP here if …

STOP here if you are okay with being a mediocre Scrum Master.

READ ON if ..

If you are someone who is looking to sharpen his/her saw, if you are someone who has embraced the culture and mentality of continuous improvement and continuous learning, if you are some one who is looking to advance his/her skills than READ ON.

Join me here every week as I share some advanced skills, tools, and techniques that are guaranteed to make you a better Scrum Master. Join me here every week to advance your skills that will help you advance your career.

With that said, let’s start reviewing the Tips.

[WPSM_AC id=2474]

Like these tips? We request you to share them with your friends and colleagues. 

[bctt tweet=”20 Tips to make you an Awesome #scrumMaster http://www.nimeshsoni.com/20-tips-advanced-scrum-master-skills ” username=”beyondCSM”]

Got your own tips that you want to share with the community? Send us an email.

 

Posted on

7Cs of Sprint Planning

How do you do Sprint Planning? Are you struggling to keep the team interested in coming to Sprint Planning, every sprint?

Show them the VALUE! Use my 7Cs of sprint planning to keep your sprint planning on track and make it the most productive meeting for the team. 

7Cs of Sprint Planning

7Cs of Sprint Planning

Let me explain each of these Cs in detail to help you make your Sprint Planning the most productive one. 

Close

CLOSE refers to Closing your current sprint 🙂 You need to make conscious decisions on any of the ‘left over’ stories, the ones that the team did not complete during this sprint and then close the sprint in preparation for the next, upcoming sprint

Confirm

Confirm, as a Team, with the Product Owner (PO) that the Stories that are at the ‘top’ of the Product Backlog are still his/her highest priorities and that the team got them READY through previous refinement sessions.

Confirm that those stories are READY and meet the Definition of Ready (DoR) criteria. You can read more on DoR and DoD here http://www.nimeshsoni.com/art-getting-done-less/

Capacity

How many Stories can you load into the Sprint backlog? To answer this question, you will need to know the Velocity of the team as well as the capacity for this Sprint, as a Team.

When I say Capacity, I am not referring to how many hours. Instead, I am referring to the Day offs, Holidays, Planned Vacations, etc. Is any one taking any time off during this sprint? What about holidays and company-wide events that will take time away from this sprint and impact your capacity.

To help you answer these questions easily, I strongly recommend you set up a Team Calendar where each team member keeps his/her time-off requests. This team calendar becomes your go-to artifact to answer the Capacity questions.

Remember, the Capacity will also impact team’s Velocity.

Consensus

Bases on the discussion on Capacity, and using Velocity as a guide line, team should be pulling top priority items from Product Backlog into the Sprint Backlog. How many stories to load into the sprint will depend on the capacity and velocity. 

As a team, you need to come to a consensus as to how many stories / story points is feasible in this sprint. 

Commit

Once team has a consensus on the number of stories, story points and what stories to load, the team Commits to them. Team promises to do everything in their power to drive these stories to completion through this sprint. 

This is where you can mark the completion of your Sprint Planning event. The team can go back to their work environment and actually start working on them. 

The next two Cs are more for the Scrum Master than the entire team. 

Communicate

Now that you have completed an awesome and highly productive Sprint Planning event, the Scrum Master should communicate to the stakeholders. Send out a communication as to what is the scope for this sprint, what stories were committed, and what feature/functionality the team is attempting to complete through this sprint. 

This will keep the stakeholders in the loop, and they will know what to expect at the Sprint Review.

Remember one of the pillars of Scrum!? The Transparency!

Collect

I am not a big fan on Task writing. But, if team decided to capture Tasks under the stories, then we need to collect them quickly. I generally advise Scrum Master and team to set a deadline here. For example, by end of the day, enter any tasks that you may want to capture. 

Stand out from the Crowd!

Don’t settle being a mediocre Scrum Master. Stand out from the crowd with this advanced certification.

Click here to Enroll in A-CSM certification workshop Now

There you have it folks! Use these 7Cs as your guiding posts as you go through your next Sprint Planning. Do let me know how it goes 🙂

Posted on

Start with WHY..

#makeTheShift: Start with WHY, and End in their (your customers) Hearts!

Simon says…

People don’t buy what you do; they buy why you do it. And what you do simply proves what you believe.

In his book Start with Why: How Great Leaders Inspire Everyone to Take Action Simon Sinek talks about what separates APPLEs from the TIVOs of this world, and why it is important to start with the purpose behind what you do. 

Looking at it from another angle, they are the vision, mission, and plan. Here is my very simple and minimalistic definition:
  • Vision is WHAT we want to become. It is the Destination. It is WHERE we want to get. 
  • Mission is WHY we want to become that entity, it is the reason why we are on that journey.
  • Plan is the vehicle that gets us there. It is HOW we intend to get to our destination. 

As @simonsinek says, we often start with the outer layer going in. Most of us are focused on showing the product (WHAT), without connecting with the audience on emotional level with our WHY. 

WHY is the soul of any product, any organization. Trying to sell the product without clear WHY is like selling hollow product(s) without any ‘soul’ in it.

start with Why

            People don’t buy what you do; they buy why you do it.

On the other hand, starting with WHY, you are connecting with the audience on an emotional level, on a much deeper level. As Simon indicated in the video, you buy with your heart, and then rationalize your purchase with your mind. You got to have a cause before you create a product and (try to) sell it. Start with the inner circle, start with WHY and everything else will fall in the right places. 

Case in point from the recent history, look at Tesla. Mr. Musk sold the WHY to us, simple. The company spends very little, next to nothing in the advertising money. Instead, people have bought into the WHY of Mr. Musk, and the companies he is leading. 

[bctt tweet=”#makeTheShift:  Start with WHY, and End in their Hearts! ” username=”beyondCSM”]

Start with the mission and then build products around it, products that help you satisfy your mission.