Friday, December 28, 2012

Transparency - We weren't ready for that!

As many readers have experienced, working towards Agility is hard to do.

Many of us talk about technical details, process, C level executives, managers, change management, culture and a large variety of other things as to why becoming Agile is difficult for a corporation.


Perhaps the real reason is much simpler than we think --->  Transparency.


I believe it is possible that the reason Agility is tough to take in large corporations is Agile's approach to transparency.


Here are some examples (it is important to realize that in an Agile environment, all of the following examples might be very public within the organization).


  • The Product Owner does not know the value of the stories they are presenting to the team and the team rejects them.
  • The team realizes early on in a project that what they are delivering will give no value to the company and it becomes very clear the project has no ROI (Return On Investment).
  • The team cannot complete it's stories because it takes 3 weeks to get a user account on a server.
  • The team keeps track of interruptions and presents the information as a reason for losing 50% of their productivity (this doesn't include the cost of "context-switching").
  • The team reports that because of internal team member conflict (which they are working on), they estimate they lost 30% of this Sprint or Cycle capacity.
  • During the retrospective, the team has figured out that they have two senior level managers giving them opposing goals and report it as something they would like fixed.
  • The company is having problems with a product line and has reported to the team members they are losing market share.
  • There will be a corporate reshuffle and the team members are asked how they wish to re-organize themselves.
I know that there are many more examples that might come up for you.  Consider your own list.


I recall a comment from a previous customer who hit the nail on the head. He said to me after reading a published retrospective...  "We are not ready for this!"

I can't tell you how many times I've heard the phrases "Agile is about transparency", "We want transparency from the team", "We want to do Agile because we are looking for transparency".  Often the assumption is that the team is the one causing delays, acting improperly, slacking off, and the list goes on.  The common misconception is that transparency is only about showing what the team is doing wrong. 

Realistically, it is rarely the case that the team is the cause of all problems.  Of course, they may have some issues. That's part of being human.

What happens almost immediately during a new transition is that things start to become "transparent" and the real causes of delay start to appear.  This is immediately uncomfortable for people who weren't expecting it.  Perhaps in your case, the "transition" is only happening in one small part of the company.  Consider the effects of this transparency where it shows issues in other groups who didn't see it coming!

What can we do about this?  Why not warn them?  Why not give them some training and coaching?

transparency graphic
Why not be honest about the fact that the information coming out of the teams will at times be uncomfortable?

Please, take the opportunity to talk about Agile values in your corporations. If you do not know why Transparency is so vital, please seek out an Agile Coach, Mentor, friend.. Whatever it takes.


The Agile Manifesto has many references that would involve transparency such as "Business people and developers must work together daily throughout the project."  Previously, many problems would not have surfaced which this principle will expose.  

The Scrum Alliance Code-of-Ethics says the following ; "When we make errors or omissions, we take ownership and make corrections promptly. When we discover errors or omissions caused by others, we promptly communicate them to the appropriate individual or body. We accept accountability for any issues resulting from our errors or omissions and any resulting consequences."

OpenAgile has a simple idea about this. It simply indicates it's purpose as follows; "The purpose of OpenAgile is to create an environment in which people are free to express their true nature and capacities to contribute to the betterment of their organization."


By spending a bit of time on this, you can make your transition a bit friendlier.  Once people realize that transparency is expected and what it really means, the change will seem less frightening.

What's making it difficult for many corporations is that we haven't truly explained what will happen when information in the company becomes open and up front.

Remember, transparency is a two-way street!


by Mike Caspar
..........
References : 
Agile Manifesto Principles - http://www.agilemanifesto.org/principles.html
Scrum Alliance Code of Ethics - http://www.scrumalliance.org/pages/code_of_ethics

Sunday, December 2, 2012

Only one to choose - Choose the Sprint Retrospective or the Reflection and Learning Step of the Engagement Meeting


I've been finding this a recurring question for a while, so I thought I might share some thoughts on the subject.  People have been asking, if you can only do one thing from Scrum or OpenAgile, what would it be?

When deciding what the most important part of your Agile Framework is, think about the Retrospective (Scrum), or the Reflection and Learning part of the Engagement Meeting (OpenAgile).

This meeting is a focused way for an individual, team, community or system to improve through continual learning.

Many corporations who have adopted Scrum have started with procedural parts of Scrum such as the Daily Scrum or the Planning Meeting.  The teams "go through the motions", yet no significant changes are made to the way work is done.  Many team members simply don't grow as individuals this way.

Scrum's Retrospective Meeting is a meeting where team members focus on improvement of themselves, the overall system, or their processes.

Often, the results of the meeting are the discovery of system-wide obstacles. If adjusted, these changes will allow the team to work more efficiently.  Sometimes the meeting may simply expose friction between team members that needs to be worked on (not managed).

The OpenAgile Reflection and Learning Parts of the Engagement Meeting focus on learning about our environment, system, community, and each other. 

By focusing on increasing our capacity to learn, we allow ourselves to be open to new ideas and things to try in our global "system".  As a result, our ability to "be of service" to our community is significantly improved.

The words are slightly different but the idea is similar...

"Let's go back and look at the last period of time we worked together and learn from that.   Based on what we learned, we can do something different next time and see how that works out."  Improvement is incremental, not batched.


If you are a ScrumMaster, or Process Facilitator, consider doing things to make the Retrospective the most important part of your Agile Mindset.

This one simple meeting, has the ability to drive any framework, team, or system to improve quickly.  It also allows continual learning and improvement to continue.

If you really want to have some fun with the meeting as well, some self-improvements to consider includes reading Ester Derby's book, Agile Retrospectives: Making Good Teams Great or taking a course in Innovation Games.

For me at least, it's always great when this meeting is taken seriously by teams and by the company.  The leaps and bounds teams can make are incredible.  This is because they can quickly and easily see what new things they need to learn and what improvement they can make .. now.

Ignoring this important meeting is just way too slow.

by Mike Caspar

References : 

OpenAgile Engagement Meeting - http://www.openagile.org/wiki/Engagement_Meeting