devopsy.kinsta.cloud

Tag: team building

  • A Developer’s Guide to Building Healthy Teams

    A Developer’s Guide to Building Healthy Teams

    To build a great software product, teamwork must extend across developers, managers and executives. Everyone needs to understand each role’s value–you can’t have an effective team without a good coach and vice versa. It takes a culture built on empathy, trust and shared responsibility with the right amount of ambition and personal connection to make the dream work.

    It isn’t easy to achieve this balance, but here are some tips to help your team become healthier and more effective.

    Watch out for Knowledge Silos 

    When too much unique knowledge is stored in one person’s brain, your ability to get things done depends on their capacity, which can jeopardize the team and the entire organization. Some silos can be good, but only when everyone on the team knows what’s in each one and how to access the information. 

    Knowledge silos can take several forms: 

    • Technical skills, like being the only one on the team to know Go or Python.
    • Ancillary knowledge in some field, like a background in statistics.
    • Historical knowledge, like a developer who has been there from the beginning and knows the whole codebase. 
    • Institutional knowledge, like understanding larger business and project strategy and the history of the company. 

    There are some great hacks for overcoming knowledge silos. Simple awareness of who is good at what–or what background everyone has–is a great place to start. Leaders can then think creatively about team collaboration like pair programming or assigning pull requests based on each individual’s knowledge. Pushing each developer to assess their own silos can help set the team up for better knowledge sharing during impromptu sessions or scheduled meetings. Prioritizing documentation is a good way to ensure developers share what they know. Additionally, using brown bags and demos can help your developers hone their teaching skills. These strategies are a great way of investing in your team’s future velocity.

    Focus on the Individuals That Make up the Team

    Fast Company published a great article about the different personality types that make up a great team:

    • The brain pushes others to take action in pursuit of a goal.
    • The voice gets the big picture and motivates the team.
    • The sharp eye focuses on details to get things done the right way.
    • The heart promotes community, consensus and collaboration.

    Thinking about these four very different traits and identifying who plays each role on your team can help you build a harmonious group—while ensuring the strengths of each individual are emphasized and appreciated. 

    Foster Empathy and Build Trust

    Having empathy for your team often means finding a balance between the desire to win or hit certain goals and understanding the different needs of each teammate. As a manager, you should push yourself to ask thoughtful questions that put you in your developers’ shoes. 

    Empathy builds trust. So does:

    • Supporting developers at their unique levels.
    • Nurturing a culture of healthy sprints and personal well-being.
    • Using data–and not just a gut feeling–as a starting point for improvement
    • Clearing roadblocks to productivity so that teams don’t feel overloaded.
    • Granting autonomy to individual contributors.
    • Consistently accomplishing goals as a team.
    • Being transparent with challenges the team is facing.
    • Sharing data across the organization.

    Things that tend to erode trust include:

    • Stack-ranking developers based on lines of code.
    • Rallying around ambitious deadlines at the expense of burnout. 
    • Using data to demean your team members. 
    • Enforcing a productivity quota.
    • Managing with a top-down perspective.
    • Limiting data to leadership.

    These tips help teams avoid burnout, which is a surefire way to wreck a team. The World Health Organization (WHO) defines burnout as “a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed.” So this isn’t just an individual’s personal problem–burnout is a sign that something is wrong within your organization. 

    Understanding knowledge silos, emphasizing individual strengths, cultivating empathy and building trust are the foundations of a strong developer team. Once you have those covered, you’ll be on your way to healthier, more effective teams.

  • 4 Strategies to Manage Freelancers with In-House Dev Teams

    4 Strategies to Manage Freelancers with In-House Dev Teams

    Remote workers are a growing segment of the global workforce. Freelancers account for a big part of that segment, especially when development teams need to bring in specialized skillsets for upcoming projects. Working with freelancers offers many benefits, but there can also be challenges when integrating freelancers with in-house teams.

    Here are four strategies to help in-house developers effectively manage freelancers in their development teams:

    1.    Keep Remote Workers in the Loop

    Don’t leave freelancers and remote workers in the dark about your overall business direction and goals. If a freelancer is only joining the team temporarily to handle one part of a project, it might not seem necessary to give them the full details about the project’s goals and the reasons behind your decisions.

    However, providing this information enables every member of the team to fully understand what you need from the products and features they are working on and how they will serve the end user. It also helps to create common goals and motivations that the team can work toward together, rather than keeping your remote workers’ tasks separate from other members of the development team.

    2.    Make Consistent Feedback a Priority

    In an OfficeVibe survey, 96% of employees said they wanted to get regular feedback from their managers, but 32% said they receive feedback less than once every three months. Freelancers and remote workers arguably need more feedback than in-office employees, for several reasons.

    Freelancers and remote workers are often less exposed to the wider business context in which they are developing products and features. This can make it harder to assess and optimize their output from the viewpoint of an end user. Just as importantly, it can make it less clear what the other members of the team are working on and how their output affects their colleagues’ work.

    “Without consistent feedback, even the most talented developers in a team can invest a lot of time in a non-feasible solution. An ongoing feedback loop is one of the best ways to support a team and enable them to put their skills to use,” said Irene Avdus, a product manager at TextMagic, which has offices in multiple countries and which regularly brings on freelance talent.

    Giving freelancers and remote workers consistent and regular feedback doesn’t just help them improve their output for a better end result. It also helps them to fit in with the workflow of the rest of the team, enabling the project to go more smoothly for everyone.

    3.    Provide Growth Opportunities

    “Great leaders invest in their employee’s career development and steer them from being a one-trick pony,” said Phidelia Johnson, Pac-J Investment Services executive director of HR.

    When it comes to upgrading a team’s skillset, companies tend to skip over freelancers and remote workers in favor of employees they see as more permanent. However, opportunities to develop skills and advance their career are just as important to remote workers and freelancers as they are to any other employee.

    As a result, the perception of remote workers and freelancers as more temporary team members can be a bit of a self-fulfilling prophecy. When companies don’t invest in developing employees’ skills outside of their in-house teams, it is to be expected that remote workers will move on after the project is done to advance their careers.

    Often, treating remote workers as temporary doesn’t result in any less training, anyway. Whenever you add a new freelancer to your development team, there will be a certain amount of training and onboarding necessary to get them up to speed with how your team works. In fact, this can often be a major time and resources investment

    “In a lot of situations, the biggest challenge of working in data engineering or BI is not learning technology X or Y—it is being able to pick up quickly all the business rules and processes of the department you are building your pipeline or dashboard for,” said Mohamed Khalil Ouachikh, ArmedAngels data engineer and BI specialist.

    Rather than spending time onboarding new remote workers with each development cycle, investing in upgrading and expanding the skills of current team members and freelancers can result in a more capable team that is already familiar and comfortable with your business and the needs of your clients.

    4.    Informal Team Meetings

    Making people feel like part of a team is important to ensure they can collaborate and coordinate effectively with other members. Both of these factors are crucial to developing any successful product.

    Why is this relevant to managing freelancers in your development team?

    Remote workers don’t have the same opportunities to connect with colleagues as in-house employees unless you provide them. As many as 20% of remote workers say they feel isolated from their colleagues. This can take a toll on their emotional well-being, and that lack of social connection to coworkers will also affect their ability to collaborate.

     As a result, they may not be able to communicate as effectively with other team members. Building connections between team members let them understand each other more easily and reduce miscommunications that could lead to development mistakes and delays.

    Informal meetings via webinar platforms or video conferencing solutions can have a significant positive impact in this area. A weekly meeting gives everyone a chance to talk about what they are working on and their challenges. As a result, every team member, including freelancers, has the chance to lend their skills to a colleague’s work and help the team pull together toward achieving a common goal.

    Just as importantly, it gives remote workers a much-needed opportunity to connect with their colleagues socially and chat about things other than work. Besides the importance of team-building, this develops more of a connection between remote workers and your business. Inviting freelance developers to all meetings and social events is a great way to ensure greater inclusivity, and it can pay off if freelancers later take full-time positions at the company.

    Make Freelancers Part of the Team

    Keeping freelancers in the loop and ensuring they have the same opportunities and voice as other employees ensure they have the same level of investment in a project’s success as every other member of the team. The tools and the opportunity to coordinate with colleagues and receive feedback are critical parts of this. Following these strategies will help you integrate and manage your freelancers more effectively.

     

  • 3 Ways to Prevent Developer Burnout

    3 Ways to Prevent Developer Burnout

    Without developers, software companies wouldn’t exist—and yet, the experience of these experts can be far from ideal. A recent report from Haystack found that nearly 80% of developers report being burned out and the pandemic isn’t even one of the primary factors. Despite similar job requirements, the experience of developers significantly varies across the industry, adding complexity to an already challenging job. Conflicting coding styles, communication styles and requirements from different teams conspire to make the development process inefficient and difficult and leave developers feeling overwhelmed. Between different organizations and even teams within the same organization, the differences in team culture and educational opportunities can lead to radically different job experiences for the same job title. To retain talented developers in the workforce and maximize their potential, the collective developer experience needs to be improved through a developer-first and inclusive culture and better access to professional development for developers at every level.

    Build a Strong Culture of Documentation, Communication and Knowledge Sharing

    One of the biggest challenges team leaders encounter is how to communicate key information between team members. Many developers are incredibly skilled at their trade but aren’t properly trained or given the time to work on sharing that information with either colleagues or end users. Having skilled technical writers means that the team can provide consistent, clear information about the software—and this is crucial for company success. Having technical writers on the team improves communication and efficiency and enables developers to more quickly and easily locate the resources and support that they need to perform their tasks

    The developer’s goal is to innovate and build successful and maintainable systems. Achieving this requires good team processes and a solid system of documentation. Without user-facing documentation, adoption will suffer as users struggle to get things done with the system. Similarly, without documentation of the individual components, knowledge cannot be shared between teams and so the teams working on the application cannot collaborate effectively. A positive culture around documentation and investment in best practices by all contributors, including developers, makes a huge difference in how successful an organization can be.

    Welcome Employees with Comprehensive and Constructive Onboarding

    Strong communication is especially vital during the onboarding process; it’s one of the most important periods for developers early in their careers. Getting developers up to speed in a new team quickly is crucial—and streamlining education beginning during onboarding can make a big difference. Onboarding is a golden opportunity to bring new developers into the cultural fold and enable them to contribute to the team quickly. Doing so also reduces the risk of losing developers from the team.

    Prioritize an Inclusive and Supportive Culture at all Levels

    The experience of software developers is greatly influenced by the culture of the company they work for. The values of a company and the way that departments interact make a big impact on developers—and it’s not always a positive one. Opportunities for career development, promotions, mentorship programs and training are critical for all employees, but especially those in fields with the potential for high turnover or burnout like developers. Providing developers with resources to further their own understanding and mastery of the job—such as access to a budget for attending conferences and further study—is a critical investment for their success. Organizations both large and small must take initiative to ensure developers see a path forward for themselves at their current company and within the industry—or risk losing their talented developers entirely. 

    While developers’ experiences vary across the industry, between departments and even smaller internal teams, there is inherent value in improving communication, investment and culture on a micro and macro scale. To attract and retain highly skilled and innovative developers and ensure success for teams and companies as a whole, executive leadership must work with their developers to find a cohesive system and create an experience that works for everyone. Like any other specialized professional in a complex trade, developers are invaluable to their teams and community; advocating for the improvement of their work experience throughout their careers is the best way for tech companies to keep developers creating software that improves our world.

  • Dismantling Inefficiency: The DevOps Point of View

    Dismantling Inefficiency: The DevOps Point of View

    I recently caught up with Paula Thrasher, application delivery lead at CSC and DevOps pioneer in government circles. In our conversation, we discussed a number of important topics including cross-functional teams, software supply chains, paying down technical debt and her search for passionate people to hire. To succeed in managing large projects, she’s taking a different approach—one you might want to apply in your own organization.

    Thrasher: I’m Paula Thrasher with CSRA and I work for a division company we call Delivery Services Organization.

    Derek Weeks: What was your presentation at the Rugged DevOps conference about today?

    Thrasher: We had a panel about the people, process and cultural aspect of DevOps, and the security context, as well. When you’re moving to the Ops transformations, what kinds of behaviors are both challenges and opportunities.

    There was a comment at the beginning session about how any sort of transformation that relies on human nature has failed. So you can’t change how we work, but you can leverage how people are motivated to try and encourage the right behavior. I think that’s the thing that’ll resonate with the security professionals.

    blogpic1
    Link to Panel: https://www.youtube.com/watch?v=IbrY8mm9aI4&index=7&list=PLotLY1RC8HovW-XnZbItSBupjbTzFkfJw

    Weeks: You’re setting up a new organization and have a lot of projects that you’re going to take on. Is it possible to achieve a lot with smaller teams? Do you need a big team to do rugged DevOps?

    Thrasher: I think the main thing that we’ve been focused on is creating the team that is sort of the center of the universe. I think the most important thing is to have a team that is cross-functional. A lot of times when you think of teams … this is the development team, this is the Ops team, this is the security team … the question is, do you have all the players on the same team, or are they on different teams? I think if you find yourself in a situation where any one team has to deliver to another team, instead of actually being responsible for delivery of the actual business submission function, you’ve got some horrible web of dependency you’re going to have to untangle.

    The big focus of what we’re trying to do in the new organization is build that completely cross-functional team and to enable them as a team to be placed on different projects, different missions. So instead of doing single-band rotations, where a single employee moves onto a new project, we’re actually trying to move full teams. As a team, they learn how they work best and how they can deliver. It makes a really powerful solution for actually solving problems. I’m really excited about that.

    Weeks: A lot of people at the Rugged DevOps Conference are interested in the rugged DevOps phase because they’re concerned about being left behind by DevOps. Is that a real concern for security teams: getting left behind?

    Thrasher: Yes, we definitely see a dichotomy in the world of how security interacts with development teams—between the traditional showing up at the end and inspecting versus really embedded security. It’s so clearly going to this idea that you can’t just inspect security. Security can’t be this checkbox at the end. You really have to build it in from a computer. You have to actually make design decisions about security. You have to make sure the developers know secure coding practices. You have to have tools that scan, check all the time, and get feedback. You can’t just add that at the end.

    I think it’s a real challenge to security folks, just as it was for everyone—developers and Ops people—to change how you think to that systemwide view. You can’t just be a phase at the end. We actually have to be part of a whole equation, that whole systems thinking. I think that is so instrumental to what DevOps really is as a group.

    Weeks: One of the things that you recently talked to Mark Miller about was an idea of using pictures to help with collaboration and to get everyone on the same page. Can you tell me about that practice?

    Thrasher: Back to this human nature piece, I think humans are inherently really visual thinkers. I also think you’re asking people to bring cross-costuming across social teams. Well, if you’re a security person and you’re talking to an Ops person, you probably don’t speak the same language. Or if you’re a developer and you talk to a security person, again, you don’t necessarily speak the same language. But when you speak visually, you can understand each other better. You don’t bring your acronyms to the table. We’re talking about a diagram.

    I also think it takes the personal element out of it a little bit. We’re talking about the system. We’re not talking about each other. The security team is not accusing the developers of being a bunch of renegades. They’re talking to them about a process and how they process it. It keeps the conversation where it needs to be, which is on making the process better and delivering better software.

    Weeks: How is the growing interest in software supply chains changing the way you’re thinking about DevOps?

    Thrasher: I think simplicity is an underused tool in security. Recently, one of our DevOps teams that was going in their rapid fashion had a deployment that had a vulnerability in it. They had to respond quickly, and they actually did respond quickly. But when we unpacked it, in retrospect, we realized: “How did we get here? How did we let this vulnerability get in?” We had all sorts of scanning. We had, supposedly, all the right things to have prevented that security flaw. Yet, how we got there was this Venn diagram of all these things overlapping. It was one of those security bugs that slips through the cracks.

    We realized what happened is we had gone to over-engineering; we had over-engineered for performance. In doing that, we had overlooked the interaction of three components in a very particular circumstance. It was like a “every third Tuesday if you spun around three times” kind of bug. But I think that’s exactly what happens a lot. That’s super common in terms of those last defects, and there’s quite a bit that comes out of that overlap of complexity.

    Fewer, more secured suppliers reduces the lift of having to upgrade updated components. It also means if you find an issue, your unpacking of that issue is a lot easier because you have a lot less things going on. All engineers need the reminder of “keep it simple.” But I think that’s a real powerful thing. Fewer, better suppliers, from a supply chain standpoint, is one of the mantras that I really appreciate because I just see it match. It really makes a difference.

    Weeks: You’re working with a lot of government agencies across the board. What’s their interest in rugged DevOps practices, or just DevOps practices that you’re bringing into play?

    Thrasher: I think in the government space, and it’s true for any enterprise, everything has to have security. There is not an agency that we can work with that doesn’t have privacy data, or heavily secured data, in the defense and intel agencies, or just straight-up vulnerabilities from being a target. The scale of the enterprise means there’s a lot of potential systems and a potential surface area for attack. You can think to all the high-profile attacks that have occurred in the federal government recently, and it’s made people really alarmed!

    One of the things that’s very interesting is that the whole federal government did a “cyber sprint” last summer, where they did nothing but pay down technical debt, and get rid of systems and their vulnerabilities. It was wonderful! And I think every organization should do just that: spend one month a year doing nothing but eliminating old frameworks and applications. That really simple, easy thing often gets overlooked because businesses are always saying, “More, more, more, more, more.” However, we actually measured the metrics of the teams after the “cyber sprint,” and all of our teams’ velocity increased. After we let teams upgrade legacy components, all of them had an improvement, which is sort of like a “Well, duh!” But I think it’s a win-win really, that if we can allow ourselves to invest in paying down our technical debt we can get better results.

    I think that in a government space, it just has to be part of the equation. So much of what we do is so instrumental to everything.

    blogpic2
    Link to interview: https://www.youtube.com/watch?v=5veGeDAaJSI

    Weeks: As we started off the conversation, you have a new group. You have a lot of projects that are going to get underway. Are you hiring?

    Thrasher: Absolutely.

    Weeks: Who are the type of people that you’re looking for, if someone wants to get in touch with your company?

    Thrasher: We are at CSRA.com, and if you go to our jobs and our careers website, you can see some of the openings we have. Actually, I’m really excited. One of the projects we did internally was building a whole new hiring model. We used big data. We built in some DevOps, and we’re taking advantage of our own technology to do that.

    Like I said, what we are really trying to do is build good strong teams, and so that’s something we’re very focused on. So one of the pilots we’ll probably be doing shortly is a team-based hiring model where a team actually hires for themselves.

    We’re looking for folks who are just really passionate about solving digital government. And I think that’s the main focus of us is really just being passionate about the mission we’re trying to do. We’re trying to help the government be that digital agency. Looking at the interactions we have with some of these Silicon Valley apps, how come we don’t have that interaction with the government? That’s what we want to create. So we’re looking for people who are passionate about our mission and willing and interested in solving problems. Hopefully we can build a great team.

    Weeks: Excellent. Thank you.

    blogpic3If you loved this interview and are looking for more great stuff on Rugged DevOps, I invite you to download this awesome research paper from Amy DeMartine at Forrester, “The Seven Habits of Rugged DevOps.”

    As Amy notes, “DevOps practices can only increase speed and quality up to a point without security and risk (S&R) pros’ expertise. Old application security practices hinder speedy releases, and security vulnerabilities represent defects that can leave a company open to cyberattacks. But DevOps practitioners can leap forward with both increased speed and quality by including S&R pros in DevOps feedback loops and including security practices in the automated life cycle. These new practices are called Rugged DevOps.”

  • Tips to change culture (at least in your team).

    Tips to change culture (at least in your team).

    DevOps is all about automation, enhancing the Application Lifecycle Management and culture change. In the last few years there have been tons of conferences and articles about the benefits of a cultural change on a project, but I have yet to read a paper about how to actually change culture.

    How do you manage to get people to change the way they think and act towards each other and professionally? This is a huge challenge that most DevOps leads will have to overcome. Here are some of my ideas.

    Create cohesion.

    The first thing to keep in mind when trying to implement DevOps (or on any other kind of project for that matter) is that people who don’t have fun at work will not perform as good as they could. How to make people happy to go to work is up to you, but I find that simple activities such as team exercises and/or after-work beer work best.

    Whenever a new member comes to a team, try to get everyone together to have fun and talk. Take them out to a game of laser tag, get some sumo suits and make people try wrestling amongst other sports. Try to identify a common interest for a sport and have everyone play together. Remember, this is not a competition, do not force people to participate if they don’t feel like it.  There are neither losers nor winners, so try to balance the teams as well as you can.

    Another way to get people to know each other and ease potential tension is to take people out. Take your team out to discover a new restaurant or pub and discuss the place together, what they would have changed in the decoration, which Belgium beer is missing from the menu, why on earth do they serve foie gras on a scallop… The point once again is to try to discover others’ interests and behavior outside of work. This specific activity however needs some rules; try to limit the alcohol intake and by all means – do not talk about religions or politics. While those two topics can be fascinating with your friends, some people might get offended, even if they say they don’t mind.

    Back on the project, the use of Scrum is highly recommended. Even though the benefits are debatable, I find that shy people tend to open up and contribute more during those sessions than they normally would. On top of that, Scrum meetings include everyone on the ladder, from bottom to top. Only one rule here: no matter what, remember to actually do your daily stand-up, if you can’t do it personally, get one of you team members to conduct it and check afterwards that is has been done. Delegating is not a sign of weakness; it just shows trust in your team.

    Create incentive.

    People make mistakes, always. There are, however, ways to get to get people to make fewer of them. Pointing fingers and blaming people is definitely not a solution. Making people pay for their mistakes is more efficient. Say each team member has to pay 50 cents (adapt to your own country and project) for every mistake (new bugs, fail in commit, forgot to write a comment in SVN/Git at commit…) they make, and things might start to change. The point here is not to rob your employees, so you will have to find a creative way to use that money. You could for example gather that money at the end of the month to buy candies for everyone. But then that’s just punishing people, which does not make it fun, so you have to come up with a way to compensate for that too. If the management doubles every penny in game, then everyone is involved and there starts to be some interest. But then again, you might get extra bugs because everyone loves candies, so you could triple the sum of gathered money when there are fewer problems than the previous month.

    At that point of reading, you might think it’s actually costly and doesn’t benefit anyone except dentists. Well you’re wrong. In the worst case scenario we’re talking about tens of dollars a month, and given that you will actually get some accurate metrics about this, this is a no-brainer.

    If candies are not popular in your project (is that possible?), you can also get the good old “employee of the month” award to whomever created the least problems and reward him/her with cinema/theater tickets, a dinner for two… Please note that on high stress periods, dinners for two, even though a lot more expensive than regular rewards, are a lot more appreciated as they might represent a good opportunity to ease work related tension in a couple.

    Develop people.

    Don’t see your colleagues, especially the young ones as just resources, rather think of them as potential wonders. Everyone aspires to shine and it’s all up to you to make it happen. Do not ever take someone else’s ideas and get the glory. That would be idiotic, mean and potentially a good way to get your colleagues to quit or resent you.  Instead, go on, try to encourage people to speak up, make them give technical presentations, make them speak and give them a positive feedback (even on failures, there are always good ways to explain how one can improve).

    Once again, Scrum can help you with that. Identify the elements in your team who need some help and pair them with some others that are more comfortable for some small sessions of peer-programming, peer-presenting, peer-testing… once a week. It can cost some time in the beginning but the benefits are potentially huge in a long term perspective. There is nothing better than a team that has learned to work together and where the first reflex when someone ask for help is to actually help, not to ignore.

    Demonstrate values.

    One of the things that really is important to remember, is where you come from. No matter your position today, you didn’t start at the top and you’ve had to learn all the values that you try to get your team to demonstrate today. So show them every day, what it means to create DevOps; a potentially highly stressful job, especially in the beginning, where tension between people should not exist. Smile as much as you can, take time to help others even if you that means staying later at night, be proactive once again, try to identify potential bombs and defuse them before they are seen by others. All in all, be nice to others, treat them as you would like them to treat you.

    But what if you are faced with a pigheaded team member? Someone who is convinced they are right, no matter how many people disagree? Well once again, do not ignore them; that will only create frustration. Instead, get some documentation or an expert and talk openly about the topic without being aggressive. In the end, the team member should be respectful of your efforts and have won some valuable knowledge in the process.

    The biggest piece of advice I have is this: Do not ever be arrogant, do not ever be pompous. Help others, always, and do it nicely and in a humble way. The leaders we like are not the ones that talk too much but the ones that are the nicest to work with.

    Changing a culture on a project is a tough thing, but it can be done with a few tricks and a lot of time spent helping others. Luckily, smiles and good atmosphere have a tendency to spread fast and the tight links between Dev and Ops can be strengthened quite fast with some goodwill.

  • DevOps card game a hit on Kickstarter

    DevOps card game a hit on Kickstarter

    In a lot of ways DevOps is about making a community out of a work place. Alex Papadimoulis has a clever new way to make that happen. Alex is currently Kickstarting a card game about software development called Release!

    Cards

    The game itself is derived from classic trick trump games, like euchre or pinochle, but it’s mixed up with special cards that feature industry thought-leaders like Jez Humble, Patrick Debois, Gene Kim, and Dan North… with some minor costume changes.

    The game appeared on Kickstarter a couple of weeks ago and quickly met and exceeded its funding goal. With support still growing, Alex and his team at Inedo were both surprised and excited.

    “We get together and play games almost every week, and it’s definitely something we look forward to around the workplace. It’s cool to think that other people in the industry might be looking forward to playing our game.”

    After the Kickstarter campaign, which ends on June 19th, Alex plans on making Release! the game available on Amazon, as well as at DevOps conferences.  So keep your eyes open, there might be a copy floating around your office soon.