A Path from Command and Control to Agility

Have you ever noticed a team where with little engagement, a lack of ownership, and team decisions are scarce?  One reason could be the amount of command-and-control from management that is occurring.  Often times this is one of those unspoken elephants in the middle of the room.   Command-and-control bosses are a sure way to kill the feeling of ownership, engagement, and empowerment. 

Agile comes along and promotes self-organizing teams, transparency, and team decision-making.  It also helps companies meet customers’ needs and adapting to the market conditions, ultimately leading to making more money.  Within an Agile culture, it no longer requires a manager to tell a team what to do.  The number of organizations following Agile continues to increase. They realize that they no longer need directive managers but leaders who act more as coach and mentor, then the traditional boss.  So what is a command-and-control manager to do?   

• If they feel they have command-and-control traits and are willing to make that move to Agile, they can test their comfort level with collaboration first.  When a team decision is needed, ask the team for their thoughts.  See if the command-and-control manager can be just one voice of the many that are on the team instead of forcing a direction.  If this works, next they can test their comfort level with self-organizing teams.  The next time there is a decision that impacts the team, ask they can ask the team to discuss it amongst themselves and decide the course of action.  Stand back and let them decide. 

• If they are inquisitive about Agile, provide them some education in the Agile values and principles space.  They should consider what they think each of the principles mean?  A bolder move is having them share the Agile principles with their team and ask them what they think it means.  Also ask the team members how it can be exhibited on a team.  Ask the team members if they think we would be a good idea to exercise some of the principles. 

• If you know they have directive tendency and their current role has them interacting with customers to understand customer needs, then they may consider becoming a Product Owner (PO) for the team.  While they should no longer be manager, a PO helps shape the product through the collection and grooming of the requirements.  The PO also shares the need with team members during the Agile-related planning events (e.g., Sprint Planning).   

So I will leave you with this question.  Which approach will lead to more productive and high-performing teams?   Is it a culture where managers tell employees what to do or is it a culture where employees are self-organizing and feel ownership of the work?   If managers and employees exhibit command-and-control tendencies, it is in their best interest in the long run to adapt toward and Agile mindset and allow for self-organizing teams.  Since Agile is pervasive in many companies, it is an opportunity to adapt and help the organization.  

Scientists Find evidence against Big Bang and for Continuous Adaptation of the Universe

The earliest phases of the Big Bang are subject to much speculation.  In a new revelation by leading Quantum Scientists from CERN, they surmised that the universe had used more of an adaptive approach. In re-investigating Vesto Rugby's study that measured the first Doppler shift of a spiral nebula, they found evidence that an adaptive approach was used to in the expansion of the universe. 

Further investigation found the singularity known as Big Bang, was really a series of cosmic inflations that align with a plurality approach that caused the universe to iteratively unfold.  While initial observations best fit the theory of Big Bang, after the discovery of cosmic microwave radiation, this promoted a continuous epoch approach where spectral waves align much more clearly with an adaptation of wave expansion. 

This came to the attention of the Agile Alliance.  They are now backing the scientists and aligning with the newly termed Continuous Adaption theory of the universe.  They recently supported the Evolution of the Species Theory promoted by Darwin.   The Agile Alliance says continuous, adaptive, and iterative are all components of Agile and now believe that Agile is really the essence of the universe.  The Alliance is now in funding NASA and CERN research in their Agile endeavor.    

April Fools...

Do you bring the “Semper Fidelis” mindset to your Agile Teamwork?

When I think of a strong example of an Agile team, I recall teams that would help each other out, would watch each other’s back, and would focus on the project at hand, working strongly in a collaborative manner to achieve the common goal. 

Interestingly enough, this is what it takes to achieve the ideal Marine mindset.  Semper Fidelis is Latin for “always faithful” and has been the Marine motto since 1883.  This motto guides the Marine to remain focused on the mission at hand and stay focused on each other as part of the unit, as part of the team.  The intent is that once you commit and become a Marine, you transform to something new, something better, where you don’t worry about yourself.  Instead, you worry about the guy next to you and to the success of the mission.  You live a life with personal integrity, courage, determination, and commitment.  These are the same attributes that make a member of an Agile team successful. 

   

Another mindset within the Marine leadership is “to lead by example”.  In Agile, we don’t need people telling us what to do.  We need people who lead by example and who live the Agile mindset.  This is the best way for the team to absorb what is expected by the Agile values and principles and is another way to grow.  

If you want to learn about the importance of teamwork, spend a moment learning about the mindset of a Marine.  As I would illuminate the attendees of my numerous Agile workshops, one strong attribute of teamwork is “no one succeeds unless everyone succeeds.”  Agile team member should bring encouragement to each other, integrity to do what is right, courage to challenge the bad habits, and commitment to see the work through.  This is teamwork and beyond.    

You may be FrAgile if...

Moving to the Agile can be challenging.  It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto.  However,  many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues).  This may be because there either wasn't a commitment to go full Agile, there wasn't an understanding of what that an Agile method entails, there wasn't the talent like an Agile Coach to help bring about that change, or there was an incremental Agile deployment approach which stalled along the way.  

When "Fragile" happens...

Some may ask, “why do I care if Agile is not quite right”.  When a form of Fragile is applied, you will not gain the business benefits of aligning better with customer value and the many other benefits Agile can bring. When you see that you are not gaining the business benefits of Agile, instead of blaming Agile, look to see how you have implemented Agile and whether you are really aligning with its values and principles. 

In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article.  I present several areas which can be problematic if they are not in place and you are serious about Agile.  So without further ado, "You may be FrAgile if": 

• ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail.  The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.  
• ...you continue to have the Project Manager or Functional Manager assign the work to the Team.  The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.  
• ...you continue to collect your requirements upfront and lock them in for the remainder of the project.  The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it. 
• ...you do not want to have a healthy balance of test/QA minded folks on the team.  The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.  
• ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.  

Let me know what you think about the results of "You may be FrAgile if".  If you believe there are other Fragile, Scrumbut, Scrumfall, Kantban, and other related Agile challenges that could be non-starters or significantly impact the ability to "be Agile", please feel free to share.     

Benefits of Agile Coaches/Agile Enterprise Leadership team for introducing Agile Cultural Change

Many companies begin their introduction to Agile by trying it on a project or two.  If they believe they have ‘enough’ success with Agile, then typically more projects deploy Agile.  The challenge is that at some point the company is unclear on what level of Agile deployment has occurred and what type of Agile is really being adopted.  Senior Management may hear things like “we are Agile” and not really sure what that means.  Worse yet, because of the inconsistency of understanding Agile, some teams will say things like, “we don’t need to document anything because we are Agile”, other teams will say “we don’t need any management support because we are self-organized”, while others will say “we can’t tell you what we’re building until the end of the project because we are using Agile”.  Now what do you do? 

This becomes even more challenging when the company begins to realize the amount of money they are spending on Agile adoption.  Sometimes the company learns that they are spending twice for the same thing like training and/or tools and often overspending because they are not leveraging the volume discount strength of the whole company.  This is particularly relevant to medium and large companies.  

Whether you realize it or not, when you have multiple product teams heading in roughly the same Agile direction, you have already embarked on an organizational change.  So the question is, do you want to let the change occur in an unorganized and ad hoc manner or do you want to manage that change in an organized way and gleam the most benefit from the effort.

While I do not believe there should be a prescriptive way to deploy Agile, I do feel strongly that much like a product level Agile deployment should strive for simplicity (per one of the principles that support the Agile Manifesto), so should an enterprise level approach.  This ensures that the company reduces the muda (a.k.a., waste), leverages and reuses what it can, and ensures a consistent framework for understanding Agile.      

When you find yourself in the situation where there are many in your company wanting to adopt a certain tool, process, method, and/or culture, or if it is already happening in an ad-hoc manner, it is highly recommended to initiate a centralized approach to the organizational change.  In Michael Spayd’s “Evolving Agile in the Enterprise: Implementing XP on a Grand Scale”, he recommends that an “effective Change team” is established.  In my experience, seasoned Agile Coaches and/or an Agile enterprise leadership team provides significant leadership for the change effort.  The Agile Coaches/Agile leadership team (aka, change team) provides the framework for the organization but still allows for adaptability and decision-points by the teams so they feel ownership of their working process.

The Agile enterprise leadership team should include talent that has experience in Agile enterprise change such as seasoned Agile Coaches and those who have organizational level change experience.  Some members can be matrix-ed in from internal organizations.  They should function as a team and can be distributed according to the areas within the organization that they will support.   It is often best to bring in either full-time regular talent or external long-term consultants to ensure that they don’t just make recommendations, but live through the challenges of the change as they help product teams, senior management, and others.

What are some of the benefits of Agile coaches and/or Agile enterprise leadership team?  This leadership can help you establish and manage the following: 

• Agile Deployment Roadmap - identify common activities to help a product team come up to speed with Agile.  This includes establishing a set of “ready for deployment” materials to help teams get ready for the change to Agile.  By having central Agile leadership construct this, it will save time and effort from each product team having to figure out the adoption activities themselves
• Agile framework and practices - collaboratively establish an adaptable set of Agile methods and practices with the rest of the organization.  By having central Agile leadership coordinate this, it will save time and effort from each product team having to establish Agile methods and practices, although they will need to tailor them for their specific team. 
• Agile terminology – establish a common working language for Agile so that members from across the organization can communicate and interact effectively with each other.  By having central Agile leadership establish this, this reduces the miscommunication issues that will arise across the organization regarding various and sundry definitions of Agile terminology.   
• Agile training – establish a common set of Agile Training aimed at various levels of the organization (e.g., Scrum Team, Scrum Masters,  Product Owner, Middle Mgt, Senior Mgt).  By using a managed training deployment approach via the central Agile leadership team and education group, we will have consistent training and can get a better understanding of who has and hasn’t been trained.  By providing an in-house training approach, this reduces the cost of utilizing multiple vendors.  This increases common Agile understanding across the organization and product teams.
• Agile Communities – establish a common organizational Agile website with links to internal and external Agile communities.  Having the central Agile leadership team establish and support this, ensure that there is a managed approached to sharing online Agile related information and resources (framework, practices, etc.) across the company site that is kept up-to-date.    
• Agile Coaching - A key aspect of the leadership team is to provide Agile Coaching via the Agile leadership team to projects/product teams across the enterprise.  They may start with a small core of dedicated Agile Coaches and then can leverage existing Agile talent across the enterprise in establishing an Agile Coaching Circle.  Coaching significantly reduces the effort involved with “correctly” getting a team to adopt Agile and more importantly ensures they do not regress into their old traditional habits.
• Agile Vision - create a vision for why we are applying Agile.  This may include something like Focus on the Customer to build the right thing and on the Employees to build the thing right" or similar.  By having a central Agile leadership team construct this, it can be used to gain buy-in or at least get folks to understand why we are doing this (at a very high level).   
• Agile Adoption measures – establish a common and reasonable set of adoption measures to see what progress is being made in the Agile adoption within the company.  By having the Agile leadership team manage this, we have common adoption measures to ensure that the leadership team and product teams are meeting the organization objectives for Agile adoption.  Senior management can more readily get a pulse of the Agile status across the organization.
• Agile Challenges Point of Contact (PoC) – establish a central point to manage Agile related challenges and issues.  This would include website, email PoC and the establishment of an Agile FAQ.  The benefit to having a go-to centralized Agile leadership team to manage this is that they can both become aware of these issues and then resolve the issues and challenges before they cause an impact.
• Agile Vendor Liaison PoC – utilize the Agile leadership team to become the PoC for managing the company relationships with the various Agile vendors.  By using a central Agile leadership team ensures that the organization or company is gaining the most leverage from the volume discounts and negotiations for Agile related materials and tools.  

Finally, when employees within a company see that many are going Agile, sometimes it is comforting to see that the organization is providing support in the adoption effort.  It is even more comforting when those employees that haven’t yet gone Agile see that there is ready support for their deployment.   It is particularly problematic when the employees are seeing wide variations of “agile” being deployed some of which is not really Agile, and they wonder when the organization may provide some guidance in this matter.  Introducing Agile really is a culture shift.  If you are thinking about adopting it or already are, then it can be a benefit to have Agile Coaches and/or a centralized Agile leadership team to help you navigate to a success adoption of Agile.  

Good luck on your Agile adventure!

Note: this was originally written in 2008 with minor updates in 2012.    

When the term Scrum moves into Politics and Media

While it is commonplace to see the term “scrum” in either Agile circles or when discussing the sport of Rugby, I have recently noticed that the term scrum is being used in political and media circles more and more (see three recent news articles below).  While I suspect that the usage of scrum is really coming from those familiar with Rugby, I wonder if there are those in the media or politics that have an affinity with those who work in Agile and Scrum related circles?  What do you think?

• Senate in last-minute scrum for deal - http://bostonglobe.com/news/politics/2012/12/30/senate-leaders-scramble-find-formula-avoid-fiscal-crisis/tCAbkkZhesZD5cq5vdN7BJ/story.html  - Dec 30
•  Judges scrum over 'double-dipping' for pension  - http://news.cincinnati.com/article/AB/20121224/NEWS010801/312240014/Judges-scrum-over-double-dipping-pension - Dec 22
• Chinese Media Digest includes the statement, "This media scrum should not develop into a political show" said the article..." - http://www.globaltimes.cn/content/752191.shtml - Dec 25
• Media scrum is now a Wikipedia entry - http://en.wikipedia.org/wiki/Media_scrum 

Scrum

It would be interesting to see if more and more Scrum and Agile related terms become infused into our political, media, and other lexicon.  In any case, I wish you all a very happy and successful New Year!

Cheers to one and all!

The Importance (or not) of Agile Terminology for an Agile Culture (with Polling Results)

I have noticed in my experience in helping teams transition toward an Agile culture that moving away from the traditional terminology and adapting Agile terminology is very beneficial.  At the same time, I have sensed reluctance in organizations in removing from their traditional terminology.  I believe the language we use matters a great deal if we are attempting to achieve a certain culture. If you are trying to change culture, the change in language highlights that something has changed and provides folks with an learning opportunity assuming that there is true meaning behind the terminology and a commitment to change. It makes us pay more attention. If you think about it, when we travel from one culture to another, the language does indeed change.  Using the proper language helps us inform and communicate our needs more effectively while a common language provides a bond within our community.

Maybe the key is to use language that is most efficient and effective for the culture you want to get to. If you want to change your culture, you need to ensure that the language is not tripping you up and dragging along its baggage of prior meaning.  When you move from a Waterfall to an Agile culture, using the same waterfall language will trip you up in most cases. Why? Because the folks in the organization still think the definition of the term is stemming from the 'old' culture. Attempting to change culture is hard enough and when you have language from the old culture still around, you can be sure that those people within the org are still interpreting the language using the old world context. This can impact your success to advance your new culture. 

With all of that being said, this is the opinion of one person.  So what of the opinions’ of others?  With that in mind, I embarked on a poll via LinkedIn to gauge other’s thoughts on how important is it to use Agile terminology to get to an Agile culture.  I present you with the following results:

Within a period of a month, there were 83 votes cast along with 26 comments.  The poll results revealed that 65% percent (or close to two-thirds) of the participants felt the use of Agile terminology was either ‘Very Important’ or ‘Important’ for an Agile culture.  Another 12% felt it were neutral.  The remaining 23% felt that the use of Agile terminology was of ‘Little Importance’ or ‘Not important at all’.

In order to more fully understand other opinions, I have included a paraphrasing of some of the comments.  They include: there is a need for specialized vocabulary; there are fundamental differences amongst various practices and methods so terminology should be considered; the terminology contributes to language precision; and the words used should work for the culture.  You can see one of the threads within the “Agile” Linkedin group for specific comments from others.

Some took my examples literally.  I didn’t really mean to imply that the term ‘sprint’ and ‘phase’ are the same, but I have seen teams use those terms interchangeably.  So I do agree that one term is not necessarily better than another but that you should ensure the language you use does not get in the way of learning and advancing within your culture.   Also, I’m not clear that there needs to be a standard “Agile” terminology across the industry.  However, with that said, if you are doing Scrum, you should strongly consider using Scrum terminology (and the same for XP, Kanban, etc.). And there is a value of having a common Agile terminology within an organization so that there can be a more effective platform for Agile related discussion across teams.   

Also a few people mentioned that the meaning is more important than terminology.  I do favor this line of thinking because there should be an effective meaning behind all terminology used.  Terminology without meaning is babble.  So yes, it is important, dare I say critical to have a well understood and clear meaning behind all the terminology used in order to gain an effective Agile culture. 

Ultimately if you are truly trying to initiate a culture change, then the language, IMHO, should reflect the change you are looking to make.   In this case, if want to establish an Agile culture, utilize the terminology that provides an appropriate and clear meaning which drags little or no baggage.  This will help you get to the Agile culture you may be seeking.

Cheers!

Note: another article that discusses Agile terminology focusing on the terms 'size' vs 'estimate' may be found at: http://cmforagile.blogspot.com/2012/10/size-matters-using-size-instead-of.html