Adopting Jazz at the Team Level

A couple of common themes seem to be popping up in the Jazz community recently.  There is some “tribal knowledge” within the Jumpstart team about these things, but nothing out on Jazz.net for some of these topics.  So it makes sense for me to blog about them here, and give people a high level look at some of these issues and the ways to think about and address those issues.

The adoption of the Jazz technologies at a team level is one of those things that we get a lot of questions about.  Since Jumpstart works with a multitude of Jazz customers at various stages of their deployment of the Jazz solution, I get the following question:

“How do customers typically deploy the Jazz solution to their individual teams and roll the solution out to their software development organization?”

My answer to that invariably begins with the observation that every customer situation is different.  They have different hardware and network infrastructures, different regulatory concerns, different organizational structures, and different software development cultures.  However, there are some broad patterns for success that we see, and I want to share them with you.

Pattern #1 – Keep it simple

Organizations that strive for simplicity tend to have smoother adoptions of the technology.  The tools will help to hide some of the complexity from the end users, and they will also ensure that the high level process for software development is followed.  Successful adopters of the Jazz solution will make sure that the general process for using the tools can be condensed and understood in no more than two or three slides.  If you need more than that to describe how your users will interact with your tools and processes, then it is probably too complex.  There are exceptions to this rule, but you probably don’t qualify as one of them.  Unless you have specific regulatory or legal concerns that MUST be ENFORCED, do not have the tool doing heavy-handed enforcing of the process.  It makes your end users mad, it is more difficult to maintain, and it does not handle exceptional conditions very well.

Anti-Pattern #1 – Define Everything

Some organizations attempt to define their entire software development process in the tools, and then have the tools enforce that process.  This leads to very long deployments of the Jazz capabilities, as end-users and stakeholders argue over the implementation of the process enforcement in the tools, and the time it takes for the tools support teams to implement the process enforcement in the tools.  This is true of ANY tool or technology adoption.  I have seen customers spend months implementing process templates, customizations,  and automations that cover their entire software development lifecycle.  When it then is rolled out to the user community, the end users claim that the tool is bulky and does not help them at all.  The problem isn’t really with the tools, the problem is that the process is implemented in the tools without regard for overall business objectives.

The lesson learned here is it is better to give teams ways to monitor their process, rather than spend the time enforcing process and trying to implement all of the exception paths that may need to be in place.  An example might better illustrate this.  In many development teams the concept of a code review is part of the software development process.  Now there are exceptions to the rule that all changes MUST have a code review.  Attempting to enforce the code review as part of the process, and then also implementing the process for the exceptions to this rule, can take a lot of time and money to implement and test.  Providing a mechanism for doing a code review, and then a way to conduct the code review with no process enforcement is better.  Development leads can then monitor and run queries on work items, looking for those that have no code review artifacts.  A quick glance by most development leaders at this list will be enough.  They can see all of the work items that have not done code reviews, and then make sure that only the exceptional cases have skipped this important step.  It is much less intrusive and disrupting to monitor, rather than enforce.

Pattern #2 – Embrace Continuous Change

Deployments of new tools, process and technologies are difficult.  For the organization that is adopting these, there are a lot of unknown factors that need to be accounted for.  Organizations need to pursue strategies to address this risk.  The first thing to remember is this:

Embrace the fact that you will be constantly improving your software development infrastructure

It seems like a pretty simple statement, but many people forget about this when deploying new tools, processes and technology (like Jazz).  I cannot count the number of times I have been asked for project plans, detailed rollout plans, Gantt charts, and all manner of planning artifacts to define the rollout of Jazz to a new community.  Stop it.  The only purpose that these serve is to lock people into making unqualified commitments, based on little or no information, and providing a false sense of security that the risk in now managed.  Please stop doing this, it hurts…..

Instead have a high level plan for how change will spread through the organization.  Start with some small early adopting teams.  Based on what you learn from their experiences, you will then be able to provide a common migration path and better estimates for migration to the rest of your organization.  Don’t make the estimates from some IBM expert (like me) the basis for your planning, plan based on the results that YOU see, in YOUR development environment, in YOUR software development culture.

Use your early adopters have to provide a base of knowledge for you.  Collect common artifacts and techniques that work, and improve your capability to not only estimate the effort involved in migration, but to actually perform the work.  As you complete the migration of your early adopters, you will be in a much more informed position to estimate the speed that you will be able to sustain in migrating the remainder of your software development teams.

Anti-Pattern #2 – Define it All and Understand Everything

Some organizations attempt to define their entire deployment of the Jazz tools prior to moving a single user.  This requires months of study and investigation, constant working and reworking of plans, and long protracted arguments about the best ways to move forward.  It can lead to analysis paralysis.  It also delays the adoption of the tools, and the realization of value from those tools, by the teams that the tools were initially meant to help.  Organizations need to get comfortable that there is nobody in their organization that has ALL of the answers.  I do this stuff for a living, and I don’t know all of the answers.  How can your internal deployment teams be expected to know all of the answers?  The quickest path to disaster is to force teams into making unrealistic commitments, while everyone else in the organization has a false sense of security because there is a PLAN in place.

The lesson learned here is that you cannot predict everything that is going to happen.  You need to manage the risks of this type of activity.  The way to manage those risks to identify what the risks are, and then use demonstrated experience and knowledge to reduce these risks.  The only way to gain this experience is by actually migrating early adopting teams, and having the courage to admit that you will make mistakes.  Just have a strategy in place for dealing with those mistakes, and for learning from them (so you don’t keep making them).  Some organizations use Centers of Excellence to help promote the best practices associated with migration to new tools and their effective use.  Others rely on User Communities or other mechanisms.  I don’t care what you use, just choose something that will work in your culture.

Pattern #3 – Use It Yourself

When rolling out Jazz to any new customer or user community, I always suggest that we track our efforts within a Jazz project.  Why?  It forces the deployment and migration teams to use the technology and become more comfortable with it.  It also forces them to share in the pain of any part of the deployment and migration that is substandard.  This is a powerful incentive for ALL stakeholders to participate and be involved in the process.

There is also the effect it will have on the senior management and your business stakeholders.  As they want information on how the migration is progressing, you can get them “trained” to go look at your dashboards and plans.  This serves two purposes.  One, it frees you up from endless status meetings telling everyone how great you are.  Two, it forces your stakeholders to become active participants in the use of the new technology.  They will end up training themselves, and will become aware of the capabilities of the Jazz tools.  Finally, having something like this available for everyone to see serves as a good way to do demonstrations of how the tools can help your internal teams.  Since this is active and alive, it is a demonstration that can be delivered anytime, with any audience.

Anti-Pattern #3 – Track Your progress on a Spreadsheet

When the teams responsible for the migration and adoption of the new Jazz tools use spreadsheets (or even worse, Gantt charts), they are sending the unspoken message that the Jazz solution is “too new” or “too hard to use”.  These deployment teams lose all credibility in the eyes of the people that they are attempting to promote change with.  Your deployment and migration teams need to embrace change, and this needs to be part of the culture of that team.  This enthusiasm and openness will become infectious, and will help the software development teams adopting the Jazz solution overcome their fear of change.

The real lesson learned here is that the credibility and attitude of your team helping deploy this change to your software development teams is critical.  A team with enthusiasm and an open mindset will be much more successful than the team of “corporate tool drones” who come in and just mumble something about, “I’m just doing my job”.

Pattern #4 – Limit Scope

Limiting the scope of what you are doing is probably the single toughest thing to do.  Limit the amount of change that you are forcing on your software development teams.  Once they realize the value from adopting a small change, then allow them to adopt more change.  Make it an incremental process.  This allows the individual software teams to limit the risk to themselves, and also allows them to digest and understand things in a more manageable way.  Very often software development teams will have some existing tools in place that work quite well, like Maven or Jenkins.  Let them continue to use the things that are working well for them, and integrate their use into your new Jazz development environment.  Use the Jazz tools to address areas where those teams will see value.

This takes courage and some discipline.  Often we want to go in and just do a “rip and replace”, changing everything all at once.  Resist that temptation!!  Make sure that your end users are able to realize some benefit from all of this change.  As they see the benefits, they will begin to ask you to increase the pace of change.  This is quite a bit more productive than going through a series of exercises where you are forcing new tools and processes on teams that are resistant to change.

Anti-Pattern #4 – We Just Bought it All, We Have to Use it All

Unfortunately we have customers who make a large purchase of the entire Jazz CLM solution (including RTC, RQM, and RRC), and then attempt to deploy ALL of these to their development teams.  They are eager to realize all of the benefits of a Jazz based development environment, and they want to get a quick return on their investment in the tools.  This is the “Big bang” approach.  Unfortunately, this can quickly lead to results much like the original Big Bang.  An organization can be left with nothing more than a jumble of hot gas and random energy.  People are not able to successfully adapt to all of the changes being asked of them, and have an inherent fear of all of the changes.  Big bang migrations also run into issues because they must be meticulously planned, they fail to limit scope, and they force people to predict all of the potential issues that could arise.

The lesson learned here is that the value of the Jazz solution is that it increases collaboration, communication and transparency.  A deployment that damages the ability of the organization to realize this, due to mistrust, hurt feelings, or missed expectations, has a direct economic impact on your organization.  The value of Jazz is that it is supposed to make software development easier for your end users, not more painful.  If your end users are not realizing any benefit from the new tools and processes, then regardless of what has been deployed, your deployment is a failure.  Your end users should be telling you how much more effective and productive they are, and not complaining about the new tools.

Conclusion

The rollout of a new Jazz development environment, or any new process, tool, or technology, can be a scary thing.  There is no one “correct” way to deploy and migrate teams to a Jazz solution environment.  The techniques and approach for deploying Jazz will vary from situation to situation, and there is no “one size fits all” model for doing this.  The culture and environment of every organization will impact the deployment process, and every implementation is different.  What we can do is identify many of the common behaviors that successful teams have, as well as some unsuccessful anti-patterns.

Keeping an open mind, limiting scope, having an enthusiastic deployment team, focused on simplicity, and embracing the concept of continuous change, are some of the common patterns that we see in customers that successfully adopt the Jazz solutions.

Extra Credit

Often people struggle with getting that initial list of things to be aware of.  I mention identifying what your risks are, and then moving to address them.  Below I have a list of common areas of concern and activities that occur in any deployment of Jazz tools.  You can get more detail on a lot of the infrastructure areas of concern by checking out the Jazz Deployment Guide.

• Infrastructure setup
  • Application Servers – How many do we need? What is the Public URI?
  • LDAP – How are you handling user identity?
  • Database Servers – Use existing resources?
  • Reverse proxy usage – Use a reverse proxy or not?
  • Support team – Get your deployment and migration team together
  • Common process support – Will you have common process templates for all teams?  Will you allow them to customize this process?
  • Management support – What does Management need?  What support does this effort require?
• Adoption/Migration Path
  • Analysis of current environment and process – How much change?
  • Identification of integrations and data migrations – What needs to be migrated? What needs to be integrated?
  • Identification of critical reports and metrics – Identify alternatives, and develop any custom reports
  • Education of adopting team – Training
  • Migration dry run – Make sure that it will work
  • Project/Team Migration – The big transition day
  • Mentoring – Continued user support and guidance
  • Feedback – What worked well?  What needs improvement?