Tag Archives: team

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 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?

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 Examples – The Scrum Team

This is an excerpt from the textbook that I am writing with a co-author on Agile.  Here are examples of a strong and weak Scrum Teams.  Would love to hear your thoughts and comments.

Strong Scrum Teams

The green team has a team member who is wicked smart, so much so that the rest of the team has trouble keeping up with him when he gets going on an idea.  He is almost always right in his direction but he processes information in his brain so quickly that when he talks, it is a bit like gibberish to the rest of the team because he doesn’t clearly state how he got from problem to solution.  On some teams, this type of savant could be extremely frustrating because when he talks, the team rarely understands what he is saying.  But the green team is a highly effective team and they recognize and value the intelligence and ideas of their super-smart colleague.  So they brainstormed the right way to allow him to communicate his ideas and thought patterns.  They painted all of the walls in the area with whiteboard paint which allows you to write on the walls, from floor to ceiling, and then erase it when you are done.  They encouraged their team member to write down the train of thought that his brain was making in solving a particular problem.   This allows the rest of the team to slowly digest what their colleague is conveying and they have a written record to access when they are trying to recall a specific detail.  The green team rallied together and found a solution that would allow all of their team members to actively contribute and drive towards the best possible solution.

Not so Strong Scrum Teams

The blue team is not optimized.  They have a member who is equally talented but far more disruptive.  This individual is negative and not a team player. Every idea that isn’t his own is stupid and anyone who doesn’t like his ideas is stupid.  He is very intelligent and knows the system very well so his behavior is tolerated even though he is so negative.  The sense is that the team could not do without him because of his expertise.  His presence has created a work environment that is tense and unproductive.  His team members are reluctant to confront him because he is so aggressive in his negative demeanor.  The issue of his attitude has been raised with both the Scrum Master and the IT Manager but neither are willing to address the problem because they fear losing his expertise on the system.  So this team operates in a constant state of fear. They do not know how this individual will react in any situation so they all retreat and wait for his reaction before they express any opinions of their own.  The team is failing to meet any of its deliverables because no one can commit to certain tasks when the bully on the team is driving all of the discussions and undermining the whole Scrum practice.  This is an ineffective team who would be far better off if the dominant individual was removed from the team.  They might suffer a bit from the lost expertise but they would gain far more by being allowed to brainstorm and work together.

Want to read more?  We have examples for Product Owners and Scrum Masters too.