Tag Archives: scrum

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.

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.

Agile Culture: Management and Teamwork

When it comes to implementing Agile, managers who are used to a “Command and Control” environment are going to be very uncomfortable.  Now, let’s be honest, Command and Control managers are not all bad.  They typically feel a high degree of accountability and that is a great thing.  They feel like their neck is on the line so they want actions to be done as they command so that they can deliver.  But what they fail to benefit from is the wisdom of the team.

Image Source: http://buzzardnbigdog.com/?p=3131

Image Source: http://buzzardnbigdog.com/?p=3131

The Power of the Team

Think about your team or colleagues.  Who has long tenure and has ‘been there, done that’? Who is a relative new hire who may have relevant experiences from a previous employer?  Who has worked in several different departments? Who has worked in several different roles?  Each of these unique traits means that an employee might bring a unique perspective that the manager would benefit from, if they were willing to listen.  Albert Einstein has famously said “we cannot solve our problems with the same thinking that we used when we created them.”  Our employees have great ideas and many welcome the opportunity to creatively solve the problems of the business.

Members of management – manager, director, VP, whatever – should present the team with the problem or opportunity and let them ‘self organize’ to determine how they will solve the problem with teamwork.

Agile Culture: Management and Trust

I recently led a discussion on the impacts of Agile on the culture of an organization.  I shared that if your company is undergoing an Agile transformation and you aren’t uncomfortable, then you aren’t stretching enough.  Agile is uncomfortable.  It is awesome and the positive impacts on productivity, collaboration and customer and employee satisfaction are profound.  But getting there can be bumpy.  This blog is dedicated to the subject of trust and how it plays out with management.

Trust and Teenagers

trust-230x300

Image Source: http://www.webapptesting.com/trust-no-one-who-doesnt-localize-their-apps/2012/08/

A good analogy on trust is college freshman.  If anyone has sent away a child, niece, nephew or neighbor, then you know something about trust.  When we send our loved ones away to a land of temptation with minimal supervision and high expectations, we have to trust them.  How do we do that?  Well, hopefully a number of factors are working towards the positive.  We hope the following about college freshmen:

–          They have a strong foundation

–          They are smart/intelligent

–          They are capable of learning from their mistakes

If an 18 year old has these qualities, they will probably fare well in their new environment.  They have a foundation of values and experiences that will influence their decisions, they are smart people who can navigate through new experiences and if they do make a wrong turn, they can learn from their mistakes and course correct.

So why is it that we are able to trust immature and hormonal teenagers but we cannot trust our employees?  Are the same factors not also true about our employees?

Introduction to Agile Textbook

It is real now.  Our Agile textbook is advertised on the Pearson Higher Ed website.  How cool is that??  After many long months of writing, editing, revising, writing more, researching and writing even more – it has become a reality.

Many more details to come but I had to get the news out because it is so exciting!!!

open_book

Image Source: http://vixstar1314.wordpress.com/2011/03/19/closed-book/

 

Handling Bugs and Maintenance in Agile

One question that comes up often when teams are exploring the transition to Agile is how they are going to handle bugs or maintenance issues.  This blog will outline three scenarios that have worked for teams.

1. Building time into the Sprint

Image Source: http://www.asrintl.com/?page_id=310

Image Source: http://www.asrintl.com/?page_id=310

Perhaps the most common way that teams deal with unpredictable bugs and maintenance issues is to reserve some time for them within the Sprint.  For example, the team can handle 40 story points per sprint, but they only commit to 35 points, so they will have some time available for the unplanned bugs that need immediate action.  In some sprints, the bugs may account for more than the allotted 5 points and in other sprints, they may be less but on the whole, the team learns their rhythm and builds in enough reserves to handle whatever may come up.

Managing Conflicts in Agile

helping-hand

Image Source: http://www.reachingout.me/general-stuff/

Moving to Agile or Scrum introduces a lot of change and that can lead to conflicts in an organization.  There are a number of key factors to consider when managing those conflicts so that they are resolved quickly and collaboratively.

1. Level Set on the Goals

Here is a common scenario that we see in Agile.  The development team is frustrated because the Product Owner doesn’t have all of the answers and the Product Owner is frustrated that the developers ask for everything before they will work on anything.  Does this sound familiar?  In this scenario, we need to get back to basics and remember our main goal.  We want to deliver working software that adds business value as quickly as possible.  Both the development teams and the Product Owner share this goal and we need to remember that.  No product owner is knowingly going to withhold information about the marketplace or the product and no development team ever plans to write crummy code.  We all want the same thing, we just have different roles in how to achieve that.  So if you find yourself at a stalemate, think back to the original goal and realign on that.  It can really help to get everyone back on the same page.

Scrum Meetings

There are a handful of meetings that the Scrum Methodology includes as part of the cadence and this blog addresses each one and why they are important.

teamwork

Image Source: http://silenced-no-longer.blogspot.com/2012/11/a-revelation-putting-together-puzzle.html

Sprint Planning

The first meeting is called Sprint Planning and this is a two-part meeting.  The first part is  where the Product Owner has the opportunity to clarify and answer questions regarding the highest priority items in the backlog.  The Scrum team and Product Owner then set the Sprint Goal by deciding which stories will be included in this Sprint.  This is sometimes referred to as the “What” part of the meeting when we determine what we are going to build.  The second part of the meeting is for the Scrum team to discuss the individual tasks that will be required to execute the stories and any technical considerations or dependencies.  This is referred to as the “How” part of the meeting when the Scrum team decides how they are going to accomplish the what.  The team also usually picks the tasks that each individual is going to work on and estimates the amount of time that each task will take to complete.

Agile: The Power of the Fist (of Five)

There is a concept in Agile called Fist of Five.  The notion is simple – when you come to a decision point and you need to make sure everyone is on board,  you ‘vote’.  Agile is all about transparency and Fist of Five is one method to reinforce it.

Image Source: http://nicosteyn.wordpress.com/2011/01/12/5-rules/

Image Source: http://nicosteyn.wordpress.com/2011/01/12/5-rules/

We do it like the game “Rock, Paper, Scissors” where everyone shows their vote at the same time.  One – Two – Three – Shoot.  In theory, this is supposed to keep people from being influenced by their neighbor, but honestly, we think it is just more fun.

The voting works as follows:  A team member will propose a direction forward and the team will demonstrate their acceptance by holding up their hand with the number of fingers that corresponds with their level of support.

5 fingers = I am all in.  I completely agree.
4 fingers = I buy into the option and I will support it.
3 fingers = I may have some reservations, but I can support the decision and move forward.
2 fingers = I have reservations and I cannot support this decision without further discussion and clarification.
1 finger = I cannot support this direction.  I disagree.