Zero to Fear in 60 Seconds

One of the key benefits that Agility provides is visibility. If you have read any agile book or if you have been fortunate enough to implement agile in any manner, you will quickly agree that visibility is king. Heck you can even get a quick refresher from on of my previous posts called We Live in a Glass House!

When you go through the process of converting an existing non agile development process into using Agility, you have to realize that culturally, folks aren’t going to be used to the visibility agility provides. In fact, it might even frighten folks. Hence the title of this article - Zero to Fear in 60 Seconds.

As part of rolling out agility, we made it very clear that accountability and visibility were top priority. We stressed the importance of empowerment at the iteration team level. We raved about the ability for the team to truly own their work beginning to end. At the same time, we reminded folks that in order to be empowered, they had to be accountable.

We kicked off our first agile release with roughly 10 teams all executing in parallel within 2 week iterations. We held our first 2 day release planning session to establish our release commitment. We then ran our iterations using iteration planning days and iteration demo days - the basic release planning and iteration planning approach that Dean Leffingwell and others describe so well.

Everything was working great - or at least it seemed. Everyone would come to the daily scrum of scrum and communicate their status appropriately - pretty much always green with a few yellow’s from time to time. It was a smooth start - lots of excitement and lots of empowered folks.

Unfortunately, it was a bit of a facade. In hindsight, what really happened is that folks weren’t used to speaking up. They weren’t used to the visibility. They were scared to say things weren’t going well. Especially when every other team was doing so well. What we experienced was a fear of accountability so strong that it actually prevented our ability to truly show visibility. Even though we enabled everyone to be empowered and we had multiple mechanisms in place to drive visibility, we actually lived in a dream world until our hardening iterations came along.

Now - you are probably asking yourself how could this be? How could everyone have missed the signs? Why didn’t Product Owners or Scrum Masters speak up and state the obvious? It’s not that simple - it was our first agile release of that magnitude. With the exception of 2 teams, the remaining teams had little agile experience. In addition, not a single team had run in 2 week iterations before. We were all new to this format.

So… the morale of the story is that it takes time to figure out visibility. You can’t assume that a new agile process will bring about visibility and all of a sudden eliminate the struggles non agile processes have. For us, we are just now reaching a point where visibility is truly king. Where people know how to communicate and express the the true state of their team. Where our daily scrum of scrums really drive out cross team coordination, dependencies and impediments. We got there by coaching our scrum masters and product owners. We enhanced our ability by structuring our release planning and iteration planning in a manner that fed the updates within our daily scrum of scrums. Here are some basic tips that really helped us

• Release Planning - Make it clear to everyone what epics & stories have cross team interest. For example, Team A is committing to a story that Team B and C are dependent on. Everyone should understand this and the person running the Scrum of Scrums should remind folks regularly
• Iteration Planning - In addition to stating iteration commitments, ask teams to restate their commitment to the release commitments. For us, we use Epics as the “release commitment” and stories that comprise the epic as the “iteration commitment”. This gives us the ability to track release commitments at a higher level vs. having to track every single story. It also gives product owners autonomy to adjust stories post release planning without the fear of missing a release commitment. It’s a bit nebulous - you have to have faith in your product owners to protect the spirit of the commitment
• The reiteration of whether or not we are committed to our release planning commitments occurs numerous times through the release - once per week. Each iteration planning update as stated above. In addition, we also do a commitment checkpoint at each iteration mid point. The daily scrum of scrum that occurs during the middle of each iteration is actually run a bit different. Scrum masters provide a feeling on the their team’s projection for the end of iteration and the release. 
• Mentor scrum masters and product owners to provide valuable updates during each daily scrum of scrum. Use feedback often to ensure your scrum of scrum is viewed as valuable. People shouldn’t see it as just another meeting - if your updates or attendance is poor, question your format and not your people. Meetings should be interesting and debate and discussion should exist
• Leverage a few star scrum masters and product owners to set the standard. Call on them first during your release planning, iteration planning and scrum of scrums to provide updates. If you pick someone who doesn’t provide good updates, you may cause a domino effect where everyone follows with a poor update
• Provide a status update that goes out to everyone - not just executives. Every member of the entire agile release train should have access to the same status report that goes out to executives. We do a 2 week roll-up status report that occurs after each iteration planning event. This also includes an update of our release plan of record. No one from the team provides a status report - they provide enough updates in their daily scrum of scrums, commitment meetings, etc. The individual that runs our daily scrum of scrums for all 10 teams does it solo
• Provide metrics on Done, Done, Done results of user stories - however, do so for their growth and not for external purposes. Missing a user story in an iteration is bad but it’s not the end of the world. In fact, it may be the best thing that happened since slice bread if the team learns from their mistake. The metrics give them the ability to improve. Hold them accountable through their retrospectives and let them know that you expect improvement. If it continues to be a problem, then address it properly. 

Strive for visibility! it’s what you want. Don’t give up early - it took us 3 months to get to where I mentioned above. Deep into the middle/end of our 2nd release. We realized we had problems early into the first release but it took us a while to fix it. It’s human nature to get frustrated and think people just don’t want to or don’t know how to provide good updates. Remember that they don’t know any better initially but they want to learn if they are truly committed to agility!

Why does Agile go sour?

Any new process is met with those that are enthusiastic and those that are detractors.  Only time will tell if you can tip the balance in your favor.  This balance is especially interesting when you have a legacy process in place that has a long history, has produced results over time and has several people who are well entrenched in “the way things are”.  However, there is a reason that exploration for a new process took place, and moving from waterfall to agile was met with welcome arms by several within the organization - especially those in Product Management.  This cannot be forgotten.

 

The requests and increased pressure from clients to move from producing a cabernet sauvignon that takes several years into making a sauvignon blanc that can be turned out quickly are coming from all angles.  The promises of the new process cause a lot of excitement and buzz.  Short term successes start to build the momentum and the agile train is growing with passengers.  The problem, there will be bumps.  All of a sudden, you find those from the previous process are quick to request expectations and depth comparable to a cabinet sauvignon being produced in the time of a sauvignon blanc.  This isn’t to say you can’t produce a complex sauvignon blanc, but it takes practice - so don’t expect this right away.

 

The challenges associated with this become increasingly difficult when you enter a world where both processes have to co-exist in a single development organization (Waterfall and Agile).  Some are working on the new agile methodology while others continue to work on the way things used to be.  It is divided by teams and by applications, which causes a natural chasm.  However, these teams are expected to integrate and blend when it is all said and done.  When the heat is turned on, those that were on the fence or just wrapped up in the excitement of agile quickly revert back to wanting all that was waterfall… thorough design documentation, pseudo code, and painstaking approval processes.

 

This is not the recipe for a good blend.

 

You all of a sudden find yourself in a situation where the agilest are making compromises to the new process, scrutiny from the highest levels is increased, and those that were on board are starting to wonder which side the company is going to end up supporting.

 

How do you keep people from going sour?  How do you ensure that they keep the faith in agile?

 

Just like any process, things will go wrong.  Lessons are to be learned.  Unanticipated challenges crop out of nowhere.  Above all this, there are those that are trying to ruin the crop before it is even harvested in the first place.  Whether out of fear or comfort, the want the old to continue to succeed and the new to never come off the vines.

 

There are three key ingredients that set you up for a chance at success:  Communication, Executive Sponsorship, and Agile leadership with conviction.

 

The first answer to most challenges starts with communication.  Up front and honest communication that outlines that this is new, this is unchartered territory and there will be sour grapes in the bunch.  It is a constant battle to ensure those on the fence that the process can make a difference and that we will get there.

 

This is where the next two ingredients come in.  With executive sponsorship it makes it possible to knock down walls that previously stopped progress.  The fear people have with a new process is somehow alleviated by just saying “Executive so and so” is behind this initiative and it is critical for the company’s success.  Keep in mind, that knocks down the wall initially, but then as time goes on those that have their doubts will retreat, and likely go to the executives with their complaints.  It is at that time you need to see the true strength in executive management when they stand by their decision.

 

Finally, conviction in the leader of the agile process has to be there, and that conviction has to trickle its way through the agile side of the process and ultimately to those that are on the fence.

 

There is a saying that says to “keep your friends close and your enemies closer”.  In an environment that is introducing agile into a blended world, I don’t think anything could be more true.  While it is important to ensure your own house is in order, it is doubly important to make sure the teams around you that are watching with skepticism are included in what is going on and the pressure is reapplied to what they are responsible for with regards to making the overall company successful.  The agile leader(s) with conviction and confidence will help navigate these waters.

 

Product Management is a good place to continuously use as a litmus test.  If they continue to support what is going on, then you continue to have a fighting chance.  Keep them in the loop, make sure they are constantly reminded of why agile is good and the benefits associated with the methodology.  They are there, and the company can get there – you just have to be sure to recover from the bumps.

 

It is not an easy formula, but none of the good blends ever are.

If You See the Spotlight, Don’t Ignore It

Agile is less about software development and more about building highly effective and efficient teams. The team is a family committed to each other and to the work requested of them. It’s a unified team, one that from the outside appears to be a single powerful entity instead of several different individuals.

 

Agile relies on team accountability and team empowerment to deliver consistently amazing results. High performers are attracted to this type of environment because there is no place to hide. If you can’t perform at the level expected by your team, you’ll be answering to the entire team vs. a single manager.

 

There is no place to hide. Nowhere. The average performer will feel their skin burning under the bright spot light. It won’t just be the team that notices - even the individual will quickly realize they aren’t meeting the team’s expectations. 

 

In a healthy environment, the average performer will be quickly addressed. Perhaps via a new role that leverages their skills more effectively. Perhaps they will self select out. Perhaps they will be coached out of the organization. While this may seem harsh, it’s the best decision for the team, the individual and the company. It’s expected and it has to happen fast. Because there is no place to hide. Especially when you run in short iterations and the criteria for success is clearly defined within the user stories committed to by the team. The average performer is accountable to the team and it’s so much tougher than being accountable to one manager. As a result, high performers know they will be working with other high performers who will provide mentoring, enjoyment and a great sense of team accomplishment. A players attract A players. It’s that simple.

 

But what if the culture you live in doesn’t believe in high performance? What if it’s customary to give average performers second, third and even fourth chances? In the agile world, you are dead. The key thing gained by agility is compromised - team accountability and team empowerment. If the team is lucky, the average performer will leave on their on accord. Even if the team is that lucky, they will lose faith in management’s ability to eliminate impediments. The ability to truly leverage the utmost power of agility may be lost forever.

  

The problem becomes significantly worse at scale. What if six teams are highly effective but one isn’t? What if the scope committed in a release requires all seven teams to be highly effective? All of a sudden, the overall agile release train suffers because they are only as strong as the weakest link. What if executive sponsors are still tentative about agile? Will you let a single team of 6-8 people destroy the ability for 40+, 100+ to become truly agile?

 

While there are many reasons why agility may not work, I personally believe no other killer is more powerful than ignoring the spotlight agile shines so well. If you truly want to experience the power of agile, you must heed the advice of the spotlight and you must do it quickly. Coupled with a solid retrospective strategy, heeding the advice of the spotlight will send you down the path of success faster than any other advice I can offer.

 

Agility leverages the power of team accountability and team empowerment. Why even try if you aren’t willing to use it fully???

The Power of the Product Owner

In an effective agile iteration team, everyone is viewed as a highly effective team member. They may have different skill sets, different levels of experience and different work/life priorities. Regardless, the team is a team - unified in every way. Even so, two roles stand out a bit more than the others - the product owner and the scrum master. These two individuals, more than anyone else, are responsible for ensuring the team is ultimately successful.

For now, let’s focus on the product owner. Until we tried to scale agility beyond 1-2 teams, I never truly realized how powerful the product owner role was. At scale, the product owner role becomes pivotal to the success of the overall effort. No other role has the ability to clearly articulate the vision of where each team needs to go. No other role enables each iteration team to be truly autonomous while also ensuring the vision is preserved.

In addition, an interesting dynamic occurs when a team is fortunate enough to have an effective product owner. Even though the product owner represents the traditional product management organization (and may even be part of the PM organization), they really are a member of the iteration team.

Sounds pretty simple but don’t underestimate the behavioral transformation the overall organization goes through. Traditionally PM asks for 10 items and development says they can only deliver 5 items. This constant tension generally leads to a clear organizational boundary.

That changes with an effective product owner because a) they become aware of what the iteration team can really deliver, b) they develop a strong and powerful bond with the team and c) they commit and operate as part of the team and not as separate requester.

The tension that previously existed disappears. Even if it doesn’t disappear 100%, it shifts from development vs. product management to product management vs. product management. Sounds odd and to some extent simple. It’s a very powerful transformation that ultimately leads to better planning and much, much less frustration. Everyone becomes more knowledgeable and in doing so, more of a family.

Conversely, not having an effective product owner will destroy the ability for an iteration team to be effective faster than any other individual or impediment. We’ll cover some of these issues in future posts.

The Power of Diversification in Agile

It doesn’t take a lot of money to quickly realize that diversification is the key to managing your risk. If you role the dice and invest all your money in one stock, you might hit it big. However, history shows that you will likely walk away very sad. One key to successful investment is diversification…

So what does diversification have to do with Agile? Well… in terms of release planning and vision at an enterprise scale, it’s everything! The standard approach the industry has traditionally used for software development is to define a vision and road map that in turn is used to accurately plan the development, testing, documentation, deployment, etc. of a new set of functional features.

This “rigid” plan is then locked and execution starts. Any shift in execution is viewed as a bad thing which in turn leads to the “next” plan being adjusted because the current plan obviously can’t change - it’s locked! In the agile world, you still have something similar - it’s just in the form of iterations and shorter duration releases. While you embrace change, you still want to define a solid plan that is just long enough to avoid constant shift distractions.

The power of diversification in agile comes from a thinking about planning a few different ways

• Minimize the duration of the release to the least time possible - this enables you to still lock the release in order to avoid distractions and constant shifts while still enabling time to market adjustments
• Define your road map in a manner that enables flexibility without giving up visibility. You don’t want to error on the side of not defining a road mapbecause you still need to be able to communicate commitments that extend beyond a single agile release to your sales force and clients. You can accomplish this by adjusting the number of external commitments (we call them MUST epics) based on the maturity or evolution of the plan of intent. The further out the POI, the less you commit to.
• Define your client commitments in terms of Epics. An epic is a larger grained story that is subsequently broken down into smaller grained stories. If you have capable product owners, you can communicate the spirit of the “epic” to your clients while still giving the team the autonomy to adjust via the proper definition of stories during the actual release execution
• Embrace change - let product managers shift the contents of a POI. The key guideline is that the closer the POI is to being converted to a true Plan of Record (POR) as part of the release planning process, the less it should change. This is a guideline that will improve your velocity and release planning efforts. It is not a hard rule.

So… why on earth would a product management group that is used to 1 to 2 year road maps ever agree to something like above? Well they won’t initially. However, if you involve them in the agile process and some of them actually dedicate a good portion of their time to successfully enabling the product owners of the iteration team, you will quickly see an almost reverse effect. Very quickly, they will recognize that the value of being able to adjust to the unknown is desirable and powerful. This combined with the ability to lock in a small subset of important features vs. the entire release is exactly what they needed. It’s just not a natural thing to do until you experience it first hand.

OK - diversification as a topic may have been a stretch. It’s just something I thought about as I was playing around with stocks and watching Jim Cramer’s Mad Money. Hopefully they can give you something to think about in the agile world!

We Live in a Glass House

One of the biggest benefits agile provides is crystal clear visibility into a variety of items including

• What it takes to actually develop working software
• The quality of the people involved in the development process
• The issues and impediments that arise from execution

Visibility is a great thing. It allows you to take risk, experience minor failures and adjust without truly failing. With the proper leaders in place, poor performers are quickly transitioned into other roles were they may perform better or if appropriate out of the organization altogether.

     

Visibility is a great thing. Don’t fear it. Don’t run from it - embrace it. That’s what I have always believed in and that’s what makes sense in a truly agile embracing environment. So simple yet so powerful.

     

Unfortunately I was wrong. Along the way, I learned that visibility isn’t always a good thing. When you introduce agility into a culture that isn’t accustomed to visibility, it’s even more powerful yet extremely dangerous if not managed well. 

     

Take waterfall development for example. The true consequences of a major / critical failure are often realized after it’s too late to make a difference. When the event occurs, 10s of people are involved in trying to salvage the situation. Alerts notify executives and everything possible is done to correct the situation. Sometimes it works… Sometimes it doesn’t… The key  take away is that it’s a major event and executives, project management groups, release management groups, everyone is in the know.

     

With agility, the simplest mistake - a missed story in an iteration critical to a product owner is quickly identified and usually fixed in the following iteration. Course is corrected and everyone is happy.

     

Unfortunately, theory isn’t reality in this situation. The simplest mistake becomes the same catastrophic event described in the waterfall example. All of a sudden, the simplest mistake is misinterpreted for the major failure and the world reins in to solve the problem. Every executive, project manager and hero arrives to take control. All of a sudden… visibility is not a great thing.

      

Instinctively, eliminating visibility sounds like the right answer. It’s NOT.  Falling into this trap will ultimately lead you away from agility. For now, we have focused on helping others understand that small failures are OK. It still causes frustration more often than not but we are slowly making progress towards eliminating the false “alert” behavior. While I can’t state I have found the perfect solution yet, I can say that I still believe in visibility. It is a great thing and it’s a key tenant of agility.

Welcome

Agile Juice is a blog dedicated to the advancement of software agility. We’re experienced agile advocates in the Telecom / Cable software industry. With the help of others throughout the software industry, we have learned a ton and in the process, have been successful at leveraging agile best practices to deliver enterprise scale BSS and OOS software of high value in within reduced timeframes. It’s now our turn to give back to the community.

For the bulk of our careers, our agile experiences have been centered on development shops of 30 folks or less. However, that has recently changed and over the past year, we have transformed a 100+ resource development shop into a synchronized agile release train that operates in concurrent and parallel 2 week iterations.

We owe a lot to Dean Leffingwell for helping us get started. Since his original visit, we have continued to advance towards agility and we continue to improve our efficiency and execution each day. While we have made tremendous strides, we are farm from truly being a highly efficient enterprise scale agility shop.

From this point forward, we will share with others our successes, our failures and our ideas so that others considering or executing towards enterprise agility will be able to benefit from our postings as well as hopefully contribute to our own learnings. We hope you enjoy our musings and that they may ultimately improve your ability to promote and leverage enterprise agility!

We’ll be posting musings on a variety of topics. These include

• Organic - True agile concepts
• Fortified - Altered or augmented concepts to enable enterprise agility
• Corked - Situations where agility is no longer a reality (even though you may believe otherwise)