Agile’s Little Secret – It Makes You Money

Agile tends to be introduced at the team level and it’s the Agile teams who are expected to adopt Agile.   While there is various amounts of buy-in from management, some don’t seem to understand that it takes an organization to embrace Agile in order to gain the business benefits.  In other words, management has a strong role to play including adapting their behavior, embracing the Agile values and principles, and leading a culture change, in order to gain the business benefits of Agile.  It requires significant buy-in to achieve a culture change.  But this doesn’t always seem to happen. 

Some of this is not management’s fault.  Part of the issue is that Agile gets introduced to them is various ways – as a way to improve productivity, as a way to speed up development, as a way to increase quality, but in most of these cases, those introducing Agile to them fail to mention the significant buy-in they need to make.  While each of these ways have different levels of merit, it often doesn’t convey enough of a reason for management to motivate a change in their behavior and their organizational culture.    

   

How about changing the message?  Though there are many benefits for going Agile, it occurred to me that to get serious executive/senior management attention and buy-in to Agile is to give them a reason that is near and dear to their heart.  Explain to your management that Agile can increase revenue—in short, it can help them make money (or more of it).  In my experience, this gets them to actively listen, versus the passive listening they may exhibit when they think Agile is an engineering method or something the engineering team and others must do.

Yes, Agile can lead to an increase in customer sales, ergo an increase in revenue. This is all true if the organization is truly allowed to “be Agile”.  This means that teams continually demonstrate working software to customers and they are allowed to continually adapt their requirements to customer needs.  Then teams can more closely align with what customers find as valuable.  The more value customers see in your products, the more likely they will buy (or buy more).  Maybe, just maybe, if you convey that Agile can make them more money, they will listen and buy-in to what it really takes.     

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.