Category Archives: Agile

Prioritization – Part 2: MoSCoW and Risk-Value

As introduced in the first blog, prioritization is difficult.  The first and most important question is “should we do this at all?”  Once you determine that an effort is worth doing, we have to figure out where it falls relative to the other things in the queue.  There are a number of tools that we can use in this effort.

MoSCoW

The first tool in our arsenal is from Dynamic System Development Method (DSDM) and it is an acronym for Must have, Should have, Could moscow_blog2have, Want.  The technical definition for each category is as follows:

Must have: all features classified in this group must be implemented, and if they are not delivered, the system would simply not work.

Should have: features of this priority are important but can be omitted if time or resources constraints appear.

Could have: these features enhance the system with greater functionality, but the timeliness of their delivery is not critical.

Want to have: these features serve only a limited group of users and do not drive the same amount of business value as the preceding items.

To put MoSCoW  in action, we pull a reference from our book, Introduction to Agile Methods.  In this example, we are looking at the payment methods that could be offered on a new eCommerce site.

Must have: ability to accept Mastercard and Visa

Should have: add American Express and Discover

Could have: add ACH payments for transactions directly through banking institutions

Want to have: add gift cards

By understanding where each feature falls relative to the MoSCoW parameters, the prioritization is much easier.

Prioritization – Part 1: Should we do this?

As a Product Manager and an Agile Enthusiast, I have lots of conversations about prioritization.  It is really tricky.  Well, that’s not always true.  If you really only have one thing to work on, then I guess it’s easy.  For the rest of us that live in the real world, we have to balance multiple number one initiatives in a way that will deliver the most value to the business.  This is a first in a blog series about Prioritization.

The First Question

The very first question that should always be asked when considering something for prioritization is – Should we do this at all?  People are too often moving too fast and trying to be responsive to the point that sometimes we stop thinking.  One of my mentors had a saying:  “This is top of mind, not top of list.”  I love that.  I first heard this when he called me after just having talked to an important client about a feature they wanted.most_imp  He was excited and it was a good idea.  I asked him if he felt like we should reshuffle our priorities and execute on this newly introduced concept.  He paused and took a moment to really think through my question.  And then he responded with the now often quoted “Top of mind, not top of list.”  That is a fantastic barometer to keep in mind when you have a flash of brillance.  It might just be a flash and you need to stick to your existing priority list.  Bright, shiny objects can come into view, but they do not always warranted our immediate attention.

Hiring a Product Manager

Image source: http://www.rochester.edu/working/hr/employment/

Image source: http://www.rochester.edu /working /hr/employment/

Having moved from Austin, TX to Des Moines, IA to San Diego, CA, I have had to learn a few things about hiring product managers.  In Austin, Product Management is a well-known profession and many talented people who are either natural product managers or trained ones are available for hire.  Des Moines, like many areas in the country, is not a product management town.  It is full of wonderful, hard working people but with industries centered around insurance and agriculture, there has not be high demand for product management, as a discipline.  This is changing, both with the enthusiasm around Agile as a software development methodology and the increasing number of start-ups in the “Silicon Prairie.” The need for product managers is, therefore, on the rise.  If you are tasked with hiring Product Managers, here are three tips to help.

Comfortable withOUT a job description

For nearly every job that I have had, I have lacked a job description.  Not only am I comfortable with that, I actually prefer it.  And I think most natural Product Managers feel the same.  Of course, we all want to know the rough boundaries around our job but we tend to be very comfortable with ambiguity.  A product manager’s job may range from strategic product visioning to market research to customer interviews to tactical prioritization to sales training to process documentation and much more.  What you intend to get done when you arrive at the office may differ completely from your accomplishments at the end of the day.  As one of my colleagues so eloquently stated, “A product manager is the CEO of that product” and just like company CEOs, you have to roll with the punches and respond to the needs that are presented that day.

Agile 2014 Recap

Here is another guest blog from my co-author on the Introduction to Agile Methods textbook, Dr. Sondra Ashmore (@sondra1130).  This is her recap of the Agile 2014 Conference in Orlando, Florida.

Agile 2014 Recap

Sondra Ashmore participating in 3D Pair Programming Session.

Sondra Ashmore participating in 3D Pair Programming Session.

I think I have finally recovered from the excitement of Agile 2014 that took place in the fun and sun of Orlando, Florida this year.  I found it very invigorating to spend the week with nearly 2000 fellow Agile enthusiasts from around the world.

When I initially signed up for the conference, I decided to fill my schedule with a variety of different sessions from the wacky (Agile Karaoke) to the more traditional (Agile Enterprise – Are You Ready?) and finally some research sessions to satisfy my academic side.  I was glad I did because it helped me get a general feel for the current trends in Agile and forced me to look at my world in a new way.

 

Lessons from an Author

The fact that I can title this blog “Lessons from an Author” is both amazing and surreal.  You see, my first book was just published so I guess I can officially say that I am an author.  (Buy it here!) Holding the book in my hands led me to reflect on the last 18 months and the journey that my co-author, Sondra Ashmore, and I have been on.  For what they are worth, here are the lessons that I have learned along the way.cover

Persistence Required

When writing a book, or doing any meaningful and challenging undertaking, you must have persistence.  This is obvious, I know, but let me share the backstory.  There were two chapter in our Agile textbook that were particularly difficult – the chapter on roles and the one on culture.  Not that we didn’t have plenty of content, that was never the problem.  It was trying to figure out a way to convey the information in a logical and cohesive fashion.  Each chapter was re-written nearly from scratch three times.  By the time you are writing a chapter for the third time, it is easy to get frustrated, depressed, aggravated, annoyed (can you tell that the memories are still fresh??) and a whole host of other emotions.  This is when you need someone to pull you back to the surface.  In my case, I was lucky to have Sondra.  In my time of doubt, Sondra reminded me that this is the time and circumstances that separates published authors from those with unpublished work sitting in a drawer.  It is persistence.  Pure and simple.  There are lots of great writers out there.  But persistence is the distinguishing trait for true authors.

Agile Book – Culture

For the final blog post in our series about our upcoming book, Introduction to Agile Methods, we are going tackle the cultural impacts of an Agile implementation.  Agile is a simple set of concepts to understand (once you read the book, of course) but that doesn’t mean it is easy to implement.  It can be challenging for organizations to adopt principles like self-organizing teams, continuous improvement and frequent delivery.  This chapter examines creating an Agile culture from the perspectives of a team member, manager and an executive.

Learning Objectives

  • Understand organizational culture and why it matters in an Agile implementation
  • Dive into ways things might be different in an Agile organization from a developer, manager, and executive viewpoint
  • Look at successes and failures in behaviors to see the cultural impacts
  • Understand how the Agile principles drive different behaviors in an organization
  • Investigate the healthy team dynamics of self-organization teams, continuous improvement, frequent delivery, effective seating arrangements, incorporating virtual resources, and adapting to the changing environment
  • Explore how an Agile workplace differs for managers and the ways that they must change with regard to teamwork, trust, and transparency
  • Review the role of executives and how their behavior can position an Agile transformation for success with executive alignment, respecting priorities, creating supportive environments for the teams, and driving the right behaviors with metrics

There is so much great content in this chapter, it is hard to pick one excerpt to spotlight.  We chose the executive viewpoint and how important it is for the executive sponsor to embrace the change and provide consistent leadership.

Staying the Course

Image source: http://blog.lifestyleforhealth.com/stay-the-course-guest-blog-by-anna-townsley/

Image source: http://blog.lifestyleforhealth.com/stay-the-course-guest-blog-by-anna-townsley/

An Agile transformation is challenging for most organizations. Some command and control managers will fight the change, offering dire predictions of failed projects as examples of why this is a bad idea. Developers may not embrace the increased accountability and transparency, and some may choose to leave the organization. There are new expenses in the form of seating arrangements, training, and Agile tools that may stress the budget. Agile transformations also have a history of bringing chronic issues that the organization has ignored for years to the surface where they must be confronted. All of these are reasons why an executive might abandon the effort and simply revert to what is comfortable (but ineffective). Any change worth making is going to require effort, and Agile is no different. The strong Agile executive will work through these issues without wavering on the commitment to Agile.

Agile Book – Marketing

Our Agile textbook is just weeks away from being a real, tangible thing and it is so exciting.  Continuing with our blog series with excerpts from the book, this one comes from the final chapter titled Agile Beyond IT.  One might wonder why an Agile textbook marketingwould dedicate a whole chapter to marketing products developed by Agile teams or even how Agile has been deployed in Marketing and other corporate departments.  My co-author, Sondra Ashmore and I believe that it is important to remember that a product is not successful because it was created by an Agile team.  Successful products have to be launched correctly too and that can be an equally significant challenge.  Here are the learning objectives from this chapter as well as an excerpt on marketing with agility.

 Learning Objectives

  • Learn how the Agile values apply to bringing products to market, beyond the development efforts
  • Understand ways to systematically collaborate with the marketplace through discovery and validation
  • Explore the changing dynamics for marketing of products with the proliferation of new channels and the complexities of brand management with social media
  • Review how wireframes and prototypes can be used in the marketplace to inform priorities for Agile software development teams
  • Learn how to be Agile when launching products by managing features, limiting the initial audience, and pursuing continuous enhancements
  • Take the Agile concepts beyond IT and product development and see how other corporate organizations can benefit from Agile values and principles
  • Discover how Marketing has taken Agile to a whole new level of discipline by creating their own manifesto

Marketing with Agility

There are a number of ways to effectively market products built with Agile development teams. Some Agile purists are uncomfortable committing dates and features to the marketplace, but in most industries, it is not optional: Existing customers and late-stage prospects demand to know when and how the product will evolve. We outline several ways to balance these two sides.

Agile Book – Tracking

One of the amazing things about co-authoring this Agile textbook (Introduction to Agile Methods) with Sondra Ashmore has been the opportunity to learn new things and research other methodologies.  For our excerpt from Chapter 8, Tracking and Reporting, I had the opportunity to research Feature Driven Development (FDD) and a great concept called Parking Lots.  Here are the Learning Objectives for this chapter and more on FDD Parking Lots.

Learning Objectives

  • Understand Kanban, its effectiveness, and when it is used
  • Learn the definition of work in progress (WIP) limits and how they can identify bottlenecks in processes
  • Explore different tracking mechanisms used in XP, Scrum, Lean, DSDM, and Crystal
  • Understand burn charts, both burn-up for release management and burn-down for sprint tracking
  • Examine feature-driven development (FDD) parking lots and how they assist in tracking large and complex projects
  • Learn the different strategies for tracking quality through an iteration
  • Understand the importance of meetings in tracking progress and course correcting
  • Learn the purpose and desired outcome for each meeting—the daily stand-up, the Sprint review, and the retrospective
  • Consider the metrics for measuring the success of Agile projects

 

Feature-Driven Development (FDD) Parking Lots

FDD incorporates an excellent way to track progress on larger projects where many activities are contributing to a cohesive whole. For our Cayman Design project, we want to create and sell weather-related calendars to customers; this is a large departure from the other features in our weather app because we have to consider inventory, shipping, and payment details. An example of an FDD parking lot might look like what is shown in Figure 8.7.

FDD2

 

 

 

 

 

 

This tells us that the feature “Collect Customer Information” consists of seven stories totaling 32 points. At this moment, we are 75% complete, and the feature is needed by August 2014. The color on the story can indicate its health, this particular story being yellow, meaning it is in jeopardy. Although this is an interesting depiction of information, it is not necessarily more valuable than any of the other Agile tools we have discussed—that is, until you add many other components, and then the picture painted by the FDD parking lot is incredibly useful (see Figure 8.8).

Agile Book – Technical Debt

In the next edition of this blog series highlighting excerpts from our upcoming book, we will tackle the tricky subject of Technical Debt.  To be honest, I had a hard time choosing a single topic from this chapter because there are so many great topics covered – debt2Definition of Done, Planning Poker, Value Stream Mapping, the Kano Model, Velocity, the XP Planning Game – and much more in this chapter on Grooming and Planning.  And it includes an interview with none other than Mike Cohn!  If this post, or any of the previous ones on Roles or Requirements or our guest blog from co-author Sondra Ashmore inspire you to want to purchase the book, please visit Amazon and search on Introduction to Agile Methods.

Back to Planning and Grooming, here are the Learning Objectives for the chapter.

Learning Objectives

  • Understand the elements of a product backlog and what traits lead to the strongest deliverables
  • Dive into prioritization and learn different methods for understanding what is the most important feature or item to work on
  • Explore estimation and the different practices and measures that are used today
  • Understand story points and planning poker as ways to discern the level of effort and complexity of the user stories/requirements
  • Learn the other inputs that affect the planning process, such as team velocity, definition of “done,” technical debt, and bugs/defects
  • Evaluate Sprint planning and the XP planning game to learn how commitments are made and work is planned
  • See how maintenance work can be incorporated into Agile teams
  • Review the triple constraints model and how it is handled within the Agile framework

Agile Book – Requirements

This is the second in a series of blogs about our upcoming textbook called Introduction to Agile Methods that I have written with Sondra Ashmore.  The first blog spotlighted Roles and our second post was a guest blog by Sondra on Agile in Academics.  I hope these blogs inspire you to want to read the whole book!  Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan. The chapter spotlight for this post concerns Requirements and how they Userstoryare approached very differently in Agile, as opposed to Waterfall.  Within Agile, the terms around requirements include User Stories, Epics, Acceptance Criteria, Personas, Release Management and much more.  The excerpt that I have chosen to share here addresses a particularly challenging aspect of managing requirements and priorities – Customer Specific Code Requests.  First, here are the learning objectives for the chapter.

Learning Objectives

  • Recognize the differences between Agile and Waterfall with regard to requirements gathering and documentation
  • Understand the format used within Scrum for user stories, including epics and acceptance criteria
  • Explore several examples of how user stories are broken down from epics to child user stories and how acceptance criteria add important details to the story
  • Learn how the other methodologies differ from Scrum in their terminology and practices
  • Examine how requirements can be enhanced by using personas or engaging User Experience (UX) designers to better understand potential system users
  • Understand how user stories and Agile development efforts map into a marketplace driven by consumer demands and customer-specific development requests
  • Value the importance of communication and transparency when it comes to requirement specifications and priorities
  • Explore Lean software development and the Lean start-up concepts and how they influence the product development process