Author: Joshua Platt

  • Crossing the Ecosystem Boundaries: How ServiceNow, Salesforce and Atlassian Work Together

    Crossing the Ecosystem Boundaries: How ServiceNow, Salesforce and Atlassian Work Together

    Although these platforms were originally designed to serve different functional roles—Atlassian’s help desk, ServiceNow’s IT service management and Salesforces’ sales and CRM—from the outset, they all addressed the evolving mega-management and leadership issue: collaboration across teams and business units.

    Independent action, siloed organizations and disconnected thinking was increasingly giving way to more agile, interdependent, collaborative problem-solving practices and methodologies. Whether the differences were political, cultural, intellectual or institutional, survival became progressively dependent on living, working and communicating more effectively across all boarders. It was in our individual and collective, both internally and externally, best interest to do so.

    Effective companies and the platforms that served them needed to promote a culture that collaborated with less friction across five boundary types (“CCL’s” Center for Creative Leadership’s Boundary-Spanning Leadership)

    • Horizontal: Expertise, function, peers.
    • Vertical: Rank, class, seniority, authority, power.
    • Stakeholder: Partners, constituencies, value chain, communities.
    • Demographic: Gender, generation, nationality, culture, personality, ideology.
    • Geographic: Location, region, markets, distance.

    Collaboration initiatives generally begin by focusing on existing boundaries within a specific business unit or team. Then they expand to forge common ground on specific projects across teams, and finally, moved across all five boundary types with multiple teams and interdependent projects which some refer to as complex adaptive systems. These platforms were launched, quickly developed and continue to evolve to meet this collaboration challenge head on.

    Making Sense of the Blurring Boundaries Across Convergent Platform Roadmaps

    Boundaries are difficult to identify when they are continuously moving and being redefined. Instead of taking a more traditional route of seizing mind and market share by differentiating and establishing/defending clear boundaries, these platforms are doing the opposite, they are converging. The ecosystems that support each platform are also beginning to look increasingly similar—but more on this in a future post.

    The convergence of frameworks such as ITSM and Agile represents a tangential and interconnected set of moving boundaries intersecting somewhere along the spectrum at ITIL—ITIL4 if you’re counting. As all three platforms seek broader market penetration reflecting this full spectrum of frameworks, consider using the ITIL4 Edition’s 17 service management practices as a cheat-sheet for their boundary spanning enterprise roadmaps:

    • Business analysis.
    • Service catalog management.
    • Service design.
    • Service level management.
    • Availability management.
    • Capacity and performance management.
    • Service continuity management.
    • Monitoring and event management.
    • Service desk.
    • Incident management.
    • Service request management–includes both request fulfillment and access management of ITIL V3.
    • Problem management.
    • Release management–includes an explanation about releases in waterfall driven environments and DevOps driven organizations.
    • Change control–formerly known as change management.
    • Service validation and testing.
    • Service configuration management.
    • IT asset management.

    As organizations prioritize and re-prioritize the list reflecting their Agile/ITSM journey, the boundaries between platforms will move, and in many cases, simply disappear. As this journey plays out in your company, the platforms and ecosystems that support each will need be rationalized. Said differently, you may be asked or told to choose one, but as our experience suggests, you won’t need to do that today.

    Instead of diving into the technical features and benefits of each platform and ecosystem, take some time to reflect the benefits of expanding your boundaries to address the business challenges you are facing now and expect over the next 18 months.

    Where does this leave you and your team today?

    While everything else gets worked out….

    • Review the ITIL4 Edition’s 17 service management practices and rank prioritize for your team and company.
    • Do a self-assessment on your personal commitment to, and comfort with, the benefits of expanding your boundaries.
    • Meet with your team and have each of the individuals do the same.
    • Encourage conversations about where the platforms appear to be focusing (e.g., Atlassian focusing more on ITSM and ServiceNow paying more lip service to Agile).
    • When the time comes to make recommendations on app consolidation or choosing one platform over another, your team will be well prepared to do so with open, informed and agile minds.

    One last note on the benefits of expanding boundaries: Leaders who effectively reach beyond their present boundaries have the advantage when faced with solving problems, creating innovative solutions and evolving to thrive in today’s interdependent, complex world. The benefits of boundary spanning leadership include:

    • Increased organizational agility to respond to a dynamic marketplace.
    • Advanced cross-organizational innovation processes.
    • Achievement of mission-critical, bottom-line results:
      • An engaged and empowered workplace at all levels.
      • Flexible, cross-functional learning capabilities to solve problems and adapt to change.
      • Better-managed risks and rewards through enduring cross-sector partnerships.
      • Higher-performing virtual teams.
      • Global mindsets and cross-regional collaboration.

    Use these bullets to get your team spanning conversation started.

    — Joshua Platt

  • Successful DevOps Initiatives Start With Company Culture

    Successful DevOps Initiatives Start With Company Culture

    What initially drove the need for embarking on the DevOps journey in your team or at your company in the first place? Was it:

    • Market shift?
    • New leadership or an acquisition?
    • New product or service idea?
    • Cost savings or consolidation?
    • All of the above?

    Whatever drove the need, my guess is there were pre-sales demos, reorganizations and training on new tools that were promised to solve all your DevOps problems along the way. Now, I must break your heart just a little: Buying new tools or apps will not, on their own, ensure positive DevOps outcomes.

    A tool-first approach is ineffective. In fact, it may actually generate backlash from the individuals or groups who are invested in protecting the status quo and result in a wasted implementation effort. Imposing new methodologies or processes across teams through new tools can cause people to dig in, generating responses ranging from passive-aggressive to overtly destructive—both contributing to failure.

    It Starts With Culture

    Your success on the DevOps journey starts with culture. Culture transcends tools, methodologies and processes, making use of all but not relying on any. Culture was, and always will be, present, and much like continuous development—routinely referenced in DevOps—it is continuously influenced by everyone and everything in its environment.

    The successful implementation of DevOps must begin with a conscious effort to reassess and evolve a company’s culture, supported by the tools. For example, continuous deployment as an initiative will only find traction when members of the team all believe, philosophically, it is best for the organization. It requires a certain kind of individual.

    A culture of rapidly evolving and adapting teams focused on continuously discovering, developing and delivering demands a commitment to evolving toward a more contemporary integral DevOps toolset, not the other way around.

    Culture Alignment as a Competitive Advantage

    Cultural alignment is not a buzzword bingo box that gets checked off. One’s sense of alignment with a clearly articulated mission and set of values, coupled with a way of working in a team and supported by the right tools, generates velocity and efficiency. This alignment becomes a competitive advantage.

    But, doing so demands all participants to be more conscious of how what they do affects everyone and everything else, in real time.

    Culture Change is Difficult but Achievable

    It can be very daunting or even scary if your company culture has a long history, producing images of the Borg or Hive, depending on your age bracket. Changing a culture is difficult. Here are some thoughts on where you might start.

    Learning agility: Focus on learning to dance with VUCA (Volatility, Uncertainty, Complexity and Ambiguity) instead of being consumed by it.

    Diversity: Commit to working with people with wide-ranging intellect, backgrounds, titles, CVs, life experiences, ways of learning, gender and energy, instead of working with your mirror.

    Trust: Build a work environment based on psychological safety—a sense of confidence that the team will not embarrass, reject or punish someone for speaking up. Knowing takes time and deliberate effort.

    Leadership: Adapt and promote a leadership style such as the 3 C’s of change leadership–communicate, collaborate and commit.

    Coaching Culture: Consider championing a coaching subculture by applying a methodology such as LACE to work through difficult conversations:

    • Listen to understand.
    • Ask powerful questions.
    • Challenge and support with feedback.
    • Establish next steps and accountability.

    Worth It

    We started with a little heartbreak. But I have had enough conversations about DevOps success and failure to believe that you already knew it was not just about tools. We have all felt the weight of culture when it is not in alignment. Employing some or all of these recommendations will set you down the path of creating your own language that is a requirement for building a culture. Now stop looking at the next great messaging protocol and start working on building an agile, aligned culture.

    — Joshua Platt

  • How to Improve DevOps Visibility

    How to Improve DevOps Visibility

    DevOps, by design, works quickly and accomplishes deadline-driven projects rapidly. With a high amount of project turnover, visibility into key operational data is easy to mismanage and can lead to simple mistakes, lack of optimization and organizational misalignment. To examine the effect of DevOps visibility, SmartDraw commissioned the “2019 DevOps Visibility Report.” The results were decisive: Each company surveyed is seeking ways to better DevOps visibility, and 84% of respondents list it as somewhat to extremely important to their organization. But achieving DevOps visibility is not always simple.

    Roadblocks to Achieving DevOps Visibility

    Respondents identified that visibility reports take skilled workers away from their other priorities. In a small, fast-moving lean team, removing a skilled worker from a key deadline-driven task can cause performance and timeliness to suffer.

    Further, the reports often are visually complex and not useful. If the team member creating the visualization is unable to design it in a simple fashion, the report is often wasted effort as it provides no actionable insights.

    Finally, and potentially the most harmful, the reports are static and do not accurately represent the current state of information. DevOps teams are meant to be agile, and poor report updating practices can lead to stale data. When that stale data is used to make decisions, organizations lose productivity and quality.

    So, what should DevOps managers do to improve this process?

    Key DevOps Visualization Recommendations

    The “2019 DevOps Visibility Report” uncovered four insights to improve operational visibility and efficiency with expanded real-time DevOps data visualization:

    • Avoid building static reports in spreadsheets: Spreadsheets, while effective at data analysis, are not the correct medium for visibility reports. The static data quickly become out of date and useless. In today’s modern business landscape of rapid change and competition, any manual work becomes a risk to an organization’s decision-making ability.
    • Present common DevOps information in an easily comprehensible manner: Respondents reported challenges in reporting data in a way that a variety of audiences could comprehend. These reports are designed to be consumed by multiple levels of the organization, with varying degrees of technical knowledge. The most successful respondents focused on visualizing data in an easy-to-understand way.
    • Adopt low or no-code solution for visualizing unique relational data: By utilizing a solution that is fully or mostly automated, organizations allow their skilled team members to prioritize deadline-driven work. Further, this automation allows for improving real-time information and lessens the likelihood of stakeholders making decisions based on old, outdated data.
    • Create self-service reports that enable non-engineers to visualize DevOps data without submitting change requests to engineering: It’s crucial to be able to remove DevOps team members from the update process. Key stakeholders should have the ability to generate a report easily and without input from DevOps. Additionally, this report should be based on existing source data, and should allow for anyone to drill further in to see the raw numbers that the visualization is drawn from.

    Conclusion

    A good DevOps process improves quality, lowers cost and saves time. Yet, poor visibility can limit DevOps success and lead to misalignment. Organizations should adopt an automated real-time DevOps visibility solution to allow team members to focus on the crucial pieces of their role, provide relevant information to managers and create digestible visualizations.

    — Joshua Platt

  • Dev and Ops: Not from Different Planets

    Dev and Ops: Not from Different Planets

    At a conference, I heard a speaker remark that “Dev people are from Mars while Ops people are from Venus.” That’s catchy and captures what a fair number of managers believe instinctively. But is it really true? I’m not convinced.

    We all know that DevOps enables us to deliver software faster, with fewer bugs and much less downtime than traditional approaches. But DevOps is new, complex and often challenging for teams to embrace. Developers often guard their tools and operations shake their head each time they hear about some new asset bundling package they have to support. I think the first few meetings of Dev and Ops probably do a lot to build the notion that they are from different planets.

    In my experience, however, the opposite is true. To borrow a different popular catchphrase, they are more “brothers (or sisters) from a different mother.” When you examine the makeup of Dev and Ops people, you find more similarities than differences. Here are some examples of their common ground:

    • Consistency and Standards. Both Dev and Ops are technical endeavors that place a huge premium on things being “precisely” correct. Whether coding a service or setting up an AWS instance, “in the ballpark” doesn’t cut it. For this reason, both camps try to establish standards for how they work. Whether keeping Dev teams all using the same environment or Ops trying to keep Dev, testing and products all running the same, both need to benefit from building consistent environments.
    • Coding Skills. Whether coding or scripting, Devs and modern Ops teams need to be comfortable in a variety of highly technical tools. Build scripts, deployment, automated testing and reporting all require some coding skill.
    • Common Tools. If you look at the DevOps ecosystem, you’ll increasingly see tools that are intended for both Dev and Ops tasks. Dev people, for example, use Git for reusable code; Ops uses Git as well for configuration of things such as Docker. Also, Dev uses Jira to track bugs while Ops uses Jira to track tasks.
    • Shared Metrics. While their focus may be different (code versus pipeline), both Dev and Ops share many metrics of success—consistent delivery, fewer errors, responsiveness to customers and uptime, to name a few.
    • Test-Driven. Dev and Ops both embrace the “fail fast” mantra. They want to know if a change will break anything as soon as possible, long before it ever impacts a customer. Both often start with automated tests, which are run on Dev or local instances, to verify the changes are non-breaking.
    • Love of Automation. Neither Dev nor Ops enjoy manual, error-prone work. Both gravitate to tools that automate routine tasks, reducing variances and errors.
    • Star Wars. Finally, both groups are avid “Star Wars” fans. Just watch how they open automatic doors using the force or name servers or other things with sly “Star Wars” references (such as “Secret Rebel Base”). In fact, next time you’re in a DevOps meeting and somebody is wondering if Dev and Ops can get along, bring up Jar Jar Binks and marvel at the immediate—there will be a completely concordant reaction from both sides.

    So, are Dev and Ops from different planets? I don’t think so. I see Dev and Ops as being like those twins separated at birth, who, when reunited decades later, laugh the same, have the same twitches and both married spouses with the same first name. And in the best DevOps shops I have seen, that’s a really good thing.

    — Joshua Platt