devopsy.kinsta.cloud

Category: DevOps Culture

  • How DevOps Training and Certification Benefits the Team

    How DevOps Training and Certification Benefits the Team

    Cisco Systems recently announced sweeping changes to its training and certification programs to increase the real-world value of both. Cisco’s move demonstrates a trend by organizations that provide training and certification to place more value on the practical aspects of educating technology professionals—which, in turn, should have a major impact on those looking to build DevOps teams.

    “Advances in network technologies have enabled new applications and business models—converged IP networks enabled voice over IP, 3G networks enabled mobile applications and 4G networks enabled mobile video,” said Susie Wee, senior vice president and CTO of DevNet at Cisco Systems. “DevOps has become a key factor for bringing those new networked applications to life. Training and certifications for network professionals and software developers have become a must. The goal here is to bring enhanced software skills to networking, enabling application developers to write applications that leverage the full capabilities of the network.”

    Cisco’s realization that real-world knowledge brings demonstrable value to businesses has culminated in new DevNet Certifications, which are designed to demonstrate an individual’s ability to bring software skills to evolving network technologies. “The only way to fully leverage the capabilities of the network is to build DevOps teams with both networking and software skills that can address the intricacies of both software-defined networking and physical networking solutions,” Wee added.

    Cisco is not the only company pursuing a change in training and certification processes. Industry group CompTIA recently revamped its certification programs. For example, the latest version of the CompTIA Linux+ exam has been redesigned to validate the competencies and skills required of early career IT professionals supporting Linux systems.

    “For certifications to have real value today, people must immerse themselves in the technology,” noted James Stanger, CompTIA chief technology evangelist. “The new Linux + certification uses performance-based testing that presents candidates with real-world scenarios, meaning that achieving certification demonstrates the ability to function in the real world.”

    CompTIA may very well be one of the leaders in the movement to bring real-world relevance to the certification process. The company has been using performance-based testing and has been embracing certification pathways to build teams. “For DevOps teams, critical skills, including project management, both agile and waterfall, are important. Developers will need to know the operating systems they are developing in, so they’ll need to understand Windows and Linux,” Stanger said. “The idea is that for DevOps, you need to get deep into the guts of operating systems and understand them well. You can specialize in one area, but you’ll also need to understand databases, relational databases and object-oriented databases.”

    Cisco also understands the importance of educating DevOps professionals. “Our new Cisco Certifications, with new DevNet Certifications, are designed for training and certifying network professionals and software developers, so they can bring software skills to networking,” Wee noted. “This new education process teaches application developers how to write applications that leverage the full capabilities of the network, and it helps build IT teams with network skills and expertise and software skills and expertise so they can leverage the full capabilities of the network, helping to support the DevOps process.”

    Cisco is also investing in the idea of building a community in the form of the company’s DevNet offering. DevNet was created some five years ago to help network engineers and application developers take full advantage of the revolutionary changes shaping the industry. The company is now focusing its efforts on what it sees as its customers’ biggest problem—network automation—and has created the DevNet Automation Exchange, a community-based developer center where networkers and developers can learn to “walk, run and fly” with network automation using Cisco’s products and the full capabilities of the new network.

    According to Wee, those three processes can be broken down into:

    • Walk: Get visibility and insights into their networks in a read-only way. This enables use cases such as gathering telemetry and insights from running networks and performing audits to ensure the ongoing security of the network.
    • Run: Activate policy and intent across different network domains. This enables use cases such as providing self-service network operations that comply with security policies and operational guidelines.
    • Fly: Proactively manage applications, users and devices with DevOps workflows. This enables use cases such as deploying applications in continuous integration and continuous delivery (CI/CD) pipelines while configuring the network in accordance with new application policies.

    Wee noted Automation Exchange has been seeded with more than 50 code repositories, many contributed by Cisco’s engineering teams and SEs. Now, she said, the company is inviting DevNet community members to submit code that solves their use cases.

    Updated certification and training resources from the likes of Cisco and CompTIA will go a long way to helping build DevOps teams that can hit the ground running.

    — Frank Ohlhorst

  • How to Rethink Sprint Retrospectives to Shape a Better Culture

    How to Rethink Sprint Retrospectives to Shape a Better Culture

    If you have been in a scrum team (or even an agile software development team), you most certainly have had or heard about sprint retrospectives or gone through them. They often happen after the team showcases the work done during the sprint reviews or demos. The original intent behind retrospectives is to help the team learn and improve faster as a whole, with an iteration at every sprint. What if sprint retrospectives could be rethought so that it stimulates more motivation and learning for the team at every iteration, and have its value spread across the whole organization? Growing knowledge and awareness within your team is great, but growing knowledge and awareness in your whole organization (including other departments) is better.

    The fact is retrospectives are part and parcel of the engineering culture, but also the company culture. In this article, we will quickly go over the current way of doing retrospectives, before seeing the different ways their impact can be strengthened.

    What Is a Sprint Retrospective?

    There are plenty of resources about what a sprint retrospective is. Simply put, the sprint retrospective meeting lets you analyze your process in the previous sprint and create a plan for improvements in the next. It gives the scrum team the opportunity to ask and address questions such as:

    • What did we do right in the previous sprint?
    • What did we do wrong in the previous sprint?
    • What should we start doing in the next sprint?
    • What should we stop doing in the next sprint?
    • What can we do to improve productivity?

    You want to keep these simple and short, and possibly use some templates, so that the team can easily memorize and improve on every iteration. You would want to keep the team focused, otherwise it can just turn in a social gathering. The retrospective can even include some thinking about the retrospective process itself. Nothing is out of bounds.

    Be careful to avoid bashing or criticizing, as well as allowing boredom. If the same question is repeated at every retrospective, your team might not participate anymore. If the same questions arise, what can we do differently so that it is finally fixed?

    Overall, the end goal is self-improvement as a team that always strives to perform better, as well as self-improvement for every individual, scrum master and product owner.

    What’s Wrong with Current Sprint Retrospectives?

    There is nothing wrong with the way we handle retrospectives currently, per se. It’s just that there are huge missed opportunities. Sprint retrospectives are about growing the team as a whole as well as all its team members. And, think of the possibilities if we were able to do the same across the organization?

    Actually, sprint retrospectives are much more part of the organizational culture than we might initially think. It’s among the few things that happen on a weekly or bi-weekly basis with other team members. Doing sprint reviews, demos and retrospectives the right way will shape your team and individual growth, in addition to the organization’s talent retention.

    Sure, there are a few well-documented things that you need to be wary of when doing a retrospective. I’ll list them fast but won’t dwell on them because that is not the point of this article.

    • Boredom: Having the same questions asked regularly will get your team bored and the feeling that retrospectives are useless. One way to avoid this is to change things a bit. Iterate on the retrospective itself or have a different retrospective meeting leader each time.
    • Lack of candid conversation: Without conversations, feedback and ideas flowing, retrospectives are useless. It’s important to foster participation from everybody. If you see a lot of blank stares, it might be useful to think about other ways to get participation such as putting ideas on paper anonymously. But at some point, your team needs to feel comfortable to share their ideas without fear.
    • Ego: It’s vital to put the team productivity above individual needs. There shouldn’t be any place for emotions, as it will thwart honest conversations from happening.
    • Disagreements: It’s more than okay to disagree. There is a quote that says “diversity in counsel, unity in command.” The more disagreements, the more ideas will be flowing, and the end result will be the best ideas. However, once an agreement is made, everybody needs to unite behind the decision
    • Conflicting agreements: Let’s face it, that can happen. In the end, a decision needs to be made, and as stated above, then everybody needs to get behind the decision.
    • Tired of change: Attempting too many improvements may actually prevent the team from improving. In that case, making sure everyone is keeping up is the most important. Sometimes it’s best not to change anything, but just to retry as becoming good at something takes time and persistence. Also, it might mean it’s time to iterate on the sprint retrospective itself.

    4 Ways to Rethink and Improve Sprint Retrospectives

    Now, let’s see what we can do to improve retrospectives, as well as spread its benefits throughout the organization by improving its culture. Some of these points will directly address some of the speed bumps mentioned above.

    1. Positive Reinforcement

    You need to be very explicit about positive learning, so you have more willingness to share within the team. It might be interesting to rename the retrospective to “wins.” For instance, sprint wins or week wins, if you do those every week, or Friday wins, if the retrospective happens on Fridays.

    The name will emphasize that we are here to improve and not blame. Wins can also remind people of the demos, as the new features and work done can be considered new product wins.

    1. A Ship-It Culture

    Software only creates value for customers once it’s shipped. That’s a fact.

    Shorter cycle times lead to both higher productivity and higher satisfaction, there has been quite a lot of study on this. Only presenting work that has been shipped during the sprint demo will emphasize this point and will spread a culture of shipping fast and often. You shouldn’t present work that’s almost done or waiting to be merged to master. Deploying a developer’s work is what is most exhilarating for the developer.

    By promoting a shipping culture, your team will gain more confidence and will express more motivation thanks to creating this high-velocity momentum sentiment.

    1. High Energy and Inclusive 

    We already mentioned some retrospective techniques–only shipped features, no blaming, only positive learning. But that’s not enough if you want to have the full attention of the whole team during those retrospectives. For this reason, you need the retrospective meetings to be high-energy with time limits. Time limits can make them actually fun for both presenters and audience, as there are some kind of challenges. And everybody loves fun challenges.

    But also, you need to make the whole team participate. Some teams might not have shipped anything in the sprint or week. Still, you need to find ways to make everyone part of the meeting, through questions or participation to the discussion.

    Finally, why do we have sprint retrospective meetings only within teams? They create new learning opportunities for the other teams, too. That’s why they should be inclusive to anybody in the team but also to all the other teams (well, until the size of the meeting is no longer sensible).

    1. Cross-Functional as Learning Can Be

    Coming back to the last point about learning opportunities, it’s also a missed opportunity for other departments, too. For example, if sales and marketing better understood the progress of projects, they would gain a better understanding of how software engineering actually works. Companies that succeed have teams that respect each other’s work and collaborate well together.

    Plus, it’s awfully hard to predict who needs what information in a big company. Leaving the retrospective meetings open to anyone could help people get the information they need.

    So, it’s worth the effort to invest in making attendance as easy as possible–support for remote people, etc.

    Would You Still Do Intra-Team Retrospectives?

    Should these meetings stay only within teams? Should you have intra-team retrospectives with all the discussions, before a general one with only the demos and learnings?

    The point of this article is that sprint retrospectives are a great opportunity to drive more knowledge, better collaboration and alignment throughout the whole organization. So, you should really think intentionally about what you want from these meetings.

    — John Lafleur

  • 6 Traits That Define DevSecOps

    6 Traits That Define DevSecOps

    How do we define DevSecOps? A combination of DevOps and security is readily apparent, but the philosophy goes much deeper. In a recent eBook, The State of DevSecOps, we asked industry experts to define what DevSecOps meant to them. Below, we’ve condensed their answers into five core attributes.

    Following these principles, CIOs or CTOs now have a DevSecOps doctrine applicable to nearly any software development and release environment.

    Security Automation

    DevSecOps emphasizes security objectives within the automation processes. Ben Newton, director of product marketing and evangelism at Sumo Logic, defines DevSecOps as first making security requirements and objectives a clear part of the continuous integration (CI) and continuous deployment (CD) cycle.

    Culture of Security

    DevSecOps establishes a team culture that embraces security concerns. As stated by Ben, a security team must provide “clear guardrails for developers as to what is fair game and what is not appropriate from a security perspective.” Building security expertise to integrate security into the entire DevOps lifecycle is critical.

    De-Siloing IT

    DevSecOps is about eroding boundaries. Just as DevOps has eroded the traditional separation between software engineering and IT operations teams, “DevSecOps further erases the walls between the DevOps team and IT Security,” said Tim Jarrett, senior director of product management at Veracode. “DevSecOps is about building a bridge between the security and DevOps teams,” echoed Dan Hubbard, chief product officer at Lacework.

    Security Shifts Left

    DevSecOps places security earlier on in the development process. IT security is traditionally viewed from a risk avoidance and compliance standpoint. Rather than viewing security as a gate, Tim noted that within DevSecOps, “security is better positioned to integrate earlier in the development cycle where they can actually make a difference.”

    Security Enables, Not Stalls

    DevSecOps supports, not stalls, agile development. DevSecOps doesn’t have to be sluggish. As Dan described, DevSecOps must “support the need for DevOps to move fast, but in a way where security is not ignored.” By embracing a security-as-code mindset and involving practices such as automated threat detection, agility is not sacrificed.

    — Bill Doerrfeld

  • Collaboration Inside and Out for Innovation

    Collaboration Inside and Out for Innovation

    Across all industries today, organizations increasingly are migrating their infrastructures to the cloud in a bid to boost agility, lower the cost of IT ownership and reduce the risk of outages.

    Firms are under more pressure than ever before to innovate new products to keep up with newer, more agile firms. But before they can reap the benefits that come with going totally serverless, organizations must deal with the immediate challenge of meeting the ever-growing expectations of today’s digital-first customer.

    For newer firms, this is arguably a much easier undertaking, as their IT infrastructures will have been built using modern programming languages, technologies and software development practices. They also will most likely have adopted an agile approach and be highly adaptable to changing business needs. Conversely, older firms typically have a large body of IT that lives in an entirely different world. With infrastructures made up of a patchwork of interdependent legacy applications, built on top of monolithic architectures, these firms struggle to innovate customer-facing applications at pace. But if they are to compete, established players must adopt a similar approach to their more agile counterparts.

    Don’t Hate the Players

    It is completely natural for technology to evolve. The problem faced by many organizations that were pioneering in their use of technology is that they have now become victims of their own success. Take the world of financial services as an example. Banks that began building out their IT infrastructure decades ago have had to adapt gradually to new technologies. But it’s only in recent years that digital transformation has become a key business objective. In the not-so-distant past, banks may have been able to get away with taking their customers for granted, as the competitive landscape lacked any real diversity. But today competition abounds, with challenger banks and fintechs bringing innovative new products and services to markets traditionally owned by the banks.

    If the banks are to compete, they must seek to collaborate with the fintechs. Cloud-based open platforms that focus on open APIs are the most effective means of achieving this. By providing fintech partners with access to core systems via open APIs, the banks get to concentrate on their core operations while innovation from the outside helps them to deliver new applications to their customers.

    Historically, the banks would have been fiercely protective of their IP and core systems, but in collaborative environments, it is exactly this IP that can be used to create value in a safe and secure way. This is why banks increasingly are seeing fintechs as partners rather than poachers, as they are above all technology providers that are eager to have their services leveraged by large financial institutions. Similarly, banks understand that they must become more agile and entrepreneurial to deliver what their customers want. So, working with third parties that embody these characteristics is the most effective means of doing so.

    Embrace Internal Collaboration

    As well as overcoming legacy systems, legacy culture must also be addressed if true digital transformation is to be achieved. The first way to do this is to align application development with business goals, showing how a focus on the former helps to achieve the latter. Here, the adoption of a DevOps mindset can bring about the right culture for increasing innovation within. Though not entirely applicable to legacy systems, which must be evolved at a much more gradual pace using a waterfall approach, DevOps can be applied when it comes to systems of differentiation—which include decision-making, pricing, analytics and risk management tools in the middle office, as these tools will need updating more often to accommodate changing business practices or customer requirements.

    Creating cross-functional teams that include business analysts, developers, data scientists, QA, UAT and compliance experts means there is collective focus and responsibility for the delivery of applications. It also enables more agile development so that applications can be pushed through to the production environment continuously, rather than simply throwing a finished product over a wall with little care as to how it performs.

    In recent years, IT increasingly has been seen as a business driver. As software development methodologies and practices that rely on a collaborative culture continue to mature and further prove their value, partnerships between larger organizations and disruptors will be viewed in much the same way.

    — Mitesh Soni

  • The Bumpy Rise of the Tech-Savvy CFO in Healthcare Organizations

    The Bumpy Rise of the Tech-Savvy CFO in Healthcare Organizations

    The good news? The working relationship between technology leadership and financial officers in health systems organizations is improving. The bad news? Chasms between finance and IT remain, and they are common throughout health systems providers.

    Market Research firm Black Book Research recently found, in its “2019 Black Book CFO & Financial Leadership Survey,” that chief financial officers (CFOs) are no longer prioritizing cost-cutting and are becoming more aggressive in their technology spending. Interestingly, 52% of CFOs reported that they are shifting their priorities to financial technology investments, such as the implementation of advanced analytics, as well as 44% who cited increased spending on broader distributed ledger technologies.

    This is a dramatic change over previous years, where financial technology in many healthcare organizations witnessed negligence and budget cuts. “Ninety-one percent of CFOs surveyed agreed that their past organizational CIO and senior IT management did not support a culture where financial technology upgrades and acquisitions were prioritized as initiatives that impacted enterprise health system strategy,” the report found.

    The survey found that 90% of financial leaders and management strongly agreed that CIOs and IT management undervalued the needs of financial digital transformation and their financial tools. Technology leaders instead prioritized and convinced their boards that their electronic health record vendor-related offerings were the best investment going forward.

    The result? When it comes to finance technology in healthcare organizations, the world has become quite bifurcated. Consider this: Ninety-four percent of marginally performing hospital CFOs nationally claimed that they are not prepared to handle new healthcare delivery and payment models with their current financial software. Comparatively, 89% of the top financially performing hospitals in the country report having the organizational technology tools to address modified payment strategies.

    There’s also no rest for the weary financial officer, the survey found. While senior financial officers struggled with the pressures of smaller operating incomes, rising labor and supply costs, shrinking volumes, reduced reimbursements, declining patient volumes and changing healthcare delivery models, 83% report that in the past fiscal year that they received add-on responsibilities that included organizational productivity, strategic technology and innovation growth initiatives.

    “In a noticeable shift since the acquisition of enterprisewide EHR systems led by CIOs, CFOs have become the executive charged with digital transformations to improve competitive advantages, strategic growth and innovation across all customer touch points, while measuring the technologies’ ROI,” said Doug Brown, president of Black Book.

    Indeed, there has been a huge shift in CFO involvement in recent years. In fact, 88% of CFOs report having increased involvement in their health system IT agenda since the implementation of their enterprise EHR, as compared to 14% in 2015.

    But this dramatic rise hasn’t been without friction:

    • 85% of all respondents stated that their current organizational structure prevents enhanced CIO-CFO collaboration. Eighty-nine percent of CEOs interviewed disagree with this statement.
    • 82% of CFOs stated that they have an insufficient understanding of IT issues as the barrier to them not being included in technology selections and approvals prior to 2014.
    • 84% of CIOs surveyed in Q4 2018 claimed the processes and tools in finance are incomparable to IT functions and remain a significant barrier to mutual understanding.
    • 90% of all respondents agree that the absence of key performance indicators that link IT agendas to financial performance greatly limits their success.
    • 98% of respondents strongly agree that it’s the healthcare CFO’s job to ensure their organization fully realize the benefits of technology investments, not the CIO’s job, in 2019.

    While the CFO’s role in technology has grown, largely due to the substantial impact of EHR adoption—and this has caused significant stress between the CFO and CIO in many health services organizations—the working relationship is showing signs of becoming stronger and more collaborative. The report found that the continuing lack in understanding on both parties to converge on strategies, investment mindsets, healthcare customer experience, business models and agendas continue to keep the barriers high for many.

    — George V. Hulme

  • Leading Business Transformation From the Top

    Leading Business Transformation From the Top

    From their inception, new agile digital disruptors have realized the importance of centering their business objectives around value and technology, making it vital for traditional incumbents to follow suit. If waterfall organizations ignore this challenge, their ability to innovate and react quickly to market changes and new customer demands is threatened. To change and succeed, the active involvement from the C-suite is essential to instill a cultural shift, placing value and people (employees and customers) at the center of any transformation.

    Sounds easy, doesn’t it? Well, actually, it is.

    At the heart of any transformation, there are common themes among agile organizations that, if implemented correctly, can have a major impact on productivity, innovation and the ability to grow market share, while enhancing the customer experience.

    Be Value-Driven

    Being value- and purpose-driven should be at the center of any organization wanting to be more agile, with a strong focus on the customer. To serve the customer, your organization, team and individual purpose must be explicit and aligned to one another. This ensures that every team member is directing their energies for the same goal to unlock the full potential of the business.

    On the surface, you may think this is already happening. Some boards are setting objectives related to the customer or efficiency, but too often this message gets diluted due to an inconsistent approach to determining value and prioritization. Often, decisions are not based around customer value because customer thinking isn’t extended throughout the value chain. Frequently, when decisions are taken in isolation, work that could offer true customer value is missed altogether. For example, fixing certain tech debt is often prioritized without the consideration of customer value, which contributes to waste. Value may be lost due to legacy processes, such as planning, budgeting and forecasting, which can slow organizations down.

    A lack of feedback loops and continuous planning can also impact business velocity, with the board needing to listen to product teams, as they are closest to the customer. This ensures that any reprioritization by the board is based on value, which is then filtered down once again, giving the product teams confidence to make decisions that will positively impact the customer. Traceability is increased further by implementing a story hierarchy, allowing everything from initial concepts, features and detailed user stories with acceptance criteria in a structured, easy-to-follow way.

    Do

    1. Ask what the value of any initiative is, even at the feature level, making sure it aligns with the organization’s objectives.
    2. Create true transparency of organizational alignment via a consistent hierarchy of work.
    3. Understand and organize around your value, helping teams relate to the customer and your goals. Too often teams are functional or system-based and don’t appreciate the end user experience, making systems thinking harder to achieve.

    Don’t

    1. Prioritize based on effort, which is a typical waterfall anti-pattern. Small, easy, quick wins will only reduce the capability to deliver true value.
    2. Set up projects to deal with regulatory change. Consider these as any other non-functional requirements and add to the product teams’ backlog.
    3. Organize in functional silos with work having to be passed between them to be completed.

    Create Teams Around Products

    In the world of agile, teams siloed by function rather than products don’t work. They’re too removed from the customer, require process hand-offs and often have competing objectives, resulting in work not focused on value. Small product teams stay close to the customer and quickly adapt to sudden market changes and differing customer demands. When done well, these teams are consistently more productive, morale is higher and better-quality products are released to market faster, with a lower risk of failure than traditional methods.

    To do this, teams need to be carefully constructed with the right multiskilled people who complement the product, including non-IT roles, such as sales and marketing. They should ideally be no larger than 10 to 12 people or “two pizzas” (see Brooks’ Law), which makes them highly productive and accountable, empowered by clearer visibility and effective collaboration. Organizations with large monolithic systems will find this challenging due to the amount of responsibility placed on the team. Breaking these down into loosely coupled microservices can help by reducing the scope of accountability to a manageable size.

    By having teams work this way, products can have funding associated to them, with product teams directly mapping to this. This makes it easier to track ROI, which is a better metric to measure output compared to capex or opex. As a result, legacy reporting needs to change, too; the metrics you really need are cycle time, right first time (quality) and customer experience. These are then used by product teams to understand how they are contributing value. All these metrics can be generated automatically and made available through dashboards; gone are the days when PMs and PMOs need to chase developers for updates.

    Do

    1. Value teams and individuals in value creation roles and remunerate them accordingly, considering product ROI. In particular, rockstar engineers should be able to increase ROI, and should be retained at all costs.
    2. Break monoliths down into microservices. These are smaller in scope and more manageable for a single team.

    Don’t

    1. Set up project teams, which by nature are short-lived and reduce accountability. Empirical data shows that stable teams are 60% more productive and 60% more responsive to customer input than teams that rotate members.
    2. Track value through project accounting metrics–opex/capex split doesn’t help make decisions, it only creates management overheads that demotivate people.

    Create an Engaging Working Environment

    Globally, two-thirds of employees are not engaged. This means employees turn up for work but do not apply themselves and offer minimal effort. By having an agile mindset, implementing a set of principles based around value that everyone works to, gives employees the confidence when making decisions. Even if the outcome isn’t exactly what was expected, having a fail-fast attitude can allow continuous learning and improvement to flourish—the only way to evolve is to fail. It also helps create a culture where engaged employees feel valued and psychologically safe.

    With an engaged workforce, people collaborate more, helping knowledge and skills to be shared, boosting innovation. This notion is supported by the Medici Effect, where the greatest innovations are created by the “intersection of ideas, concepts and cultures …” This environment doesn’t just have an impact on innovation: According to Gallup Business Journal, engaged employees can be directly related to increased revenue. That isn’t all: Compared with disengaged teams, engaged teams show:

    • 24% to 59% less employee turnover.
    • 10% higher customer ratings.
    • 21% greater profitability.
    • 17% higher productivity.
    • 28% less shrinkage.
    • 70% fewer safety incidents.
    • 41% less absenteeism.

    Leaders should make space and time for diverse new ideas to emerge but must maintain an overall sense of purpose. It is their responsibility to help people resist the urge to converge quickly on a solution without feeling they lack direction.

    Do

    1. Empower your people by trusting them to do their jobs, which in turn will create value for the customer. As Richard Branson said, “I have always believed that the way you treat your employees is the way they will treat your customers.”
    2. Embrace failure and learn from it. The fastest way to innovation is through experimentation and learning. Delivering in smaller increments reduces the risk and investment and gives results quicker.

    Don’t

    1. Assume you have all the answers. Allow your employees to develop a collaboration of ideas to identify one possible solution to a product or process design challenge and find seven possibilities.
    2. Expect innovation to happen in a vacuum. It’s not the responsibility of a few individuals but rather one big team. Value new ideas from your employees and create an environment where innovation can flourish and is rewarded.

    Outside-In Focus

    Although trust in your employees and understanding their motivations promote increased productivity, if organizations ignore their customer pain points and don’t have the ability to adequately respond to customer feedback, all other efforts will be in vain. Leaders need to consider what is happening outside the organization and be aware of customer demands, as well as market trends and behaviors.

    In one of the most recognized cases, Blockbuster’s demise, many consider digital disruption paved the way to administration. In reality, it may well have been the company’s difficulty to innovate quickly enough compared to more nimble competitors. Blockbuster was savvy enough to see the rise of Netflix as a threat, but internal legacy processes made it more difficult to react. When it did act, its traditional way of working led to a proposed solution costing circa $400 million, which led to investors struggling to see ROI, so deemed it too risky.

    A more agile organization could have responded quicker and with smaller increments (MVP), making its overall solution cheaper. Further analysis would have also identified that the cost of technology advancement would decrease and support services would evolve. Being set up as an agile organization and assessing outside influences, Netflix had also foreseen the move from the traditional VHS-versus-DVD market to what customers really wanted: video on demand.

    This is no longer a choice; all leaders must be aware of outside influences (PESTEL) and emphasize the use of consumer analysis and encourage their employees to put themselves into the end user’s situation. By doing this, agile organizations can adapt to market forces and customer feedback quickly, helping to prioritize the backlog and provide value.

    Do

    1. Take feedback from the customer early, feature toggling and canary testing are great ways of enabling this.
    2. Constantly research, analyze and understand the effects outside influences can have with business and customer alignment, and the impact on value.
    3. Respect your competitors and the new kids on the block. They may have seen something you don’t.
    4. Understand how technology can and will change consumer expectations and habits. Evolve your products accordingly.

    Don’t

    1. Rely on past successes to survive. Phrases such as, “We’ve always done it this way,” and, “We’re too big to fail” should never be spoken.
    2. Dismiss information (shoot the messenger) because it’s a tough pill to swallow and will require significant change within your organization.

    If the above organizational attributes are not realized, the chances are that your business is not agile, so a shift in mindset is necessary to establish a new way of working. This will only happen if the CEO leads from the front, embraces agile personally and creates an engaging working environment where work is prioritized by value and people (employees and customers). Then, and only then, can innovation thrive, boosting productivity and helping your business to react fast enough to changing market forces and remain competitive.

    — Louise Cermak

  • A Golden Age for Developers

    A Golden Age for Developers

    There’s probably never been a time since the dawn of programming when there has been more opportunity for developers—individuals and teams—to imagine, create and be successful. Developers are able to do a lot more (and do things a lot faster) with more tools, a better development ecosystem and a tighter connection with the rest of the enterprise than was possible even a few years ago.

    To me, we are in a golden age for developers. And it comes just as the need for developers has never been greater, in every enterprise.

    Three things have come together to create this moment: Culture, code and the cloud.

    Changing Culture

    First, developers today operate in a culture that is far more collaborative than in years past, both internally and externally. A big part of that is the growing adoption of the DevOps methodology, which breaks down silos between business units, IT and development through partnerships between developers and the enterprise. It’s changing how we work and think.

    DevOps leads to a process of continuous integration of new ideas and features that meet business needs, and continuous deployment life cycles that get those features operational rapidly. Rather than taking weeks or months to get a new version of an application up and running, it’s possible to make constant incremental changes and have things running in days or even hours. The enterprise is able to be exceptionally agile responding to business changes and challenges—and, if there’s a problem or failure, the mean time to recovery is just as fast.

    Democratized Code, Empowering Cloud

    A major factor in enabling this approach is the widespread use of open source code. Open source has democratized access to powerful tools and platforms that can greatly accelerate work for any developer. Open source projects are mature, stable and growing, which provides equal access for citizen and enterprise developers alike. The size of your IT operation no longer matters: Developers everywhere can call up on their laptops the same tools that once were available only to web-scale unicorns. It removes limits to a developer’s imagination and the ability to create something new.

    Finally, the ever-expanding realm of cloud-native computing is putting incredible resources and computing ability within reach of every developer. Tools such as Kubernetes, which let you create and orchestrate applications in containers that can then be deployed and run in the cloud; serverless technologies; and other new ways of using distributed computing power remove barriers. Where a developer once might have been reluctant to create apps that required high levels of computing power, that’s not the case now with the cloud. What once may have taken access to a Cray supercomputer is now at a developer’s fingertips.

    Retraining, Not Replacement

    If there’s any challenge in this golden age, it’s helping the enterprise to make the transition—in particular, facilitating the leap that existing development teams must take in using these new approaches and new tools. In fact, the top issue for cloud developers is to make this cultural change.

    That takes both strong top-down leadership and an openness by veteran developers to new ways of working for developers, especially those who’ve been around for a while.

    Too often, we see companies trying to make the switch by offering early retirement to their veteran developers and trying to recruit a new team that’s already used to DevOps, open source and the cloud. That’s the wrong way to do it. Instead, even as they bring in newer developers, companies should look to retrain their existing team.

    That takes more than just telling people, “Here are the new ways we’re going to operate,” and then throwing them into it. There are a lot of tools and gateways available that can help people move gradually from the tools and languages they have been using. For example, in the last 12 months alone, numerous open source Kubernetes operators, service brokers and frameworks have been introduced that allow enterprise teams to leverage cloud-native technology from a context they already know, including WebLogic, database and Java. Look for combinations of people and projects that are likely to result in some early wins, and then have those people help train the rest of the organization.

    Make sure to take advantage, too, of the external collaborative environment that exists. Have veterans go to conferences or meet-ups and learn from the community—which, thanks to open source, is huge and growing.

    This will do more than give you a development team that’s built for today’s market, which demands that you deploy faster and react to failures in a more graceful way. It also will help you recruit and retain. Developers are twice as likely to recommend their workplace to if they are using DevOps principles—they are happier, easier to recruit and easier to retain.

    In this golden age for developers, the potentials are limitless—and every enterprise can participate. Making that cultural change, taking advantage of open source code and exploiting the power in the cloud—those are the keys to building the team and the applications that will spell success.

    — Bob Quillin

  • How Systemic Approaches to ITOps Impact the Business Culture

    How Systemic Approaches to ITOps Impact the Business Culture

    We are at an inflection point in the rise of big data. Enterprise IT infrastructure is producing data at a scale like the world has never seen before. IT operations (ITOps) management has accelerated past the notion of data storage and processing (vis a vis the Hadoop model) and into the world of analytics-as-a-service. We now need systems to drive insights and manage change on-demand. In fact, we need a new operating model for IT in the face of these new effects.

    Can a New System Save Us?

    The key to transforming into a responsive, data-driven enterprise—while avoiding a flood of unnecessary processes and over-staffing—is to adapt automation to intelligently consolidate information flows. At the same time, the dynamic nature of today’s IT environment requires IT teams to become literate in a completely new approach to technology, one that spans all functions of the business. Consequently, risks that previously stayed inside organizational units now leak across domains, influencing decision-making for the entire company. These factors will try to pull the organization in multiple directions at once; only a unified data management system with the intelligence to extract operational insights can drive positive business change.

    Culture Has Got to Change, Too

    Agile processes such as DevOps and AIOps offer mechanisms to control the flow of data and turn it into actionable results. For example, continuous application development and deployment gathers data about functional use, user sentiment, efficiency and various other metrics to inform the overall process and improve the product. Such rapid dev cycles let organizations identify and fix issues more quickly and with fewer resources, ultimately delivering greater business value.

    The resulting streamlined collaboration among IT, development and customer teams improves capabilities but also introduces dependencies that must be managed effectively. It changes the culture to adapt to the system, and thereby, the system of service delivery will fundamentally affect how organizations are structured, built and run. Eventually, there will be increased digitization of every human process, and that means human impact slowly will be replaced by AI impact. This doesn’t mean that machines are coming to take our jobs; instead, it means the modern enterprise IT organization must address a new future. How will it look?

    Retraining and Reskilling Is a Fact of Life: In a world of dynamic IT, requirements are no longer static, and teams need to be prepared. Organizational units must be able to work in different ways with new technology, with new skills that include robotic emotional intelligence, cloud-native literacy and infinite adaptability.

    System operators become stewards of the business because system operations directly impact business outcomes. It won’t be enough for workers to merely deploy, configure and manage IT while isolated from the goals of the company, because those goals are inextricably linked to how objectives are achieved through innovation. Employees will need to develop new skills for functioning in a dynamic system. Training staff in agile methodologies, service-oriented software design and six sigma-style approaches for process improvement will become critical for success.

    Automation Is Everything: Automation by policy won’t be enough; even runbooks will become obsolete. Data and results are always changing, so simple automation will not drive meaningful change. AI can be used to drive automation policies and frameworks, with the potential to reduce errors and integrate disparate systems, which previously required multiple points of oversight.

    The trend toward using AI for data understanding is driving intelligent services into other parts of the business, as well. Rather than just for correlating system and operational data, AI is being adapted to business process optimization. Moving forward, IT operations can begin to run themselves, led by deep data analytics. Alerting and response processes automatically will use their own feedback to update the system’s intelligence, identify emergent trends and take actions to deliver improved operational results.

    Risk Becomes Universal: Increasing connectivity and generalized frameworks (such as DevOps and site reliability engineering) mean that risk is no longer siloed to one department or function. It’s spread everywhere, and cascading effects become commonplace.

    In general, successful engineering outcomes rely on coordinated processes and policies that dictate operational needs, even after deployment. Introducing connectivity between formerly disparate systems can create instability that potentially affects operations in other unintended areas. Thus, broad risks arise if different systems can’t interoperate once unified into a single IT ecosystem. Addressing requirements under a generalized framework helps prevent gaps between application implementations.

    The System Drags the Company Forward: Insights-driven action will transform digital business well in advance of executive priorities. Change will happen before anyone is ready. Indeed, with so much complexity, so many tools and processes and so many competing business demands, IT changes now impact culture in entirely new ways.

    Business impacts will come from system intelligence rather than manual processes. Efficiency in operations management is derived from the entire system, including the people themselves. What was previously the IT culture is rapidly being replaced with a combination of self-adapting processes and workers who focus more on value than on plumbing.

    Transforming the enterprise from silos into integrated platforms will propel the business forward. The resulting system will also drive cultural change at an accelerated rate, perhaps faster than the worker community is prepared to accept, but informed by real data instead of executive intuition.

    — Bhanu Singh

  • How to Solve Any Problem in 3 Steps Using the Zombie Retrospective

    How to Solve Any Problem in 3 Steps Using the Zombie Retrospective

    Facing challenges is an inevitable part of life, but how we deal with them can make a big difference. When problems show up, it’s important to focus on the things that unite us—it’s better to have a common enemy than fight internally. Experience in complex software development has taught me that it’s crucial to stop, think and act at regular intervals.

    The feedback loop is the concept on which the agile mindset is built. Instead of having a project that is one year long, we divide the project into smaller mini-projects of two to four weeks. As the saying goes: There is only one way to eat an elephant–one bite at a time.

    To inspect and adapt quickly, I recommend a time frame of just two weeks. During these two-week sprints, the team must work hard to achieve the goal. At the end of each two-week period, the team meets to inspect progress and creates a plan for improvements during the next sprint.

    The purpose of the retrospective is to:

    • Inspect how the last sprint went with regards to people, relationships, process and tools.
    • Identify and order the major items that went well and potential improvements.
    • Create a plan for implementing improvements to the way the team performs its work.

    (Source: Scrum Guide).

    These retrospectives can be general or they can be focused on one issue that occurred during a sprint. Sometimes a retrospective is about de-escalating or resolving conflict and tension. If the sprint didn’t go as planned, the facilitator needs to be cautious about how they run the retrospective. They need to keep in mind how they say certain things, because team members might already have low spirits coming into the meeting.

    I stay away from using harsh judgments, blaming specific members or showing my frustration. The goal is to create positive energy for the retrospective. Facilitators should motivate the team to have fun while they participate in the retrospective. I like to have high energy, be positive and try to get the others on the same boat.

    As a scrum master myself, I was shocked to find out that only 81% of scrum masters hold retrospective meetings. The retrospective is an essential part of any given sprint and provides valuable information on how to improve.

    Preparation

    Before the retrospective meeting, I think about the format and tools. If you work in a distributed team, like me, a digital whiteboard is recommended. Using the digital whiteboard, we can have a retrospective no matter where we are in the world.

    Here is my process for a zombie retrospective meeting. It’s divided into three steps: check-in, input and output.

    Figure 1: Zombie Retrospective board.

    Step 1: The Check-In (15 Minutes)

    The check-in stage is kind of an ice-breaker. It should be fast, like the starter before the main dish—which in this case would be the deeper and more constructive discussion. Check-ins are treated as an exercise at the beginning of the retrospective to gather information on the just-completed sprint. One nice starter for more in-depth discussion is the happiness index: a quick way to check-in with the team and to see how everybody experienced the last sprint.

    I ask the question: “On a scale of 1 to 5, specify how happy are you with the last sprint? No.5 is super-happy, and 1 is totally unhappy. Put the sticky note with one keyword next to the number on the whiteboard.”

    Figure 2: Icon made by Freepik from www.flaticon.com

    The Scale Is:

    5 = Super-happy! Don’t want to change anything!

    4 = Pretty happy, but there are some things that need to be fixed.

    3 = I can live with this, but there are many things that need to be fixed.

    2 = Not feeling so good about this right now.

    1 = Totally unhappy, I want out.

    I give the team three minutes to five minutes to gather the input, then we discuss the issues. It’s a perfect moment to turn the problem into opportunity. You can use solution-focused questions, such as:

    • What needs to be done to raise your happiness index?”
    • Let’s imagine we have an ideal world, what would it look like?
    • How would you like to have it?

    Example:

    The team members identified that they are moderately happy because they spend a huge amount of time preparing for the release. The work is boring and repetitive. I then turn the problem upside down and ask how we would like to have it. The team then starts with something they want.

    Goal: As a team we want to have automatic regression tests, so that we can have faster releases and use our time for value-added work.

    Next, we define action items that will help us achieve the goal—we plan to invest time and implement the automated tests. The product owner will be responsible for managing the product backlog in a way that we would achieve the goal within six months.

    The scrum master needs to keep in mind which team members are more open to sharing their opinion and those who are more reserved. Shy employees may have lots of great input, but if they don’t feel comfortable sharing it, they will simply sit back and listen. It’s up to the scrum master to understand the team well and know which team members may need an extra push to be more vocal, to collect the input from the colleagues that are more reserved. The first step is to create an inclusive workplace with a team culture of trust, openness and transparency. You want to reach a point where everyone feels like they’re really a part of the team, and know how their efforts contribute to the team’s success. It’s important to remember the importance of tone of voice and body language and the positive influence this can generate.

    Step 2: Team Input (45 Minutes)

    There are plenty of techniques to collect input from the team during the retrospective. When I prepare the whiteboard for a retrospective, I look into the different techniques and choose the one that I believe is most fitting for the current context. When we face prevalent problems and challenges, I particularly like the zombie retrospective.

    Figure 3: “The Zombie Retrospective” by Agata Matynia. Image representing the zombie retrospective used to support the team input stage. This tool helps teams to visualize problems as part of the journey to aid creative solutions.

    With this poster, I explain the following to the team: When a virus turns the human race into bloodthirsty mutants, we need to save ourselves from the zombie attack. We need to think clearly, so our discussion would be split into three groups.

    1. The zombies in the illustration represent the problems that we have.
    2. The blocked chair represents the actions we can take to stop the problems affecting us.
    3. The last place is our hiding place. The TNT explosives, gun and hand grenade represent the team strengths.

    Once the team has finished contributing their input, we then go through every idea on a case-by-case basis and discuss it. This stage should take a maximum of 45 minutes.

    Following discussion, we then move on to the final stage of the retrospective. This step takes all the input and turns them into concrete, measurable goals with action items, responsible people and clear timelines.

    Step 3: Team Output (15 Minutes)

    The output stage outlines the goals the team would like to achieve the actions they will take, who will do it and when. The tasks are handed out to the team, and the scrum master needs to delegate people to specific areas with deadlines to ensure that things get done. Otherwise, everyone will agree that something needs to be done, but nothing will be changed.

    I use the following format to achieve this:

    • Goal: The end result the team wants to achieve.
    • Actions: The action points that need to be done to achieve the goal.
    • Who: The owner of the goal.
    • When: The specific date.

    Example:

    Goal: As a developer team member, I want to gather analytics on how the mobile app is used so that it can focus on things that matter.

    Action point: Deciding what information to gather and who will do it.

    Who: Anna is the owner of this topic.

    When: In the next sprint.

    The retrospective at the end of a sprint should never be left out. It allows for the continuous improvement of people, relationships, process and tools. It makes the team great.

    Optional Step: Inspect and Adapt the Retrospective in the Plus/Delta Format (10 Minutes)

    From time to time, it is a good idea to evaluate the retrospective meeting. The goal is to be able to learn from the current retrospective to do it better next time. For this, I recommend using a quick, simple technique such as Plus/Delta to make improvements.

    In this final step, the team identifies the strengths of the retrospective and what changes can be made for the next one. I ask the team to use the sticky notes to share their thoughts.

    Plus: What can the team change or add to bring more value to the retrospective? How we can repeat it?

    Delta: Is there anything that we should change in terms of how we run the retrospective as a team?

    [Place for sticky notes]

    [Place for sticky notes]

    Action Points

    Source: https://leanconstruction.org/media/learning_laboratory/Plus_Delta/Plus-Delta.pdf

    The answers to these questions can give scrum masters valuable feedback on how to bring the team together, solve problems more efficiently and make the best use of the time spent in the retrospective. Up until this point, team members have only been discussing the previous sprint, so giving them some time to reflect on the meeting itself sometimes helps them unwind.

    More Ideas to Spice Up Your Next Retrospective

    The retrospective meeting is a great opportunity to inspect and adapt. If, like me, you would like to run it every two weeks, you will have about 26 of these meetings in a year. The zombie retrospective is great, but you should avoid using the same approach every time. Get as creative as you like—there are many variations and possibilities worth exploring.

    For check-in, I also like to utilize pain scales, a common communication tool used in a variety of medical contexts and settings. Trust me, it also works perfectly in business. Try the LEGO pain assessment tool as a starter.

    For the input stage you could use:

    Remember: Having fun is exactly what gets team members more interested!

    — Michal Serkieza

  • IT Skills Challenge: Let’s Talk About the Elephant in the Hiring Room

    IT Skills Challenge: Let’s Talk About the Elephant in the Hiring Room

    There is a glaring skills challenge facing the UK tech industry. It is the perennial concern of business leaders, with the most recent research from the Cloud Industry Forum stating that 52% of UK tech companies lack IT skills in at least one area of their business. The findings, based on interviews with senior IT business decision-makers, also predicted that the skills challenge is only going to increase in the future.

    It is an obvious statement that these shortages stem from not having enough skilled people in the workforce. However, it is more complicated than this, and many in our industry compound the problem with poor awareness of diversity and inclusion.

    Look at the tech industry workforce: It is overwhelmingly white and male and there is often an office culture that reinforces the prominence of this demographic in the workforce. If you have a skills shortage, it makes no sense to culturally exclude half the population. Every business needs to cast its net as wide as possible. Not only does this increase the skills gene pool, but it also has been shown that the more diverse arrangement of people there is in an organization, the more successful they will be in meeting the needs of their customers.

    No hiring policy should limit a skilled employee from making a difference just because of the color of their skin, gender or belief.

    Unintended biases can take hold in organizations. For example, it is often seen that tech businesses fall into the trap of reinforcing bias by appointing hiring managers from similar backgrounds and experiences, a process known as affinity bias. Most organizations, especially large ones, claim to be diverse and inclusive, but a simple glance at their board members can tell you how much of that is true. All this bias ultimately leads to the same result: hiring people for a less diverse and less effective workforce where most employees look, sound and think the same. What employees don’t realize is that a diverse workforce is ultimately more profitable and productive.

    To ensure that your company is hiring a diverse workforce, HR decision-makers can opt for process changes that not only assist in screening applicants but also checks for inherent biases. Blind hiring also could be used, as it works by removing personal information (such as name, age or gender) from a resumé or CV during the assessment and selection process.

    Lack of gender diversity is a problem area for tech companies across the globe. While it is a known fact that women are at par with men when it comes to skill sets, they are still less represented at managerial and boardroom positions. The situation is even worse for women of color.

    Gender-diverse teams are on average more creative, innovative and, therefore, more profitable, and this should be an incentive enough for tech companies to hire and retain more women who can grow and take leadership opportunities. Another way you can address gender diversity in the workplace is by ensuring female representation on interview panels, adequate maternity schemes and an overall environment where everyone feels accepted and invited.

    Another issue one may not consider is the use of certain language that can offend and even discourage women or members from LGBTQ backgrounds from applying for a role. For example, using words such as “aggressive,” “challenging” and “ambitious” in job descriptions have been shown to suggest more traditionally masculine cultures that discourage female and minority groups from applying.

    Working in the IT industry myself, I understand the struggles and challenges of recruiting a skilled workforce, especially women. Having said that, I also understand that a diverse workforce is always good news, not just for the morale of the employees, but also for the overall office productivity. We must take proactive steps to close the skills gap in our industry because if this decline continues, it can have far-reaching consequences.

    Understanding the gravity of the situation, it’s time we moved beyond half measures and took concrete steps in recruitment and retention in our IT workforce. Britain has long been a melting pot of cultures and to take advantage of this, IT organizations must curb implicit biases in hiring. All employees from all backgrounds should feel invited and respected for their skills and talent. Because as an industry, it’s all about embracing new ways of thinking, organizing and problem-solving.

    — Annalisa O’Rourke