Dying to Adapt

The Death card is following me. I drew it two days in a row now and I’m wondering what the Universe is trying to tell me.

Rarely does this tarot card represent physical death so I’m not too concerned about an imminent demise.

img_1754

I am actually happy to see this bare bones figure on his white horse because he represents not only an abrupt end but also a new beginning.

A transformation.

A rebirth.

Death is not always a bad thing. Sometimes bad things need to end.

Sometimes sclerotic obstacles need to be broken down and removed.

Just like the Tower card helped me focus on the significance of the radical change at hand, Death gives me hope that there is something refreshing and different coming after the destruction.

Like a cosmic etch-a-sketch, it feels good to shakes things up and have an invigorating start.

Death teaches us to let go of outworn and outgrown ways of life and nudges us to move forward.

In my last blog Tower of Change,  I listed some options we have when facing change. We can resist it, we can embrace it or we can accept it.

Maybe with Death we have other choices.

When contemplating this dramatic card in the world today, I am reminded of the Agile principles of iterative development.

In this process you build, you inspect and then you adapt.

Build, inspect, adapt; build, inspect, adapt in a continuous cycle of short iterations.

What if this card is telling us to inspect and reflect on the death, let it go and they take action to adapt and improve?

Why can’t Death be a positive and cleansing experience? A fresh start?

Out with the old and in with the new. Kind of like those expensive chemical peels all the ladies at the day spa are getting these days.

Are we Dying to Adapt or stuck in our old, unproductive and unhealthy ways?

I look forward to drawing more Deaths cards and hope that I am open and ready for the transformation and rebirth it represents.

 

The Fool on the Hill and the Judgement Card

There is nothing like a good tarot card reading, a pending move to a new state and a bizarrely disgusting election news cycle to get me to look at things in an altered way.  An Agile Life encourages us to have frequent Retrospectives to review what is going well, what is blocking us and what we can do differently.

I view tarot cards as a mirror to the heart and soul and they often reflect thoughts and notions back to us in a new light.

judgementcardeagle

Below is a story about the Judgement Card, taken from the website Aeclectic Tarot“.

“There is no way to leave the past behind,” The Angel observes. “Each step wears down the shoe just a bit, and so shapes the next step you take, and the next and the next. Your past is always under your feet. You cannot hide from it, run from it, or rid yourself of it. But you can call it up, and come to terms with it. Are you willing to do that?

The Angel hands the Fool a small trumpet. The Fool is hesitant, but he knows that the Angel is right. There are certain memories he has a hard time looking back on as they make him feel guilty, ashamed, angry. He knows that he’s never come to terms with what happened and he must if he wants to make that final transition.”

Here are some retrospective thoughts and questions based my drawing of the Judgement Card last night:

Are we able to resurrect the past, forgive it and let it go?

Do we need to start something we’ve been putting off or have the courage to finally end something that isn’t good for us?

Is it time to move on?

img_1360

As I bask in the glorious autumn weather of Colorado and watch the leaves turn to orange, yellow and red, I remember that they will all fall to the ground soon, dead but nurturing to the soil below. I also have faith that the leaves will be reborn in the spring as the seasons continue to roll by.

I have hope that after the cold winter, there will be a better, brighter season but in the mean time…

It’s time forgive and move on to more important things.

Resolutions, Reviews and Retrospectives

Resolutions, Reviews and Retrospectives

As a matter of course, I don’t make New Year’s Resolutions until at least February and this year, I have not made any.

Since I am a Scrum Master striving to lead an Agile Life, I’ve started planning and living my life in 2 week iteration (sprints) and am doing my first Sprint Review and Retrospective today. It is so much easier to set and achieve goals in a short 2-3 week period rather than the whole year. Plus it makes me very happy and excited to move my yellow sticky note user stories from the “In Progress” to the “Done” column (I know I am a total geek. See my article on Confessions of a Dashboard Junkie for further proof).

It is satisfying to have rapid feedback and visualization on the completion of your small, bite-sized chunk goals (user stories) and it is important to do a thorough review of the Sprint Board at the end of each iteration to determine what is still In Progress and/or what is not started in the To Do column.

Sprint16.1start

Sprint16.1end

 

 

 

 

 

 

 

In the Retrospective, you can reflect on what you were able to complete and why, as well as what prevented you from starting or finishing a user story. Were there obstacles or unforeseen circumstances that interfered with you completing all your goals or did you simply procrastinate? Be brutally honest with yourself and strive to improve your process in the next sprint which starts tomorrow.

MIRROR02_a

The outcome of your Retrospective is a mini New Sprint Resolution and provides input to your next Sprint Plan.  This is why I don’t need New Year’s Resolutions anymore!

The Sprint Plan is done on the 1st day of the sprint and includes all of the user stories (goals) you want to complete in the next time period. It is meant to be a realistic picture of what you commit to getting done based on your understanding of the size and scope of the various items.

Living an Agile Life is rewarding, effective and less stressful than making huge blanket resolutions on some arbitrary date at the beginning of the year. Besides, your goals for the time period of Jan. 1-15 will probably be very different than your goals for Sep. 15-30. Conducting your Reviews and Retrospectives every 2 weeks will help you quickly analyze and adjust your life plans and goals as needed plus you will get so much more accomplished than if you didn’t track and plan with your Sprint board.

So here’s a toast to happy and healthy Sprint Reviews and Retrospectives!

May the Agile force be with you.

sprint1

Rebooting My Agile Life

In October 2013, I wrote the following in Part 1 of my blog’s “An Agile Life” series:

“What if we lived our lives in 2 week increments?

Imagine what it would be like to create a Backlog of all the things you wanted or needed to do in your life including all of your wishes and desires. Kind of like a Bucket list on steroids.

What if you reviewed, prioritized and ordered this list every 2 weeks?

What if you planned out which items on your list (User Stories) you wanted or needed to accomplish in the next 2 week time period (Sprint)?

What if you (and your team/partner/family) committed to completing these items by the end of the Sprint? “

Well, 2+ years later and after a serious New Years Day Retrospective, it is time for a major reboot in my life sprints. Time to create my Backlog again, prioritize my User Stories and work on them in shorter iterations.

Time to post my sprint board on the refrigerator!

DSC_1963

Here we go, Day 1 of Sprint 16.01, I’ll let you know how my Retrospective went in early February!

Here’s how you can get started on your Agile Life:

Step 1: Grab some sticky notes and markers and start writing out the items you wish to work on/ accomplish (one per note).

Step 2: Create your sprint board with a sheet of page. Make 3 columns: To Do, In Progress and Done.

Step 3: Determine your sprint duration ( 1, 2, 3 or 4 weeks)

Step 4: Place your items ( user stories on sticky notes) on your sprint board.

Step 5: Review your user story status and track progress each day until the end of the sprint.

Step 6: Conduct a Retrospective on the last day of the sprint.

Step 7: Update your sprint board during for the next sprint’s planning session.

Step 8: Repeat steps 4- 6.

Good luck and may the force be with you!

agile

 

 

Confessions of a Scrum Master, Part 3: User Story Happiness & Success

As a user story, I want the respect I deserve so that I don’t develop an inferiority complex.

Oh the user story! You either love it or you hate it. You understand it or you are totally perplexed and frustrated by it. The must fundamental and core element of the Agile process is often misunderstood, under appreciated and misused.

The User Story, child of the Epic and parent to the Task, occasionally suffers from an identity crisis. Last month I happened upon a sad and lonely 8-point story who had only one 0.5 hour task linked to it. It confided in me that it was really a Task masquerading as a User Story but it was too ashamed to tell anyone.

The role and purpose of the user story can sometimes be misunderstood to the point of causing heated conversations and disagreements among Product Owners, Business Analysts and Scrum team members who are new to the Agile process. Here the Scrum Master’s coaching and facilitation of the Agile process is critical to the success and happiness of the team (and the user story).

As a user story, I want to define an incremental unit of work in the “who, what and why” format so that the scrum team can efficiently deliver the requirements by the end of the sprint.

whowhatwhy_userstory

 

As a user story, I want to represent a small piece of business value so that the Product Owner can see the iterative development of the work.

As a user story, I want to describe high-level requirements in such a way that  it sparks conversations among the scrum team members.

As a user story, I want to have detailed acceptance criteria so that the team knows the definition of done and exactly what is expected at the end of the sprint.

As a user story, I want to be groomed and refined on a regular basis so that I will be properly understood, stack ranked and sized by the scrum team.

As a user story, I want to meet the criteria of Bill Wake’s INVEST acronym so that I can be well formed and have high self-esteem.

INVESTuserstory2

Acceptance Criteria of this INVEST story:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Scalable (small sized)
  • Testable

 

As the author of this blog,  I want to share my thoughts and insights about user stories so that you learn in a fun and memorable way!

Confessions of a Scrum Master, Part 2: The Requirements Challenge

Alternate title:  Oh the joys of documenting requirements on a new Agile project!

Many organizations struggle with adopting Agile since it requires such a fundamental and overarching shift in business process.  Often times the biggest challenge with the new process is how to gather and document Requirements.   I’ve observed that a piece meal approach to implementing Agile is not as effective since the performance benefits are not fully realized unless all Scrum team members and stakeholders are on board. So how do we get everyone on board?

First, it can be helpful for Scrum Masters to recognize that the Agile manifesto value of “Working Software over Comprehensive Document” is a struggle for many Project Management Offices ( PMO) and Business Analysts (BA). Organizations and firms which are heavily regulated have strict requirements on detailed project artifacts in order to pass audits and the PMOs and BAs are oftentimes the creators and/or keepers of these documents. In short, it’s a balancing act to the find the appropriate and agreed to level of documentation that meets everyone’s needs. These discussions and agreements can take place during Sprint 0 and reviewed in the Release Planning meeting.

UnicycleSDBC2004

 

Waterfall/RUP documentation habits die hard with some seasoned BAs. The urge to analyze, research and detail out full use cases and system requirements prior to the start of sprinting can be strong for those who are new to iterative development and User Stories.   The Scrum Master’s coaching and guidance on the Agile best practices for User Story creation and refinement are critical to keeping the project moving along and not getting bogged down in analysis paralysis.

And then is there is the battle of what tools to use to document and where to store the project and requirement artifacts. Boy can opinions and passions run hot in this area!   Whether you use TFS, Rally, Jira, VersionOne, PivotalTracker or any other application for tracking your User Stories, sprint tasks and velocity, your Scrum team and the Project stakeholders need to understand and come to an agreement that certain Requirement Documents of Record can should be stored, tracked and linked to in other repositories like Sharepoint or Blueprint.   Traceability is a key concern for many organizations and should be addressed in your Team Agreements and processes.

The Goldilocks Dilemma

How much detail do we need to put in a User Story? This is another deeply philosophical question and everyone seems to have a different opinion on it.

How much is too much? How much is too little?   What level of information and detail is just right?

 

3bowlsv3

As Scrum Masters, our role is to strike the right balance with the Product Owners, BAs and PMs so that the needs of the organization are met without sacrificing the benefits of the iterative design and development. This is certainly easier said than done but know that you are not alone in this challenge.

It helps to explain that details on the requirements will be uncovered and documented in a more collaborative manner with ongoing conversions and meetings with the entire team. Requirements will not be created in a vacuum and will be refined /groomed/ sized by the scrum team.

It occurs to me that this topic is important and meaty enough to deserve its own article, so I’ll dive into the details of User Story Creation in Part 3 of my “Confessions of a Scrum Master” series next week.

The behavioral changes involved in adopting the Agile can be uncomfortable and difficult for many people and teams. Documenting requirements in Agile often requires a significant shift in process and the Scrum Master’s coaching and facilitation role is critical to helping the team to learn and understand the value and benefits of iterative development while allaying their fears and concerns about the “new and different” way.

 

 

 

 

 

Confessions of a Scrum Master

Every thing I needed to know about being a good Scrum Master I learned from my high school soccer coach, Miss Lonegan.

Slide1

Here’s what was instilled in me on a muddy soccer field in the early 1980s.

Great coaches and leaders:

  1. Motivate and help the team to be successful.
  2.  Walk with the team, on the field, everyday.
  3.  Teach others the process by sharing fundamental tasks and techniques.
  4.  Guide the team without being overly controlling.
  5.  Communicate positively.

These successful actions and traits recently dawned on me when I realized how important Personality and Temperament are to being an effective Scrum Master.

Over the past 5 years, I have been observing team dynamics as a Scrum Master (SM) on multiple teams in 3 different companies and have witnessed a number of SMs crash and burn due to not leading like good coaches. Lack of communication and soft skills were also a common theme with the ineffective Scrum Masters.

The most successful SMs are true team players and are comfortable surrendering control to the Product Owner and team. Adept Scrum Masters truly view their role as being in service to the team, removing obstacles for the team and helping them to be successful.

Facilitation is another important role of the Scrum Master and requires a high level collaboration and strong, tactful communication skills.   The authoritative, directive, ” my way or the highway ” approach does not work well with Scrum teams.

Project Managers can sometimes get away with a lack of soft skills but Scrum Masters, who are facilitators and coaches, cannot.

In the Retrospectives with our team, I ask them to think about the Results, the Experience and the Process of Agile and the sprint. I view my Scrum Master role as critical to helping the team to not only achieve great results (velocity) but to enjoy the experience and the process- just like my high school soccer coach did all those years ago!