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!

A Fresh Look at Retrospectives

It’s been a few months since I wrote the Agile Life series and I came across a new way to think about Sprint Retrospectives.

What if we asked these 3 questions at the end of every life sprint ( 2-4 weeks)?

1. What am I going to start doing?
2. What am I going to stop doing?
3. What am I going to continue doing?

Food for thought Grasshopper…..

20140507-145514.jpg

An Agile Life- Part 3

To conclude my Agile Life series I’d like to expand on the last two concepts that are key to implementing your Agile life.  Again, one of Stephen Covey’s habits for highly effective people is incorporated in them and that is  “Sharpen the Saw”.

  1. Timeboxing (Sprinting)
  2. Backlog Creation
  3. Backlog Refinement
  4. Review and Retrospective

Item #3 is a productive and adaptive feature of the agile process and involves the continuous Refinement of your Life Backlog.  This is a time toward the end of every sprint when you look ahead to the next few sprints and plan what you are going to focus on and accomplish next.  It’s your time to relook the order of your items and move them up or down in priority based on your needs and desires.  It is also a time when you can add or remove items from your backlog based on changes in situation.

The final component of your Agile Life process is the Review and Retrospective.  This is done on the last day of every sprint and is an ongoing process. It is a review of what you accomplished.  What did you do well and what didn’t go well during the last 2-4 weeks of sprinting?  What were your results and achievements?  Did you complete all of the User Stories that you committed to in your sprint?  If not, do you want to add them to the next sprint?

MIRROR02_a

Other things to reflect on during your retrospective are your thoughts and feelings on the process and experience of Agile.   What did you like about it?   What did you hate?  What could you do better next time to be more efficient and effective?  What could you do differently in the next sprint so that you are more productive?  Specifically, you should strive to take action on one of improvement items from the Retrospective and immediately incorporate it in to your next sprint.

Agile’s continuous improvement (sharpening the saw) aspects are powerful.  The process facilitates SMART goal setting and the time boxing is key to increased levels commitment.  The frequent reviews and refinements helps you change course sooner rather than later.

close-up-of-a-jagged-and-sharp-saw-blade

Living an Agile life requires a bit more planning and discipline in your activities but the rewards will be great. If the process is a bit unproductive and awkward at first, don’t give up!  Most agile teams don’t find their rhythm for 3-5 sprints.   Give it a try for a few sprints and let me know how it goes.

An Agile Life- Part 2

How will living an Agile Life benefit you?   I hate to say it, but it depends.  It depends on how serious and committed you are to the process.  The Agile methodology does require discipline and daily/weekly focus and if you follow it, the rewards can be swift and significant.  Teams in professional work environments tend to become high performing and there’s no reason why you and I, on a personal level, can’t live life with increased levels of happiness and satisfaction.  We can have more sense of accomplishment, less stress and dare I say, more control over our destiny.

Both Dale Carnegie and Stephen Covey have agile principles incorporated in their best selling books,  “How to Stop Worrying and Start Living” and “The 7 Habits of Highly Effective People”.    Mr. Carnegie sought to reduce worry by living in “day tight” compartments and focusing on the “tasks at hand”. Mr. Covey’s first three habits are completely in line with Agile’s backlog creation and refinement processes:

  1. Be proactive
  2. Begin with the end in mind
  3. Put first things first

To live your life in an agile way, we need to understand and implement 4 key concepts:

  1. Timeboxing (Sprinting)
  2. Backlog Creation
  3. Backlog Refinement
  4. Retrospective (Review)

In Agile, a timebox (sprint) is a previously agreed to period of time during which a person or team works steadily towards completion of some goal(s).  The duration of this timebox can be set to whatever you want or agree to with your team but it should remain consistent from sprint to sprint.  Most Agile projects have sprint durations of 2, 3 or 4 weeks.

For our Agile Life sprints, I think a 2 or 4 week timebox could work well.  Pick an interval duration you feel comfortable with and go with it.  Since I like more frequent check ins and reviews, I’m personally planning to go with 2 week sprint cycles for my life.

sprint1

Now that we have our sprint time intervals figured out, let’s talk about the fun stuff -our Backlog, our wish list, our bucket list on steroids!

The first step is to write down all of the things you’d like to do in the next year.  These things can be goals, actions, achievements, travel plans, household tasks, personal improvement, professional development, financial results or healthy lifestyle changes.  Anything you want should be added to the list.   These backlog items (User Stories) should be broken down into small enough chunks so that they are “Sprintable” i.e. capable of being completed during the time interval you determined for your sprints (2- 4 weeks).  In addition, the completion of these items/actions should be in your control (or that of your team).  If your Stories can not be achieved in a sprint,  they need to be broken down into smaller chunks or phases.  For example, if one your backlog item’s objective is to lose 10 pounds in 6 months then you could create multiple User Stories which state “Lose 2 pounds”.

Once you have a good draft of your Backlog completed, you’ll need to order and prioritize the User Story items.  Which items are most important?  What things do you want to accomplish first?  Then you need to divide up the items into your sprints.  For Sprint 1, include the 2-5 items that you can realistically accomplish during the time interval set.  If the timing is off for a Story and it can’t be done yet, just move it down the list and you’ll get to it later.

The process of Backlog creation is fun, rewarding and sometimes eye opening.   Brainstorming ideas and sharing with your friends and family can also help to clarify your goals and desires.  Give this phase some time and effort and then next week I will conclude the Agile Life series with Part 3 and we’ll dive into the final two components of the process : Backlog Refinement and Retrospectives.

An Agile Life- Part 1

I am a Scrum Master.  It’s a cool title with interesting roles and responsibilities.  On the surface, I facilitate a team in an Agile software development project but lately I’ve found myself having to analyze and consider the psychological and personality profiles of the team (a topic for another blog post).  I am a servant-leader, coach and part time grade school teacher in a process that stresses the importance of communication and teamwork.

Image

Agile is a framework based on iterative and incremental development where requirements and solutions evolve through collaboration within a self-organizing team. It can help teams become high performing in a relatively short amount of time, assuming they follow the guidelines and principles of Agile  (the “hard and fast rules” as our Agile coach Henry tells us).  Henry is very wise and often reminds me of Obi-Wan Kenobi. I’m not sure yet if I am Luke Skywalker or Princess Leia… but I digress.

Our scrum team meets every day for a 15 minute Standup meeting and we work in two week long Sprints.  At our daily Standups we review the commitments we made to the tasks in our User Stories and state what we plan to do in during the next 24 hours.  During each Sprint we conduct a Backlog grooming meeting, a Demonstration of our completed work and a Retrospective review of how we did.

The Agile process and experience has been stimulating, fun and rewarding and it has recently got me to shift my way of thinking about things. I’ve started asking strange questions like  “What if we lived our lives in 2 week increments?”.

What if we had an Agile Life?

Image

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?

What if you sat down at the end of every Sprint and reviewed what you accomplished (Retrospective)? What went well?  What didn’t go well? What were the results?  What can you do better next time?

Imagine what it would be like to take one action item from the last Retrospective and apply it to your next sprint.    What would this Agile process do to the level of satisfaction in your life?

What if you were the Scrum Master of your life?

In An Agile Life- Part 2, I’ll dive deeper into some of the impacts, benefits and ramifications of living life in 2 week increments.