In Agile, do not let “Fast” be your Driver

If your primary focus of using Agile is to build a product fast, then you may be missing the point of Agile.  Agile values and principles guides you to build the most valuable software based on the needs of the customer with high quality and in a timely manner.  Notice I did not use the word “fast” but instead I stated that it should be provided in a timely manner per the needs of the customers.  While building it fast can help you fail fast, "fast" should not be your primary drive and imply less focus on quality and adapting to the needs of the customer.  

Building the wrong thing fast is like driving a dragster that races off the motorway when the road twists and turns as they often do.  Instead an Agile racing car is like a Porsche Turbo that has great suspension, performance, quality engineering, and handling that can handle the twists and turns of the road.  The twists and turns represent the changes in customer requirements.  Also building a product fast with poor quality does not help the customer or your business in the long run. 

If you really strive to build customer value, then you need an Agile values and principles race car that will help you deliver what the customer wants, when they want it, with high quality.  If you can do this, then they will buy the product or more of the product, increasing the likelihood of remaining loyal to you, and helping you grow your business and they receive value.    

What happens in the Retrospective stays in the Retrospective!

The Sprint Retrospective is the last event in Scrum occurring at the end of the sprint.  It is a private and safe session for Scrum team members only and facilitated by the Scrum Master. It is used to identify what went well, what did not go so well, and what can be improved.*  It is important to discuss what went well so that you can celebrate successes and when the team feels certain things are going well. 

A sprint retrospective promotes continuous team improvement.  The areas that did not go so well are rated by the team as to which were the most problematic.   The team takes the top 2 or 3 of these problematic areas and identifies the root cause.  Root cause analysis ensures that the real challenge is uncovered so the team crafts a solution that will resolve the problem.  An improvement action is established for each problematic area. Then the team commits to a couple of these improvement actions to be worked on in the next sprint. 

The retrospective is an opportunity for the Scrum Team to reflect on the past sprint’s activities including team dynamics, processes, tools, and culture.  It supports the Agile principle of self-organizing teams.  In order to really get to the nitty-gritty of the problem areas, sometimes “dirty laundry” needs to be discussed. This includes taking a hard look at the problems.  

In order for the team to feel comfortable in airing problems, the team needs to feel that they can trust each other.  Team members must believe they can discuss problems knowing that anything said will stay in the room.  If what is discussed in the retrospective gets communicated outside of the room, folks on the team will be less likely to raise and discuss problems.  And discussing and resolving problems is what the retrospective is all about.  This is why it is important to discourage outsiders, particularly any managers of the team members from attending these sessions.  When outsiders attend, you often see far fewer real problems get raised.  Outsiders may not understand the context of why a team made a decision or did something a certain way which can lead to inappropriate judgments.

The retrospective only has value when the team discusses problems in a sincere manner, has a safe environment to discuss problems, and provides a strong commitment to resolving the problems to the benefit of the whole team.  So keep all of this in mind when you hold a Sprint Retrospective and remember, what happens in a retrospective stays in a retrospective!

* An alternative approach is to discuss what we should stop doing, continue doing, and start doing.  

Right-sizing Documentation in an Agile World

Within an Agile context, there is a focus on right-sizing documentation.  This is a response to the bureaucracy that has led to large volumes of project and product documents which are often left unread, are out-of-date the moment they are complete, and seem to have little value to the team.   On the other hand, I have heard folks who are in an Agile context say that no documentation is needed.  The truth is somewhere in between.    

One of the values in Agile is “working software over comprehensive documentation”.  This does not mean that there is no value to the item on the right, but there is more value to the item on the left.  The key is right-sizing the documentation.  Right-sizing means that the level of effort applied to write and maintain the documentation plus the value of that written document should have a greater return on investment (ROI) then not having that information readily available (i.e., the effort it would take reconstruct the information and impact of not having that information for current decisions).   With that in mind, here is some high-level guidance on right-sizing documentation. 

• Documentation should be living and evolutionary and not “sitting on the shelf”.   Move away from the notion that document is “final”.
• Consider some documentation to live at the product level where it may naturally evolve from both sprint to sprint and from release to release. 
• Documentation should take on a collaborative nature.  It should not be written by one person to perfection, and then shared with others.  It should instead be shared often during draft to gain input   
• Update your documentation continuously as new things are learned.  If you learn something that can impact the team or help with decision-making, go to the document and update it. 
• Focus on just barely good enough documentation and avoid big upfront details which typically means a lot of guessing and wasted time.   Barely good enough means document what you currently know.  If you no longer need the document, it is reasonable to retire it. 
• Be concise and lean.  Write in succinct prose and add bullet points if reasonable.  Avoid long and flowing prose which may lose the reader’s attention.
• Documentation can take many forms.  It is not only a Word document, documentation can live on a wiki, in the Agile planning tool, as comments in code, and much more
• Document decisions.  Knowing the decisions helps those who must maintain the product and understand why things were decided or done in a certain way.   
• Realize that there is a difference between internal and external documentation.  External documents may be a User Guide or document that gets delivered to the customer.  These should be considered as “working software” and follow the rules of the done criteria.    

What might get documented in an Agile world?  The major documentation comes in the forms of user stories and epics.  This includes writing the user story in canonical form, with details, and acceptance criteria.  Technically, another significant form of documentation is the code itself. It should be written in team agreed coding standards with appropriate comments that specify what the code does (or simply and clearly enough that don't need explanation) and why it was written a certain why.  Remember that code needs to be maintained so if someone has to "figure out" what you wrote and why in order to support the code, then it is problematic.

You should consider lean versions of your architecture, coding, and test strategies that help inform the team of ways of working. Impediments that require effort to fix should be documented.  Items such as coding standards, an overview of your working processes and policies, done criteria such also be documented and shared. 

What do you think of this guidance?  Do they make sense?  Do you have any other tips?

A Path from Command and Control to Agility

Have you ever noticed a team where 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 and leaders are a sure way to kill the feeling of ownership, engagement, and empowerment in team members. 

Agile comes along and promotes self-organizing teams, transparency, and team decision-making.  It also helps companies bring more value to customers and adapt 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, consider an experiment.  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.  Better yet, see if the manger can remain quiet and let the team arrive at a decision.  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 the manager is inquisitive about Agile, provide them some education on the Agile values and principles.  They should consider what they think each of the principles mean and if they believe in them.  A bolder move is having them share the Agile principles with their team and ask them what they think it means.  Also they can 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 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).   

• Learn about the concept of bounded authority.  This is where the team can make their own decisions, organize, and commit to their own work.  It does not mean that teams can do whatever they want.  The balance is that the manager keeps limited responsibilities to provide vision and support for their staff while allowing the team the ownership to self-organize around the work.  

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, feel ownership of the work, and are able to use much more brain power?   If managers 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 toward better business results.  

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 Fi” 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). 

What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.    

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.