devopsy.kinsta.cloud

Tag: team

  • Using Observability to Create a Smart Data-Driven Culture

    Using Observability to Create a Smart Data-Driven Culture

    The first words that come to mind when talking about smart technologies are often artificial intelligence, machine learning and automation. While these smart technologies play a crucial role in smart-driven cultures, they are not the sole factor in making workplaces “smart.” Organizations that have a smart-driven culture, or data-driven culture, also promote innovation. An innovative organization actively encourages creativity, exploration and the pursuit of new ideas, continuously developing and implementing groundbreaking solutions, products and processes. Innovative companies with a culture of learning and growth are often seen as desirable employers and have high employee retention rates, attracting top talent.

    Let’s go over the benefits of a smart-driven culture and how an observability platform can help your company become data-driven in five steps.

    Why is Smart-Driven Culture Important

    You can increase efficiency and productivity among your employees by fostering a smart-driven culture. Smart technologies are able to automate repetitive tasks and streamline processes, which helps free up workers’ time and focus on other issues instead.

    A data-driven culture can also drastically improve decision-making on a company level. Your organization will begin to strategize and act on objective insights rather than guesswork or assumptions. Through collecting, analyzing and interpreting data, you will not only be able to make informed decisions but also know how to optimize processes and mitigate risks.

    Use data to better understand your customers’ preferences and improve your products to meet their demands more effectively. For example, leverage smart technologies and create high-tech touchpoints to tailor each of your customer’s experiences. A culture that encourages continuous learning, experimentation and adaptation is ready to navigate market shifts, changing customer needs and emerging technologies.

    How to Create a Data-Driven Culture in Five Steps

    According to the 2023 Data Analytics Survey conducted by New Vantage Partners, 79.8% of data leaders identified people, business processes and organizational alignment as the principal challenge to becoming data-driven. These folks cited cultural issues, including organizational receptivity to change, communication and organizational alignment, as the greatest obstacles to realizing business value.

    One way to overcome these challenges is by harnessing the power of observability, building data literacy and organizational transformation. Observability refers to the practice of gaining real-time insights into systems, applications, and processes through the collection and analysis of relevant data. Real-time insights will enable your organization to make data-driven decisions, understand your customers better and quickly identify areas of optimization to improve your products.

    These characteristics are fundamental to smart-driven companies, enabling them to stay competitive and drive innovation in the market. Take the following five steps to ensure you’re maximizing the potential of observability and paving the way toward becoming a smart-driven organization:

    1. Define Clear Goals

    Start by defining what a smart-driven culture means for your company. Write down clear outcomes that you want to achieve with a new culture, and identify the specific areas where observability can make a significant impact on your team.

    Focus on areas where real-time insights derived from observability can generate substantial business value. Set SMART (specific, measurable, achievable, relevant and time-bound) goals that can be tracked over time. For example, you could aim to reduce website loading time by 20% in the next two months in order to increase customer conversion.

    2. Implement Robust Observability Tools

    Evaluate and choose observability tools that align with your organization’s specific needs and goals. Look for tools that offer features such as real-time monitoring, log management, distributed tracing, advanced analytics and visualization capabilities.

    Consider factors like scalability, ease of use, integration with existing systems, and the ability to handle diverse data sources. Remember that the availability of accurate and timely insights promotes a culture that values data and encourages performance for achieving business objectives.

    Ask your IT department to help set up your observability tools to gather the relevant data. For our previous example goal of improving website loading times, this will mean gathering real-time data on website performance, such as server response times, page load speeds, and user interactions.

    3. Promote Data Literacy

    Your observability tools are of little help if no one understands how to use and derive helpful insights from the data you gather. Educate all of your employees on good data practices and the role of analytics in decision-making.

    Provide training and support on the data tools you have chosen and encourage your employees to understand, interpret and utilize data effectively in their day-to-day work. For instance, in meetings, you can ask for data points to back up business decisions.

    4. Encourage Collaboration and Knowledge Sharing

    Creating cross-functional teams and encouraging collaboration among different departments, such as IT, operations and analytics, is crucial for the successful implementation of observability practices.

    Taking an interdisciplinary approach allows for a better understanding of the systems and data within the organization. This can lead to the identification of optimization opportunities, help break data silos and practice collective problem-solving as a result.

    5. Iterate and Improve

    Embrace a culture of experimentation and continuous improvement by using observability data to identify areas for optimization and innovation. Encourage teams to test hypotheses, implement changes and measure the impact, fostering a cycle of learning and refinement. Track progress against the goals you set at the beginning and adjust your trajectory if needed.

    Coming back to our goal to improve website loading time. Now that your interdisciplinary team implemented some changes and reduced the loading times, you can assess the impact on user experience and business metrics, such as bounce rates, conversion rates and customer satisfaction.

    Becoming a smart-driven organization will grant you a great competitive advantage. You will make better and faster decisions, employ the best talent, maximize their productivity, and provide an enhanced experience for your customers.

  • How to Build Successful DevOps Teams

    How to Build Successful DevOps Teams

    The DevOps sector is still in urgent need of new talent, with 38% of tech companies stating that they struggle to find skilled developers in 2023. These same respondents named DevOps as the number-one area where they are feeling the pinch. Because of this, businesses must ensure they prioritize and nurture the right set of core skills when building DevOps teams.

    Below, we discuss the key qualities that businesses should look for when taking on new DevOps engineers and what leaders can do to get the most out of existing employees.

    Tech companies that prioritize the development of these skills will be rewarded with an intelligent, inquisitive and high-performing DevOps team, setting themselves apart from competitors.

    An Eagerness to Learn

    The DevOps sector is constantly evolving, so the talent organizations hire should be similarly open to evolution in the way they work.

    Emil Krawczak, DevOps engineer at STX Next, said this is a key trait necessary for success. “To be successful as a DevOps engineer, you need to have a natural thirst for knowledge and desire to develop, and also be highly persistent when faced with challenges. This area of IT is developing so quickly that it’s difficult to keep track of everything new. It is not enough to learn at work; you need to take steps to grow your capabilities outside of the day-to-day, as well.”

    An Analytical and Strategic Approach

    System administration and development skills are essential, but they aren’t enough if developers don’t keep the bigger picture in mind at all times. Therefore, the ability to think strategically and the ability to apply analytical skills are invaluable for DevOps engineers.

    Piotr Pawłowski, DevOps specialist at The One Question, explained how these traits made it easier for engineers to tackle a DevOps project. “Being successful in DevOps means having an analytical mind and taking a strategic approach. First and foremost, you should be to analyze the project and decide the right tools and approaches. You might know a lot about different tools and cloud solutions, but if you don’t know how to use them, you will not be successful in the world of DevOps.”

    Putting DevOps Theory Into Practice

    The ability to put theory into practice is where true progress is made. With that in mind, what DevOps employees glean from training, education, books and research has little relevance unless it is supplemented by practical experience.

    Versatility is an integral skill in the industry, and successful DevOps pros should be able to use—or at least have working knowledge of—a broad range of tools. They should also specialize in at least one area of Dev or Ops. Python is a great example; Python is highly effective in the automation process and the language should be viewed as a key stepping stone in growing DevOps engineering skillsets.

    Identifying Transferrable Skills

    Employers searching for new talent should look for relevant skills in other IT disciplines that could help a candidate make the switch to DevOps. For example, experience in SysOps or a specific programming language can be extremely useful when opting for a change of focus.

    “DevOps unites the world of admins (SysOps) with the world of programmers/developers (Dev). The easiest way to get into DevOps is to have experience in both of these areas,” Krawczak said. “As an admin, you can build on your experience in scripting, and as a developer, you can leverage your experience in setting up local infrastructure for testing.”

    A Clear and Focused Approach to Specialisation

    Marcelo Grebois, senior DevOps Engineer at Toptal, said businesses should keep things as simple as possible when establishing their DevOps approach. “Try to make things easy. Always think about automation, keep all infrastructure ‘as-code’ and stay up-to-date on tools and technologies.”

    Roman Kamiński, cloud system architect at Atos, agreed. “Using automation tools such as Ansible and Terraform, for example, stops developers from getting left behind while helping them adjust to an ever-changing industry.”

    Developing the Next Generation

    It’s important that tech companies invest in the growth of DevOps engineers and help them focus on the skills that will maximize their potential. The organizations that put time and resources into nurturing the next generation of talent will benefit from a larger pool of well-trained engineers. In the long term, this will ease the DevOps skills shortage and make for a more prosperous IT department.

  • Shifting Engineering Priorities for 2022

    Shifting Engineering Priorities for 2022

    Nearly every aspect of the software development process is accelerating, from the increasing speed of programming languages to the expectation of faster delivery. This has resulted in the misconception that speed and efficiency should be a DevOps team’s or engineer’s top priority. Though agile transformations have been a central strategy for most organizations in recent years, investing in team culture while undergoing an agile overhaul is paramount to overall success.

    For many workers, the pandemic caused a shift in priorities, so much so that as we begin to emerge from the events of the last two years, almost a quarter of UK workers are planning job changes and businesses are tackling the so-called Great Resignation. A desire to improve work-life balance and enjoy better benefits like flexible working has made employees more likely to leave a job. As such, maintaining employee satisfaction and protecting team mental health should be a top priority for companies wanting to keep retention rates high.

    This starts with leadership, and engineering and DevOps leaders must have full transparency into their teams, with an understanding of exactly what motivates them. With this in mind, here are three top priorities for engineering and DevOps leaders in 2022.

    1. Prioritize Team Culture

    The tech sector is notorious for a high employee turnover rate, with a LinkedIn report putting it at 13.2%, far above other industries. For engineers especially, the increased pressure to deliver at lightning speed has created an unsustainable “churn and burn” culture.

    Simultaneously, engineers have no shortage of options when it comes to job prospects as demand is booming. In fact, this particular sector in England and Wales advertised more job vacancies in 2021 than all British businesses across 2020.

    To avoid any leavers, it’s important for engineering leaders to establish a unique and engaging culture within their teams, and actively and continuously examine it to ensure that engineers feel supported and valued.

    However, there are a few key principles shared across world-class engineering teams. Allowing engineers to work on projects that excite them and allow them to explore their creativity is crucial. This may involve giving them dedicated time to work on developing their skills and pursuing innovative projects. In addition, leaders should cultivate a culture for their engineering teams that is built around appreciation, collaboration and psychological safety. Weaving open and honest career discussion and satisfaction check-ins into one-on-one meetings will help employees feel listened to and motivated by their personal progression.

    2. Use Data as Your Gut Check

    Ensuring decisions are data-driven is also incredibly important. The best leaders are often those who use concrete evidence to strengthen their teams. Engineering leaders must use data and metrics to gauge the health of their teams in the current jobs landscape.

    Even for engineering leaders, a team’s day-to-day programming can sometimes seem like a black box, so finding clear insights about the development process is imperative. With an engineering metrics solution, it is possible to obtain better visibility into your team’s workflow. This not only helps ensure efficiency and quality, but it can also help to gauge employee success and morale.

    Continuous health monitoring using a robust set of metrics will provide leaders with early identification and help to resolve any friction. A data-driven platform to ensure that individuals’ contributions are ‘seen’ is fundamental. Monitoring a teams’ daily workflow helps to identify standout employees that may otherwise fly under the radar, as well as flagging those who may be struggling. It’s important to pay particular attention to metrics that drive employees toward their professional goals and help to remove bottlenecks across teams.

    Prioritizing constructive feedback and one-on-one conversations with employees is crucial to employee success and retention. The focus must be on frequent check-ins with engineers to ensure that they are thriving personally and professionally.

    3. Focus on People First, Rather Than Performance

    Nothing will ever be as important within a team as the people. Only the engineering and DevOps leaders who prioritize people through a variety of tools and techniques will reap the rewards and stay ahead of the competition.

    Recent research has shown that happy employees are up to 12% more productive.

    An engineering team will deliver their best work when they feel encouraged by leaders, have the space and autonomy to work in a meaningful way and have accomplishments acknowledged and celebrated.

    As leaders, it is critical to remember to check in with team members as people, before checking in with them as workers.

    Engineering leaders will likely be battling for in-demand talent in 2022 and beyond as they continue to contend with the Great Resignation. In the face of this, there is a real opportunity for leaders to distinguish teams through their engineering culture. Whether you are cognizant of it or not, a team has a culture. It’s incumbent upon engineering leaders to make having a people-first culture the top priority in 2022.

  • 3 Ways to Support DevOps Teams in Remote Work

    3 Ways to Support DevOps Teams in Remote Work

    As we settle into remote work for the long haul, it’s crucial to consider how best to support DevOps teams. While DevOps employees face similar challenges working remotely as any other department, they also face increased pressure to deliver as IT professionals, supporting the entire organization through an ever-changing work environment.

    By nature, remote work makes it more difficult for your DevOps team to do their jobs. Team members are working in various environments, but also distributed across geographies. And in this new frontier, DevOps must provide service as usual, continuing their development projects and ensuring communication and alignment among departments when it comes to the organization’s technology and IT needs.

    Even more, in a distributed, remote workforce, disruptions to application performance and security issues are more likely to occur and DevOps professionals must be equipped to identify and correct them quickly. For these reasons, it’s critical that these teams have the right tools and support to remain operational, communicate effectively across departments and neutralize threats—keeping applications and the organization running.

    How to Support Remote DevOps Teams

    Remote success looks different for every DevOps team based on organization size, industry and business need. However, the following strategies can be applied universally and may even serve as building blocks on technological foundations you already have in place:

    • Continue migrating operations to the cloud. Your cloud infrastructure is the backbone of any remote support plans for DevOps teams. Migrating operations to the cloud is the biggest enabler in making sure your team is not tied to any physical location and can do their jobs without relying on a single data center or headquarters. For example, deploying your open source data infrastructure in public clouds not only makes it easier for team members to access the data but also increases developer and operational velocity, which accelerates application innovation. While most organizations are well into their migration to the cloud, it’s critical to accelerate the process to expand across more operational areas. Traditional work environments likely won’t return to fully in-office experiences. Rather, many organizations will implement a hybrid working model. Refining and expanding your cloud infrastructure will help you make that transition and continue supporting an in-office, remote or hybrid team in the future.
    • Automate security and performance monitoring. DevOps teams are under pressure to scale solutions for remote work, such as company VPNs for network access and secure application logins. They must also be alerted to and able to track any security issues that arose during the hasty transition to remote work. Automated monitoring of software performance and trends keeps teams ahead of threats and minimizes deployment issues. The software sends alerts and allows teams to view data in real-time. Even more, machine learning technology can analyze the data and identify trends about application performance, the cloud environment and data usage. This level of monitoring and analysis is only possible with automation and makes it much easier for DevOps teams to meet IT service requirements as the remote technology landscape rapidly changes.
    • Increase communication and collaboration efforts. It’s crucial that DevOps teams are in constant communication with key departments across the organization, including security and executive leadership, as well as with other employees to discuss what’s working and what needs to become a priority for change. To help support knowledge sharing across a remote team, first ensure you communicate all application metrics clearly so every member of the team understands and is aligned on projects and next steps. Dashboards can help in this arena, collecting and converting key data points into visuals. And while you can easily create and host meetings with conference calls and video conferencing software, informal face-to-face conversations are harder to re-create—and that’s where ideas are born. To combat this loss, arrange for non-structured discussions without strict agendas or topics to encourage idea sharing, creativity and inspiration among employees.

    Remote work has broken down the traditional DevOps team structure, but this new way of work provides an opportunity to build something better—more time for independent, focused work, a superior work-life balance and modern cloud-based solutions for daily tasks. Supporting DevOps teams as they grapple with the new pressures of remote work is the key to ensuring your organization runs smoothly during the transition—cloud infrastructure, automation and communication are just a few of the strategies to do so. 

  • How To Foster a Culture of Citizen Developers

    How To Foster a Culture of Citizen Developers

    What can leaders do to encourage a thriving environment of citizen developers in their organization?

    Over the last several months, businesses of all sizes have had to embrace rapid change, as have their workforces. When it comes to IT departments, even before the pandemic many were fielding requests to implement new technology, customize solutions to niche problems and automate specific tasks at rapid rates. Unfortunately, these increased demands coincide with an ongoing developer drought, and paired with the pandemic, have put an added strain on some already thinly stretched IT teams.

    As a result, there has been an observable rise in citizen developers being tapped to relieve some of this burden. “Citizen developer” here is used to describe any programming novice or non-developer who has been tasked with the responsibility of constructing custom applications. This person has some familiarity with programming but may not have been formally trained and, therefore, may use their own set of tools and workarounds to complete the work. If leaders don’t make an effort to create standardization, the consequence can be high variability in quality, efficiency and output.

    And it doesn’t seem to be a passing phase. I recently spoke with Dave Garrett, chief strategy and growth officer at Project Management Institute. As we look to the future, Garrett believes that citizen developers will play a critical role in helping organizations stay agile and ensuring projects move forward without delay.

    Though it won’t solve all of your pressing technical concerns, the good news is that with smart strategies, a citizen development emphasis can ease the burden on IT teams and improve output. Garrett spoke to a sea change of new techniques being developed to respond to these growing needs.

    4 Elements of Strong Citizen Developers Culture

    1. Standard Toolsets

    To start, build a solid foundation by choosing standard toolsets. Be sure all development staff is made aware of the toolsets you’ve deemed standard, clarify that adopting them is a priority and ensure that all have access. Standard approaches to using these tools should also be established and communicated, such as programming languages and stylistic standards.

    “If you have a standard toolset and approach, then you have many people who can help,” Garrett said, emphasizing that by doing so, you are building a broader base of support. Having a larger pool of employees to pull from helps an organization stay on top of the necessary tasks and creates more freedom for open collaboration. As a bonus, professional developers are freed to focus on more advanced tasks, such as machine learning and or mathematically complex programming.

    In deciding which toolsets and approaches to make standard, Garrett said, ask yourself, What will get them from A to B most quickly and efficiently? One approach to this is low-code or no-code tools. He considers such platforms transformational in empowering citizen developers to express ideas tangibly without a great deal of coding.

    2. Technical Training

    From here, ensure that all development staff, especially your citizen developers, have been technically trained in adopting the standard toolsets and approaches that have now been established. This may include offering training in low-code UIs and instilling fundamental programming concepts such as boolean logic and conditional programming such as If/Then/Else statements.

    “Set a foundation of success for learners,” he said. For example, have them build something of value during training, making it as actionable as possible for the use cases they will be handling.

    3. Discouraging Use of Shadow IT

    Once you have established toolsets and training, leadership should do whatever’s possible to enforce the established standard’s adoption and discourage the use of shadow IT—tools, applications and workarounds not approved by leadership within the company. Shadow IT, as a practice, can be messy, creating high variability and making quality-control and collaboration difficult. “You want to avoid it,” Garrett said.

    4. Good Mentorship and Governance

    Another benefit of having a standard toolset and eliminating shadow IT use is that it enables more efficient mentorship—critical for inspiring citizen developers. IT teams are advised to identify a mentor or group of mentors proficient with the standard tools to offer ongoing guidance to the team’s citizen developers.

    Quality mentorship goes hand in hand with quality governance. “Governance” here is used to mean technical admins who enforce the use of technical standards, tools and programming styles. No-code tools require access control that reflects a citizen developer’s permissions.

    Building in Hyper Agility + The Two-Pizza Rule 🍕🍕

    One way to think, Garrett said, is hyper agile. This can apply to team size, smart PM cycle lengths and brainstorming techniques.

    Team Size

    In thinking of ideal team size, ask: How can the team be optimized to work quickly and efficiently? One suggestion Garrett had was to ensure your team isn’t too large to effectively train, mentor and govern. For example, as a rule of thumb, he mentioned the old “two pizzas” rule: A team size shouldn’t require more than two pizzas to share a meal.

    Sigh. Remember things like in-person training? Pizza parties? Obviously, old meetups can’t be executed exactly to plan these days, except with some clever contactless delivery tactics, but you get the idea. A strategically sized team will create an efficient workflow and collaboration in your team dynamics.

    Cycle Length

    As projects come in, an agile cycle length, or sprint, for completing a specific set of work should be determined. What is an efficient amount of time to expect a team to turn out a project? To determine this, sprints should start with a planning meeting during which the product owner defines the work criteria. The development team determines a realistic time frame to complete the work scope. The scrum master or team manager typically makes this call.

    The lengths of agile sprints can vary—some may be two weeks, while others may be 30 days—depending on the scope of work. Most project management experts recommend you aim to keep your cycle length consistent, so teams get used to working within a set amount of time.

    Brainstorming

    Bringing attention to how your team ideates together is an excellent way to build agile collaboration. Brainstorming as a development team fosters collaboration and allows you to aggregate the talent and pull ideas together for the best output, whether you’re trying to solve a niche problem or simply join forces around how best to complete the sprint.

    Garrett recommended bringing people together in smaller groups for round-robin brainstorms and creating as you’re ideating. “Thus, iterations happen fast,” and all team members are given a chance to express their ideas in a tangible way.

    Once citizen developers see success, you can then use the excitement of building applications and solutions together to drive things forward, he said. Your anchor is a cool product that gets people excited—great for both morality and high-quality output.

    When Are Citizen Developers Appropriate?

    The question should be asked: When is it appropriate to call on citizen developers? Garrett recommended performing a suitability assessment to identify the best use cases for citizen developers. This will help the organization understand when it’s smartest to bring them in.

    The easiest way to answer this may be to consider: When isn’t it appropriate? Assigning advanced processes to citizen developers such as algorithm-heavy, mathematically complex programming or core product functionality is usually inappropriate, he said. Instead, utilize citizen developer talent for constructing internal business utilities that can be automated easily.

    There are formal suitability assessment tools that look at scores and attributes for applications to help you make this call. “However, everyone’s different,” Garrett noted. “You have your own ways of working, given context, goals and what you’re trying to accomplish.” So it may make the most sense to perform your own internal suitability assessment.

    Do the Numbers

    According to a recent PMI report, over the past five years half of organizations have recognized team members who brought innovative ideas forward, but:

    • Only 25% required dedicated time for innovative thinking and idea generation.
    • Only 19% hosted a creativity lab or hackathon facilitated by a professional.

    By contrast, their research shows that those promoting innovative practices see stronger results. Case in point:

    • 80% of organizations that encourage project leaders to expand their role have invested in at least one innovative idea in the past five years.

    The trend PMI sees on this front is that organizations want to innovate, but don’t always know how to make it happen. So, how might they push innovation forward? If you can implement a strong citizen development toolset, you can “enable innovation to bubble up,” Garrett said. The hope is this guide offers a blueprint for fostering just that.

  • 5 Team Skills That Make DevOps a Success

    5 Team Skills That Make DevOps a Success

    When starting their DevOps journey, your team will discover it needs to develop some new skills. Most likely the team is good at typing code and solving issues, but what about the soft skills?

    Many teams have to learn how to deal with issues themselves—as self-supporting teams, there is no longer a manager who will help them out and tell them what to do.

    During the Phoenix Project DevOps business simulation, the majority of teams discover collaboration and communication are skills they lack. I am often surprised how few people can really facilitate standups, retrospectives, Andon-sessions and other communication methods.

    Here are the five team skills that participants recognize as core skills they learn (or could learn) during the simulation.

    The Standup

    The standup is a very powerful way to share knowledge about certain issues. The team will stand together for a short time and discuss an issue that blocks the flow, needs clarification or needs to be high priority. So, who should initiate this standup and who should lead it? I’ve noticed a lot of participants find it very difficult to manage this standup initally, but after a few times the team discovers the key elements of a successful standup:

    • Chose a facilitator. Someone who is leading this session. It doesn’t matter who (it doesn’t have to be a manager).
    • Share the focus: What are we going to talk about?
    • Keep it short (time is ticking).
    • Make sure we all understand the outcome.
    • The importance of listening and engagement.

    Facilitating a Retrospective Session

    DevOps is also about continuous learning and experimenting. One of the important steps in this process is retrospective. This activity explores the past round of work and reviews what went OK and what needs to be improved. Again, during the simulations I discovered that not many participants know how to execute this activity. After being shown the right example, the team often can perform this activity themselves. This is what teams learned during the simulation:

    • Someone from the team must facilitate this process.
    • Make sure the improvement is supported and understood by the whole team.
    • Test the improvement before to applying it.
    • Record the discoveries—this becomes part of the visual management system and part of the team backlog of improvement needs.
    • This team skill is one of the skills that more than one team member should be able to execute.

    Managing the KanBan

    During a project, teams sometimes will have standup moments to discuss the work visualized on their KanBan. Work will move from backlog to doing and done, and new priorities will change the order of work. During the simulation participants will take the lead in this process, but some don’t find this easy. After the sessions they discover:

    • Use standups to discuss the changes on the KanBan, make sure the team is fully involved when moving notes around.
    • Challenge participants to share their thoughts. Saying “yes” doesn’t always mean “yes.”
    • Errors are made, but that doesn’t mean somebody has failed and should be punished. Keep the session safe and open.
    • The KanBan is a form of visual management system (VMS). The VMS is not the goal—it is an instrument and must help the team to visualize flow, limit work in progress, drive productivity through an awareness of what people are working on and continuously improve the process.
    • Make sure at the end of the session, all participants know what’s agreed.

    Managing an ‘Andon’ Session

    ‘Andon’ is a very powerful instrument to explore a situation that stopped the flow. As soon as the flow stops, someone “pulls the rope” and the team “swarms around” to investigate the error and try to continue the flow as quickly as possible. This session should be led by a team member; it doesn’t matter who. During this session, the team discovers the following learning:

    • Make sure the session is short and focused on fixing this blockage and restarting the flow.
    • Make sure we are not blaming each other; it should be about exploring what stopped the flow, fixing it and agreeing how to prevent it from happening again.
    • Make sure the whole teams swarms around and participates.
    • Create a safe environment.

    Collaboration

    Doing the work is not always easy. Sometimes we don’t know what to do. Sometimes we need help, and sometimes we are not happy with the actions of a team member. This is what collaboration is all about.

    One of the first aspects of collaboration is helping each other. But, this is not always effective. Sometimes it’s even disruptive or we just take some work from somebody else if we think he is too busy. Here’s what participants learned about collaboration during the simulation:

    • We have to avoid “compensational behavior.” This is about taking other people’s work with the intention to help the other. Sometimes this person doesn’t know you took the work and he or she does it again, creating unnecessary double work.
    • Collaboration is about shared goals and shared processes. We should all know what we are doing and how.
    • It’s also about clear roles and responsibilities. If you know what your colleague is doing, you know what you have to do. And the other way around.
    • You must have an open team culture in which it is also safe to say you don’t know and to ask for help.
    • Collaboration is fun, and it gives energy if we as a team achieves something.

    Conclusion

    I have visited many global DevOps conferences in the previous years and have listened to numerous speakers declaring, “It’s all about people.” And they were right. Unfortunately, the audience often did not get many useful answers.

    A high-performing collaborative team needs team players who know how to deal with the collaboration and communication issues themselves without needing management intervention.

    Teams will have to go through the stages made famous by Bruce Wayne Tuckman (Forming, Storming, Norming, Performing and Adjourning) to become an effective, collaborative team.

    Continuous learning is a key success factor and a critical competency for any DevOps team. Why not start this learning journey in a safe and challenging environment?

    A simulation such as the Phoenix Project is a very powerful instrument to teach teams how to collaborate and become high-performing. The environment is safe and feels like the real work environment. Participating in this simulation with an actual team allows you to capture and agree on actions to takeaway. Outcomes can easily be transferred to day-to-day work.

    I wish you a lot of soft skills.

    About the Author / Jan Schilt

    Jan Schilt is owner of GamingWorks. His background is Human Resource Development (MSc). Within GamingWorks he is responsible for Business Simulation design, Facilitation and Train the Trainer. He is also an expert in developing learning activities related to organizational change. He builds all the simulations and has delivered more than 300 workshops worldwide.

     

     

     

  • Can Culture Detract from Success with DevOps?

    Can Culture Detract from Success with DevOps?

    Collaborative culture is considered to be an essential best practice for enterprises. DevOps culture correlates strongly with enterprises that achieve the highest level of business performance. However, is it possible that an organization can get overly fixated on organizational culture improvements? Can culture actually detract from achieving success with an enterprise DevOps transformation?

    An article by Curtis Franklin Jr.,”8 ways to fail at DevOps,” indicated that there are “plenty of places in the DevOps process where an organization can run aground on rocky shoals of woe.” My blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps. One of the seven pillars is collaborative culture. These pillars are not silos, but rather foundations that need to be kept in balance.

    I bet most of us have experienced situations in which cultural improvement missteps hindered an enterprise DevOps transformation.

    Culture Missteps

    I’ve listed some examples l below which I have personally seen. Have you experienced these? I would love to hear examples of your experiences and solutions you have observed, too.

    1. Unrealistic expectations from leadership: Business expectations from leadership get too far ahead of the DevOps implementation reality—then teams reporting to leadership end up feeling unappreciated and experience frustration, resulting in organizational friction.
    2. Ops-side transformations fall behind Dev-side transformations: The Dev team accelerates ahead of the Ops team and implements “its part” of a DevOps transformation before the Ops team has a chance to implement complementary changes. The Dev-side is disappointed that Ops has not kept up with the complementary Ops-side planned changes. Dev changes cannot be put into effect, which deepens the mistrust between Dev and Ops.
    3. Dev-side transformations fall behind Ops-side transformations: This is the reverse of the second example, with similar effects.
    4. QA tester roles are confusing: When new continuous test strategies are implemented, the lines of test responsibilities between Dev, QA and Ops team members became blurred. Communication between cross-functional team members become confused, resulting in misunderstandings, dissatisfaction and organizational friction, which obstructs progress.
    5. Infrastructure and tools teams are siloed: Dev, QA and Ops teams maintain separate, siloed tools and infrastructure staff and do not cooperate to support end-to-end infrastructure and tools improvements. The transformation needed for a smooth DevOps pipeline stalls.
    6. Rewards and measures are not consistent with DevOps goals: The organization makes changes toward a cooperative culture but fails to change the way people are rewarded and measured. Conflict results between the teams.

    Solutions

    Below are solutions that were applied to the situations listed above. Do you agree with these solutions, or have others to suggest?

    1. Leaders were coached to be more aware that DevOps transformation is a journey of continuous improvement. Leaders then understood that there is really no “end state” to DevOps—there are specific business improvements that can be expected along the way. Each DevOps improvement initiative was refocused on realistic specific use cases and goals. With improved clarity, leaders were more realistic in their expectations for each improvement. This drove alignment between leaders and their teams, improved satisfaction and productivity.
    2. Project goals and team meetings were realigned and organized. Dev and Ops sides could monitor end-to-end progress together. When situations occurred in which one team got ahead of the other, the end-to-end progress visibility helped overall group communication. Empathy across the Dev, Ops and QA teams improved. With improved communication, team members celebrated the success of each other’s improvements. Teams shared a common end-to-end goal.
    3. Same as 2.
    4. QA testing responsibilities changed significantly during the DevOps transformation. Separate independent test team member responsibilities changed toward QA testers being more integrated with Dev teams. New skills requirements for the QA engineers emphasized test automation more than in the past. Training for the cross-functional team helped mitigate concerns related to the new QA responsibilities. QA testers were uplifted with new skills and became more valuable and respected by their peers. Cross-functional productivity improved.
    5. The tools and infrastructure teams from the separate Dev, QA and Ops teams were combined into a common tools and infrastructure team. Project goals were realigned. The improved clarity around knowing they are working toward tools and infrastructures for a common end-to-end pipeline accelerated implementation of DevOps.
    6. Rewards and measures that had been in place for separate Dev, QA and Ops roles were changed to rewards and measures that encouraged end-to-end cross-functional team activities. This improved overall morale and job satisfaction and reduced organizational friction that was previously impacting progress.

    Summary

    From the above real-life examples, it is clear to me that culture and organizational practices must evolve in concert with progress on other DevOps pillars. And as the pace of change increases with each transformation, the cross-functional teams must be even more cohesive. Continuous acceleration of interactions between team members drives the need for tighter relationships, more end-to-end responsibilities, improved customer awareness, continuous skills training and end-goal focused leadership.

    The is no need to create the “perfect culture” before starting a DevOps transformation journey. It can be counterproductive for sections of the culture to get too far ahead of itself, as indicated in the examples above. Perhaps it is best to evolve the culture carefully. Changes most important for each transformation project should be the focus. Continuously communicate goals and progress, and evolve the culture together with evolution of other pillars. What do you think? Do you agree is it possible that an organization can get overly fixated on overall organizational culture improvements?

    While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all of their IT systems.

  • The complexity of communication: Are we all Masters of Disaster?

    The complexity of communication: Are we all Masters of Disaster?

    To better the communication between people in tech teams is one important issue in daily work. Although we all grew up with communication from our early childhood on, we know, that communication often fails. But what do we all do about this discrepancy? Why do we accept eyes wide open these frequently painful failures? Why don´t we really care about misunderstandings and their consequences? Are we all Masters of Disaster?

    The answer is: Communication is a very complex topic on both sides of the game – on the sender´s side as well as on the receiver´s. To get aware of what is going wrong in our communication we have to do some very hard stuff: self-reflexion (which is indeed sometimes painful and hard to bear), changing familiar behaviors and leaving the comfort zone. This is really hard work besides all the tasks of our daily job! Additionally to a strong will, we need persistence, patience and most of the time aid from the outside to be successful in changing our communication! But in the end this entire struggle is worth it!

    In DevOps teams, where “ship fast” is taken over from “ship faster” to fulfill the goals of “continuous of everything”, a well accepted and effective, but appreciating communication is the basic skill for success. This means that building a successful team is comparable with building a house: if you spend enough in a strong and solid fundament, it will carry the house you want to build on it for a long, long time. But you have to consider, which kind of house you want to build to develop the fundament.

    In cross-functional teams with high demands – those teams we actually find in the tech industry – communication is the fundament of whatever is built on it. Communication is part of the culture and it is the tool

    • people get in contact with each other
    • knowledge is shared
    • goals and visions are shared
    • feedback is given
    • failures and success are shared
    • appreciation is shown.

    People in such demanding environments need to trust and rely on each other. Or do you want to share your knowledge with someone you do not trust? The success of the team depends on the relationships between all teammates including the leader. Relationship and trust are built among other things through the way we communicate with each other. No it is time to say, that communication is not only what we are saying with the words we are using. Communication goes far beyond the meaning of the words. Remember “Cce” – Communication causes emotions! Even in the tech world, which is still a male dominated world, communication causes emotions and feelings – although lot of people may refuse this.

    With speaking about the complexity of communication it means that there are on the one hand three different parts of sending a message and the impact on the receiver. On the other hand there are lots of possibilities how to interpret the messages. Lots of possibilities – this seem to be a source for many misunderstandings! Now be aware that an immense part of our communication – sending as well as receiving – happens in our subconscious!

    Most probably you have heard about the three different parts of communication: the verbal communication and the nonverbal communication with its subitems ´paraverbal communicationand ´body language.

    The verbal communication is about the wording, the language, the syntax, the grammar and yes, it is also about the logic! There you are: “Things have to be logical, then everything is fine, isn´t it?” Sorry, but: “No, it isn´t!” It is even not half of the truth. Here is the reason, why so called one-track specialists often have problems to convince others, although everything they say is absolutely right and logical. At this point the nonverbal communication appears on the human playing area! The paraverbal part of communication contains facts like the volume, the speech rate and melody, the intonation and articulation and at least the tone of the voice. This is completed by the body language with the fascial expressions the gestures, the body posture, eye contact, body chemistry and the clothing. If the expression of all three components is the same – then everything is fine! If the verbal communication says “YES” and the nonverbal communication “NO” – then people tend to believe in the nonverbal communication because its impact is much higher than the impact of the words.

    Just one example at the end: at one of the DevOpsDays I have joined this year, I saw one young speaker. I guess, he is really an expert in his topic and the idea and content of his talk was excellent. But he didn´t manage to appear convincing and convinced: a wrinkled shirt, a loose jeans, unkempt hair, barefoot in his sandals, a lousy body posture and a bored facial expression. You can say that this is a superficial point of view. Maybe – but that is the way it works! Communication always needs a holistic approach – and seemingly superficial points of view are influencing the our feelings and the way we interpret messages! Or to say it the other way round: if you want to convince somebody and make her/him trust you, you have to focus on all parts of communication! It is the same when you want

    to share knowledge, give feedback or want to lead a team. Communication is more than just the words!

    In the next blog post you will read about the chain of communication!

  • Building a Winning Software “A-Team” with DevOps

    Building a Winning Software “A-Team” with DevOps

    The 1980’s TV show The A-team was brilliant. Four ex-commandos with special skills who help the oppressed. Throw in some over-the-top violence where no-one gets hurt, together with some tech wizardry where the team magically create weapons out of old spare parts. Add a catchy theme tune – and voila – classic viewing.

    In many ways agile software development teams want the autonomy portrayed by the A-team. And why not? Let’s bring together small teams of bad-ass code junkies. Provide them with enough open source software to build, integrate and deploy virtually anything. While we’re at it, give them the power to smash all the evil villains’ conspiring to prevent the rapid release of software for the oppressed business – like out-of-touch operations, process-crazy service management, or security and compliance police.

    So on the face of it our A-Team looks like an IT winner. They save the day and no-one gets injured, right? Well not exactly.

    When Agile Autonomy meets an Immovable Object

    Autonomy is both a blessing and a curse. On the one hand, letting teams self-organize and self-manage without outside interference seems like a productivity no-brainer. However, when team autonomy descends into selfish technology-centric rants over rational program level thinking, all hell can break loose. Suddenly every team has access to a plethora of super open source tools — need a document style database for your new Python coded microservice? No problem, click here to download, quickly brush up by reading some appdeveloper articles, and hey presto you’re off and running. Rinse and repeat for different programming languages, build tools, code versioning, configuration management and your teams are all swimming in a fast river of technical goodness where considerations about resilience, performance and security can be easily lost.

    The only problem is that the river flows down to where it eventually meets guess who – all those out-of-touch operations folks, process crazies, and security guards. Not surprisingly, they view this last minute technical deluge with a more cautionary eye. And since they’re compensated and rewarded on preventing problems, security issues and compliance exposures, they’re not going let any software pass freely into production – well, not without a fight anyway.

    And herein lies the problem with the autonomous A-Team. The “A” suddenly becomes more associated with adversarial engagement than anything remotely agile. So cue delays and the business being ticked off yet again with IT.

    Lessons from the Art World – Rembrandt and Stradivarius

    DevOps with its focus on team collaboration aims to channel the healthy tension existing between Dev and Ops into business goodness. This starts by understanding how and where to engage all that natural team angst.

    There’s a classic old sketch from the late British comedian, Tommy Cooper — who walks on stage with a painting and violin, proclaiming – “I bought a Rembrandt and a Stradivarius – the only problem is Rembrandt made lousy violins and Stradivarius couldn’t paint”.  He then smashes the violin into the painting – hilarious.

    In development we have our own Stradivarius’ who write great code, but have little appreciation on what makes a “complete” system. They can add all functional bells and whistles, but when it comes to compliance, resilience and supportability, forget it – they’re like the maestro violin maker with a paintbrush – pretty crap. Worse still, the only time they get to learn is when they’re forced to slug it out during a gated security review or regulatory compliance session – this usually doesn’t end well.

    These issues may be resolved when development, operations and other stakeholders engage much earlier in the software development lifecycle. Here as requirements are established and code begins to take shape, stakeholders can work with development; guiding them on what’s needed for the software to become more secure, perform optimally and be a breeze to support.  For starters, this has to include IT Operations sharing years of expertise – like how to exploit monitoring tools in pre-production to equip developers with an early warning system on performance issues as they code, or explaining what’s needed to support new distributed architectures at scale.

    Engage Early and Broadly for Success at Scale

    Beyond operations, there are many other IT and non-IT stakeholders who should be drafted into the A-Team.

    When working on a new web to back-end system integration for example, security could advise development on end-to-end transaction tracing and static-code analysis techniques to help detect code or SQL vulnerabilities. In an API project, threat teams should engage early to model and mitigate against many new attack vectors that hackers can exploit, providing advice on strong, API-specific infrastructure and management. Naturally, if your team is doing anything with mobile payments you better hunker down early with the security and PCI compliance team – or if the agile team has devised some neat sensor, software and cloud technologies to capture and analyze customer-centric data ala the Internet of Things, then early involvement with the legal department on privacy gotchas is a must.

    Large scale success from agile teams can be realized when those teams become less feral about their own individual needs and more focused on supporting business objectives at a program level. To this end, and whatever the makeup of individual teams, it’s vital to establish DevOps style collaboration early in the lifecycle; engaging all business and IT stakeholders in order to establish resilience, quality, security and even supportability into the fabric of software as its developed.

    Do this and you’ll deliver great software without ever having to compromise speed. Fail, and your agile efforts may just stutter and fail – of course you’ll still have an A-Team, but the “A” now stands for something far less complementary!

  • Dice Breakers: using DevOps principles and nerdery to reimagine Team building

    Dice Breakers: using DevOps principles and nerdery to reimagine Team building

    Software is a young industry, and not a very traditional one. Your team can’t always be expected to behave like teams in other fields.

    So it’s no surprise that when a development team hears the phrase, “teambuilding exercises” for most of them it conjures up the idea of a room full of awkward people marginally engaged in a trite set of activities.

    But given the resonance of ideas like DevOps it is apparent that the benefits of teambuilding are still sorely needed. Software companies can fall into a very ‘silo’ed mentality.  This is often to our detriment, and tearing down those barriers is a big part of a DevOps philosophy.

    So there is an impasse; prepackaged, standardized teambuilding exercises fall short of a development team’s needs, and the need for the lessons those exercises try to get across is unmet.

    Last year, when I was working on Release! the Game, I realized something; the things we do outside of work, still resonate inside of work.  That led me to think that Office Game Nights might be an interesting, albeit nerdy,  solution to this issue. But before I explain my dice driven solution, let’s talk a little about traditional team building.

    Classic Teambuildingtrust-catch

    For the sake of discussion let’s say that by and large teambuilding activities all have a similar set of goals:

    • Encourage communication
    • Create easy references for actual on the job problem solving
    • Relieve stress
    • Provides a structure for complaints and socializing

    How they try to accomplish this varies, but as a general rule they set forward an infrastructure for interaction that is easily explained, and with a mechanic for comparison to the real work day.

    For example, in the classic Trust Fall exercise, one person is called out, to fall backwards while their team is called to catch them. Takes a minute to explain, and the concept that we have to rely on and trust our coworkers is applicable almost everywhere.

    It’s a fairly simple formula, get the whole office together, present a challenge, collaborate to meet it, and then discuss the vagaries of how you worked together. Your team bonds a bit, and gets some reinforcement on general work principles.

    Why doesn’t that work for Softwareliz-lemon-giphy

    In the case of software development teams we actually wind up seeing these results:

    • Sighs, scoffing, and somewhere in the dozens of eye rolls, depending on team size
    • Some variation on the phrase, “I could be getting real work done now.”
    • Some variation on the phrase, “At least I’m not doing real work right now.”
    • One or two sincerely interested participants

    Why?

    Whatever your place on a development team your job will revolve around creating or manipulating complex logic chains to overcome some hurdle.  This, in and of itself, is not that much different from any other job, the difference is code.

    Code is abstracted, it is just the logic. Code doesn’t need a teambuilding exercise it just needs to be formed correctly, tested reliably and it just works. If it has a problem, communication or otherwise, there is a distinct and detectable source of that issue, and one that, most of the time, has a methodical solution.

    That’s a simplified explanation, but the key there is that there is an identifiable problem, and an identifiable solution. That just isn’t the case for the social systems that operate outside of the code. Navigating the personalities and relationships that form in a workplace simply doesn’t have the same amount of landmarks that navigating code does.

    The pit fall is in thinking that the software you produce, and your company are the same creature, or at least have the same needs.

    Teambuilding isn’t about the product. It’s about establishing a better system for the people who work on that software, and helping them make the connections that will make production run smoother.

    Teambuilding and DevOps

    DevOps principles demand strong communication between the members of your team. The tools, the methodologies, all need the right environment to be applied in.

    So if you want to build a team that can really talk to each other, you need to step away from the standardized techniques, and pick up some new tools.

    For team building ideologies to function they require a sincere investment on the part of the participants, but, in most cases, they are so pre-packaged that the exercises themselves lack sincerity.

    Openly acknowledge the goals that your teambuilding program is trying to achieve and don’t couch it in the window dressing of corporate training. There are plenty of structured activities that get folks talking, let them blow off some steam, and foster a sense of teamwork that can be easily reflected during your regularly scheduled workday.

    My Answer?game-shelf

    (spoiler alert: this is where it gets nerdier)

    Board games: sweet dice rolling, card shuffling goodness.

    Game nights (or days) are a great place to do some socializing, have a necessary structure around that socializing, and encourage creative problem solving either through cooperation, or competition. There are also a lot of them. The landscape of modern tabletop nerdery isn’t just defined by Napoleonic conflict, or real estate monopolies, there really is something for everyone.

    Setting up some gaming is pretty simple. Set aside a few hours, pick out a game or two, pick up and pizza or two, and get a few coworkers on board. Don’t worry if everyone doesn’t jump on board, give it a few iterations to build steam.

    Here you can take a lesson from a DevOps release strategy, if your first night didn’t achieve your results, try again with some small updates, a new game, different toppings, etc…

    Chances are someone in your office already is into games, especially in the software fields. But, if not, don’t worry it’s pretty easy to get nerds on the hook.