Category Archives: Agile

Agile in Academics – Guest Blog

Please enjoy this guest book from my co-author, Sondra Ashmore.

I have spent my career working in IT for Fortune 500 companies, so it is fair to say that my career has followed a corporate path rather than an academic one. I am happy with my choice, but there has always been a part of me that is fascinated by higher education. I dabble in the academic world by teaching an occasional course, speaking at conferences, writing journal articles and soon publishing a textbook about Agile software development methods with Kristin Runyan. I love to learn, contribute to the knowledge base and help people acquire the skills they need to achieve their goals.

Sondra_Ashmore_headshot_v2In 2009, I returned to school to finish my doctorate. I had been practicing Agile methods at work for a couple years and assumed there would be an Agile course offered at my university. I was surprised to learn that most of my (very technical) professors had scarcely heard of Agile and the thought of teaching an Agile course was not on their radar. I decided to do my dissertation research on Agile methods due to the limited research on the topic. My research encouraged me to network with many local Agile enthusiasts. They complained that there was not a pipeline of students at any of the local universities who even knew the basics of Agile requiring them to do extensive training with all of their new hires. They were desperate to have an Agile methods course taught and encouraged me to sell the idea of an Agile course to my university. I presented the idea to my university and was subsequently recruited to teach because I was the only one they could think of that had any expertise or experience with Agile.

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 Manyto1align. 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.

Building a Product Owner – Existing Backlog

Product Owners – like great products – must be developed.  While some skills are innate, others must be learned and organizations tend to throw new Product Owners into the mix without adequate information. In this blog series, we have explored new product owners who are assigned to new products and those owning a system migration.  Now we are going to explore a new product owner who takes over an existing product with a robust product backlog.  In some respects, one might think this is the easiest of the three scenarios but it comes with its own set of challenges.  Here are some tips for how to get started.

1. Get to know your customers

The first step to get your arms around an existing backlog is to understand your current customers.  To do this, you need both

Backlog in Jira Agile

Backlog in Jira Agile

qualitative and quantitative information.  Data is always your friend.  How many customers do you have?  Are they profitable?  Are they the ideal customers that you want to attract?  Once you understand the numbers, now you need to actually talk to customers.  Schedule interviews with key customers – both happy ones and those that are frustrated.  Use your strong product management skills by asking open ended questions.  My favorite is “What keeps you up at night?”  Let your customers talk or complaint or suggest – wherever the conversation goes can be valuable.  Knowing who is buying your product is very important.

Building a Product Owner – System Migrations

We have a problem with Product Owners in Agile.  These are incredibly difficult jobs and it is easy to blame the product owner when things go wrong because “the requirements were not clearly articulated or prioritized.”  That might be an easy path, but it often is neither correct nor fair.  Instead of pointing fingers, let’s support our Product Owner and give them the training and tools that they need to be successful.  Just like we introduced with developing New Products and explored with existing backlogs, here are some tips and tricks to managing system migrations.

Image Source: http://tinyurl.com/nghasux

Image Source: http://tinyurl.com/nghasux

Moving from old technology to new is a common project for Agile teams.  Many companies have platforms that are no longer providing the necessary value and features to the marketplace and IT organizations are faced with the challenge of moving from an old, tired, inflexible system to a new, dynamic, configurable system.  Or it might not be that dramatic – perhaps you just need to move from one software package to another for cost or vendor relationship reasons.  Either way, a new product owner must discover how to break this big effort down into manageable chunks.  How do you get started?

1. Analyze what is being used

The first step is to figure out what pieces of the legacy software are actually being used.  There is no sense migrating functions or features that no longer matter to the organization.  If you can weed out some portions of the migration to minimize the size of the effort, that is great news for the company.  Some firms want to skip this analysis step and just build “like for like.”  This approach will save time as part of the project prep, but it will cost precious developer time down the road.

Building a Product Owner – New Product

Many of the complaints that I hear often about Agile implementations concern the product owner.  Either the business is not engaged appropriately, or the product owner is indecisive or unavailable, or the quality of the requirements/user stories is poor. Whatever the situation, the product owner is often “at fault.”

person4Instead of lamenting why we do not have good product owners, I would like to shift our thinking to: How can we build a Product Owner?  These are challenging jobs and often the people put in them have little background on what is expected of them.  This is the first in a series of three blogs to help us build better product owners, which will lead to better products.  First, let’s examine a new product offering.  Where would a new product owner start?

For this effort, I recommend a three step process and I have to give credit to David Hussman who provided some of the inspiration for this topic.

1. Create personas

Who is going to use this new product?  Who is your buyer?  Will you have power users and casual users?  Do you need to consider administrative users?

Personas first came into the conversation with Alan Cooper’s book “The Inmates are Running the Asylum” in 1999.  Personas are fictitious people who are going to use the system so the Product Owner can think about user interactions and how best to optimize the experience.  Let’s map out a few personas.

Networking and Blogging – Is it worth it?

Have you ever worked on something only to wonder “is this worth the effort?” “Does it matter at all?”  “Does anyone care?”  I know I have – and it relates in part to these blogs.  In 2013, I set a goal that I was going to write 52 blogs – one per week.  If you have ever tried to maintain a blog site, you know that is an ambitious goal.  But I was committed so even when I would have rather been reading a book or walking the dog, I wrote blogs.  And if I am honest, it did give me a sense of accomplishment when I achieved the goal.

Blogs

As I worked on my 52 blogs, most were about three subjects that I am deeply passionate about: (1) Product Management, (2) Agileflat orb and (3) Leadership.  I have  a good amount of practical experience, I have taken awesome training classes and I have devoted time reading and studying on these subjects, so I hope that I have something useful to share.

Agile in 100 words

Introducing Agile into your software development projects, or other organizations in your company or into your life has produced
wonderful, empowering results for many people – myself included.  I often get asked “What is Agile, in simple terms?”  Here is my attempt to boil it down to 100 words which will hopefully resonate for everyone, regardless of your background.

Agile is an approach to problem solving.  We tackle big projects by breaking them down into small, deliverable chunks.  After each chunk is completed, we inspect it and adjust based on what we learn.  We prioritize each chunk based on its value, to ensure we work on the most important stuff first. We work as a team where smart people get together face-to-face to brainstorm solutions to complex problems.  We succeed as a team and measure our progress to immediately address any roadblocks.  We strive to deliver more chunks with higher quality and clear value on a frequent, sustainable basis.

100Cloud

What do you think?  What is missing?  Does that make sense to people who aren’t part of this movement?  I would love to hear what you think.

 

 

 

To learn more, please reference the book Change, Inc.: An Agile Fable of Transformation available on www.amazon.com.

Agile: Is Rework Bad?

I recently had an enlightening conversation with someone who was just learning about Agile.  She was deeply entrenched in a Waterfall methodology and legacy PMO practices.  She had lots of questions about how Agile works in a Stage-gate approval process and client contract negotiations.  But what captured my attention most was her frustration over rework.  She said, “we recently had a situation where a client came to us with a half-baked idea.  Before we had finalized the requirements, IT went ahead and worked on something.  That led to seven rounds of rework before we finally satisfied the customer.  How would Agile have handled that?”  It is a good question, but the answer is about far more than just a process change.

Image Source: http://nakedpresenting.co.uk/f-is-for-feedback

Image Source: http://nakedpresenting.co.uk/f-is-for-feedback

Re-thinking Rework

The paradigm shift that Agile suggests is that rework isn’t bad.  That is a challenging concept to get your head around.  Let’s look at the woman’s example again and shift the language slightly.  “Our IT department responded to a client and showed them an option based on the available requirements.  Upon seeing the working software, the client was able to refine their request and provide more clarity to IT.  After seven iterations, the client was thrilled.”  Mind-blowing, right?  If we simply pivot our expectations, we might find that we can be more Agile in our approach to solving customer problems.

Agile and Product Mgmt – Year in Review

I committed this year to write 52 blogs and I did it!  There are 16 on my previous employers website and 36 on www.runyanconsulting.com.  As I look back and review and reflect on the posts, here are my favorites.

Product Management Blogs

I am very passionate about Product Management and I think it is sometimes an undervalued skill set.  Where I have a chance, I always try to share the strategic and practical benefits that come from having great product management resources.  This year, I wrote a five part series about how to Launch a Product and recently completed a 3 part series on how to sunset or decommission a product.

Image Source: http://www.greenbiz.com/

Image Source: http://www.greenbiz.com/

 

Agile Blogs

I am equally passionate about Agile because I have seen how it can improve people’s job satisfaction and raise the level of productivity and effectiveness for the whole organization.  This category was harder to choose my favorites, so I came up with four.  First, there was a series on creating an Agile Culture and what it really means for management.  This series generated some controversy, which I love because it means we are talking about important things.  Next, I am surprised that many organizations are not familiar with Fist of Five.  We use the Agile technique all the time and it is a difference maker in driving productive conversations.  Many organizations also  struggle with how to incorporate Agile into the day-to-day business, so I offered three options for incorporating bugs and maintenance into your Agile teams.  Finally, I am a big believer in the sacredness of the Sprint and I believe that organizations that are disciplined enough to honor a sprint commitment will typically be more successful than those who are loosey-goosey with the guidelines.

Other

Finally, I care deeply about leadership and family so some of my blogs were dedicated to those topics.  One that has been particularly fun is documenting our evolution to an Agile Family.  We have learned (and laughed) a lot together.  Also, I spent some time really thinking about Innovation and what drives an innovative spirit in some people but not others.  This particular blog might be my favorite of the year.

I hope you have enjoyed some of these blogs and maybe learned something new.  I know that I have learned with each post and I am grateful to have the opportunity to continue growing and exploring new ideas.  What is in store for 2014?  Who knows for sure, but it is going to be a great year!

 

Agile Family – A Recap

We became an “Agile Family” in 2013 and I first blogged about it in August. Since then, we have had a number of family meetings and we have learned some very interesting things along the way.  Here is a recap of our findings.

1. Face-to-face collaboration matters.

Those of you who are familiar with Agile and its principles know that face-to-face communication and frequent opportunities to Runyan_Familycollaborate are essential to Agile.  Turns out, the same is true with the family.  When we asked the retrospective-type question “What do you want to do more of?” our tween daughters (ages 11 and 12) said more family activities.  What?!? Our kids are at the age of boyfriends and texting and thinking parents are uncool and yet — they want to spend more time with us.  And when we inquired about the types of activities, it wasn’t watching TV or playing video games.  It was electronics-free hiking and bowling and ice skating.  You could have knocked me over with a feather when I heard that, but since then, we have become closer as a family – as a team.