Agile is NOT a Methodology

Agile is a Mindset! Agile is Aloha!

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!

Back from my mini retirement..

I wrote about “taking Sagmeister” in my earlier post last year. This is based on a book I read about two years back. In this book, Drive, author Daniel Pink talks about “taking Sagmeister”, inspired by designer Stefan Sagmeister. Essentially, it is about taking mini and micro retirements NOW rather than deferring the big retirement. 

https://instagram.com/p/BWFlH9WD7tq/

This year, I took about two weeks off from routine life, and was on European vacation. We went on to Portugal-Spain tour, and it was amazing! I highly recommend visit to these two beautiful countries, filled with lots of history, architecture, and natural beauty.

https://www.instagram.com/p/BV-oKk3DPdc

Now, snapping out of the vacation and back to work! Rather, start working towards the next mini-retirement!

Remember, we work for living, and not living for work. You got to have fun, so sprinkle the mini vacations in your year. Have fun!

True Catalysts of Change

True Catalysts of Change. At beginning of 2016, this was one of my goals. As we draw it to close, I am happy to look back to a list of books I have read. These are the true catalysts. They have the power to change your world!

When you review this list. Notice that I do not have agile/scrum related books on my list. That’s easier to learn. The harder part is shifting the mindset. These books will help you there. With the right mindset, you will go further than you can imagine now. You will surprise yourself!

I read about two books per month. And, spend almost $0 for reading those books. [Hit me if you want to know how]

For now, here are the top 5 books from my list with tremendous power to influence and change your world in 2017.

  1. Creativity Inc – Overcoming the Unseen Forces That Stand in the Way of True Inspiration by Ed Catmull and Amy Wallace

Creativity Inc - Overcoming the Unseen Forces That Stand in the Way of True Inspiration
Creativity Inc – Overcoming the Unseen Forces That Stand in the Way of True Inspiration

2.Switch: How to Change Things When Change is Hard by Chip Heath and Dan Heath

Switch, Transformation,GetHyper, Agile, Get hyper
Switch: How to Change Things When Change Is Hard

3.Essentialism: The Disciplined Pursuit of Less by Greg McKeown 

Essentialism, Agile, transformation, getHyper
Essentialism: The Disciplined Pursuit of Less

4.Onward: How to Starbucks Fought Its Life without Losing Its Soul by Howard Schultz 

agile, gethyper, transformation
Onward: How to Starbucks Fought Its Life without Losing Its Soul

5.The Rich Employee by James Altucher

True Catalysts of Change
The Rich Employee

The Art of getting MORE done with LESS

Playbook for Scrum Teams

Can Agilists use Check Lists? Can checklists help them perform at a much better level? To answer this question, we will have to visit the two bookends of User Stories. Please grab copies of your team’s Definition of Ready (DoR) and Definition of Done (DoD).

Two book of end User Stories
Two books of end User Stories: DoR, DoD

A user story should not be allowed to go onto a sprint backlog unless it meets all the items listed on DoR; in order for it to be marked as READY. On the other end, teams are supposed to mark a user story as DONE only when it meets all the criteria a laid out in the DoD. Aren’t these checklists? Can we expand them to other areas of doing Agile?

Why use the Checklists?

If NASA can use checklists to send satellites into the outer space. If surgeons can use the checklist to eliminate contamination in the surgery room, why can’t we, the Agilists, use the checklists to eliminate the worst, minimize the waste, and improve our productivity? As Atul Gawande describes in his book, The Checklist Manifesto: How to Get Things Right, the knowledge exists, but often times we fail to apply it correctly.

[callout]
We need a different strategy for overcoming failure, one that builds on experience and takes advantage of the knowledge people have but somehow also makes up for our inevitable human inadequacies.
– Atul Gawande,  The Checklist Manifesto: How to Get Things Right
[/callout]

Listed below are some additional benefits of using Checklists.

  • Helps you analyze what you are doing, why you are doing and then eliminate unnecessary steps and optimize it by combining some of them.
  • Makes work results more predictable.
  • Helps you in making Repeatable, predictable process.
  • Helps in delivering consistent quality and results.

Outline path to Success

Checklists, in essence, can help you improve your performance. They outline the path to success, with minimal resistance, because they are infused with your experiences and learnings from the past.

As Edward Deming once said, “don’t look at the individual, look at the system.” You can start with a simple checklist, and infuse them with your experiences and learnings. Refine them as you use them by incorporating the lessons learned with each use.

checklists
make it-use it-refine it-agile checklists

You can create a checklist on pretty much anything! If I know that I’m going to be doing a specific activity more than once, I would create a checklist.

I follow a simple process to create them. Start with an outline of what tasks you would have to carry out to complete the activity. You don’t have to put in a lot of time and effort and come up with an elaborate checklist. Once you have the initial outline, just do ‘the thing’! And, as you do it, refine the list.

Yes, the initial list may not be complete. Yes, it may not be elaborate. But you have a checklist that you can improve on and make it better as you do it again and again. To ensure the ‘continuous improvement’, one of that last item that I almost always have is:
Is there any way I can improve this checklist?

Automate or Delegate

In his highly successful book The Four Hour Week, Tim Ferris suggests four simple steps to freedom:  Eliminate-Simplify-Automate-Delegate.

One of the side benefits of having checklists is that it helps you delegating the activity or individual tasks. It also helps you eliminate the unnecessary steps as you use them and optimize them. Once you have used a checklist to complete the activity couple of times, one of the three things could happen.

  • Automate:
    Find a way to automate the activity.
  • Delegate:
    If you cannot automate this process then find a way to delegate it to somebody who can follow your checklist.
  • Do It yourself:
    If you cannot delegate it and you are ‘forced’ to do it,  you should be able to finish it quickly and efficiently as you have optimized your checklist. This should allow you to finish the activity quickly, with a higher quality, minimizing, if not completely eliminating, the waste.

Enabling and Empowering

Checklists are enabling and empowering! They are ‘concentrated doses’ of experiences and learnings, acquired over multiple iterations. They help you in improving your Sprint Planning, the Backlog Refinement, Sprint Review, and many other events and activities.

[callout]
Even the most expert among us can gain from searching out the patterns of mistakes and failures and putting a few checks in
– Atul Gawande,  The Checklist Manifesto: How to Get Things Right
[/callout]

Create one, use it, and you will realize how liberating they are! Let us know your experience in the comment below. And, don’t forget to share it with your peers and community.

Why reinvent the wheel? Get this booklet (containing various checklists) and get a jump start!

Add to Cart

Playbook for Scrum Teams – Get it Today!

Dependency Wheel with Scrum team

Dependency Wheel

Can dependencies derail your project? What is the impact of these dependencies on your initiative?

In today’s hyper connected world, it will be difficult to have a project that did not have any dependencies, internal or external, upstream or downstream on other projects or initiatives, vendors, tools, or functionality.

Impacts of Dependencies

If you are not careful about the dependencies, if you do not put any effort in identifying them, they will sneak up on you and derail your initiative:

  • The later you identify, the more costly it will be to address them, the more time it will add to your delivery time, the more negative impact it will have on the quality of work you can deliver.
  • You will be dealing with hot heads! The stakeholders will not be happy to hear you that ‘it will take more time!’
  • Your estimates will be way off, if you ignored the dependencies

So, why not be intentional about them as you start on an initiative and through the execution of it; why not spend some time upfront talking about potential dependencies.

[bctt tweet=”Dependencies will sneak up on you and derail your initiative! Identify them upfront with Dependency Wheel! pic.twitter.com/1FrLPgODOF”]

Dependency Wheel

I use this simple tool with the teams I coach. It is a simple, intuitive, easy to use, yet very effective tool.

Start this session with your team by drawing a circle at the center of whiteboard or flip chart sheet. Put your program/team name in the center. All the spikes on this wheel are the dependencies that are known at the time. As you identify new dependency, just draw another spike.

The more rims you have on the dependency wheel, the more air it has to cut through, the more friction it has to push through. Similarly, your program/project will have to cut through more of the red carpet and push through more friction from other projects if you have more rims on your dependency wheel.

[callout]The more rims you have on this dependency wheel, the more difficult and complex the project will be. It also helps you in setting the expectations with you stakeholders, it also helps team when they are providing their estimation.[/callout]

Here is a sample, from a team I coached in the past at a client.

dependency wheel

Why identify Dependencies?

As you can see, it is of paramount importance to spend some time on thinking about them and identify them upfront. Granted that you will not know all the dependencies. But, mere fact that you are putting some time to think about them upfront is a huge win. It gives you a gauge as to how much additional force you will need to push through the friction.

Above all, it helps you in setting the expectations of all the parties. It helps you ground the expectations of stakeholders. It also helps ground the team and provide more realistic estimates.

As I mentioned, it adds tremendous value and increases your chances of success on a program or initiative. You can start reaching out to those partier (on whom you are dependent, or who are dependent on you). The cross functional team, works on the initial version of this wheel as they go through the planning activity (Release planning, Sprint planning.) And, then it can be a good artifact to take to your Scrum of Scrum.

[bctt tweet=”Put this wheel on your backlog, or else your program will derail (for sure, at some point in future)”]