Tag Archives: book
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.
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 – 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 
are 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
Agile Book – Roles
We are getting closer to the publication of the Agile textbook that I have co-authored with Sondra Ashmore. It is such an exciting time for us and I want to use this blog series to highlight chapters from the book. I hope you enjoy this so much that you want to order the book. Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan.
One of the chapters that I was responsible for addresses the roles within Agile and specifically Scrum teams. Here are the chapter learning objectives as well as an excerpt from the section about Product Owners, something I am very passionate about.
Learning Objectives
- Understand the roles in Scrum with their specific responsibilities—product owner, Scrum master, and team
- Identify the attributes and personality types that are most successful in the various roles
- Learn the Agile definitions of “chickens” and “pigs”
- See how extended team members interact with the team
- Compare and contrast the roles in Scrum and the other methodologies
- Walk through practical examples of how the roles are filled in different-sized organizations
Product Ownership – Breadth
Another nuance of the product owner role is the breadth of his or her ownership. Does one product owner manage multiple products? Or is one product so big that it requires multiple product owners? Both of these situations are common in the workplace where teams are thin and expectations are high.
To examine the first instance, what are the advantages and disadvantages of having one product owner responsible for multiple products? The biggest risk factor is time and attention. Can the product owner devote adequate time to every product that he or she is responsible for? Does this person have the necessary depth of understanding to truly collaborate with IT on the best solutions? It is a risk, but certainly one that can be overcome.
In the instance where the product is large enough to have multiple product owners, there is a chance that the priorities will not 
align. Related to the previous reference of business value, if one product owner wants to expand to new cities to attract new users but another product owner places top priority on improving the processing speed, then you can run into conflicts. However, one of the core tenets of Agile is collaboration, which includes collaboration between product owners. Product owners need to be in communication with each other to clearly articulate the best plan for all groups—knowing that at any given time, one group’s needs will take precedence over another’s.
Even if you have a single product owner for every product, that does not mean that things are easy. Between systems there are interactions, and to create a new feature or make a modification, the product owner may need to consider dependencies.
