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.

Five Reasons why you are lucky

There are times when we all feel a bit beat down by life or circumstances, so this is a blog to explain five reasons why you are lucky – or blessed.  I know what you might be thinking – this blogger doesn’t even know me.  How can she presume that I am lucky?  Let’s examine five reasons.

Image Source: http://www.examiner.com/article/four-leaf-clover-and-st-patrick-s-day

Image Source: http://www.examiner.com/article/four-leaf-clover-and-st-patrick-s-day

1. You are smart.

We can discern this fact – and yes, it is a fact – because you can read.  Only literate people read blogs AND you are smart enough to navigate the internet to find this blog AND you are smart enough to have access to a computer.  So if you are doubting yourself or your worth, know that you ARE smart.

2. You live in a country that has freedom.

The fact that you are able to access this blog means that you live in a country that allows its citizens to share controversial ideas and to learn and grow from different opinions.  That is a beautiful thing that is worthy of celebration.  You are lucky to be afforded such freedom.

3. You are interested in learning.

The act of wanting to expand your horizons, to learn new things and to explore differing points of view is a gift.  You are engaged in life and that is a great thing.  There are people who have given up, who are jaded or uninterested and feel like their best days are behind them.  You are not that person.  By virtue of the fact that you are interested in internet musings means that you are an active participant in this life and good for you.  That zeal makes you a lucky person.

Sunsetting a Product: Pricing

It may sound odd that you need to consider pricing when sunsetting a product or platform but you do – at least in some form.  This is the final installment in a series on decommissioning or sunsetting a product.  First you must get data to know exactly what the situation is; second, you must craft your communication plan, and finally, you need to consider the financial implications.

Refunds

If you are truly turning a service off, or ‘going dark’, you may have to consider whether refunds will be required for your existing customers.  If your business model is one of pre-payment, then you need to look into contractual obligations, notice periods and financial true-ups.  The potential impact of refunds may even dictate your sunsetting strategy, so you can minimize pay outs.

Let’s consider an example.  The company charges annually for the following year.  For example, on November 1st, you are charged fordollar_sign2 November 1st to October 31st of the following year.  The company will need to research the month with the highest number of renewals and you might base your decommissioning date based on that information to minimize the refunds.  If sunsetting this product is a large and complex effort, you might consider a rolling project where customers are moved off of the product or platform as their services expire contractually.  This approach can take up to a year to complete, but that might be ideal in certain circumstances.

Sunsetting a product: Get Data

As a Product Manager, one of the efforts that we are often asked to consider is the decommissioning or sunsetting of a product or platform.  It is not always a fun task, but it is very important to the business.  This blog series is dedicated to the steps that a strong Product Manager needs to consider when researching this kind of issue.  The first and most important thing to do is to get data.

If ever there was a project that should NOT be executed based on gut feel, this is it.  You need data to make sure you make the most sunsetprudent decision possible.  There is no way to sunset a product without upsetting some aspects of your business, so this is not something that should be taken lightly.  What kind of data do you need?

Customer Analysis:

You need solid data from the financial and CRM systems of the company to answer the following questions:

  1. How many customers are impacted?
  2. How important are those customers?
  3. What other services have they purchased?
  4. What prices are they paying?
  5. What is their lifetime value?

Agile Culture: Impacts to the Organization

In previous blogs, we reviewed the implications of adopting an Agile Culture on management – learning to trust the teams, understanding the new aspects of teamwork and the reality of more transparency.  In this blog, we are going to address the impacts to the organizational structure.  Jim Highsmith, one of the original signers of the Agile Manifesto recognizes the evolution of organizations and has presented a webinar titled “Stop doing Agile.  Start being Agile.”

ChangeWhen we think about that phrase – to start being Agile – we have to dig deep into our culture and organization to truly examine how things currently are and how they ultimately should be.  What we typically find when we start coaching an organization is that they are open to fitting Agile into their existing structure.  But that isn’t enough.  There has to be a willingness to abandon the existing structure in favor of one that is truly Agile.  This is a much bigger shift and much harder to accomplish and in many cases (unfortunately) this is where Agile implementations are compromised.  Let’s look at some examples.

Agile Culture: Management and Transparency

Image Source: http://en.wikipedia.org/wiki/Transparency_and_translucency

Image Source: http://en.wikipedia.org/wiki/Transparency_and_translucency

This is a blog series about the impacts of an Agile implementation for management.  We have already discussed trust  and teamwork, and this post is dedicated to transparency.

Transparency for the Team

People that move into Agile (or Scrum) team typically experience a dramatic increase in their involvement in the business.  They have access to more information and they are participants in conversations that would have excluded them in the past.   The team members now see more of the Product Vision or Roadmap than they ever have before.  They probably have a task board where they can see which tasks are in which state.  They should be having a Daily Stand-Up meeting where the team learns if anything is standing in the way of progress for their development effort.  They are now included in conversations about scope and timing and release planning.  Thus, from the team member’s perspective, transparency has increased exponentially.

This is not necessarily true for management.  When you have a team that you trust and that is working together, the transparency for management might actually decrease in some ways.  As a manager or Director, you will no longer know everything that is happening on your teams in an Agile environment for two main reasons.  (1) You trust the teams to work together to deliver so you no longer micro-manage them and (2) Because of the trust and teamwork, more things are happening than ever before and it is much harder – and unnecessary – to stay on top of everything.