What Does Continuous Delivery to a Team

Tl;dr: Continuous integration and delivery are not about a pipeline, it is about trust, psychological safety, a common goal and real teamwork.

What is needed for CI/CD – and how to achieve those?

  • No feature branches but trunk-based development and feature toggles: feature branches mean discontinuous development. CI/CD works with only one temporary branch: the local copy on your machine getting integrated at the moment you want to push. “No feature branches” also means pushing your changes at least once a day.
  • A feeling of safety to commit and push your code: trust in yourself and trust in your environment to help you if you fall – or steady you to not fall at all.
  • Quality gates to keep the customer safe
  • Observing and reducing the outcome of your work (as a team, of course)
  • Resilience: accept that errors will happen and make sure that they are not fatal, that you can live with them. This means also being aware of the risk involved in your changes

What happens in the team, in the team-work:

  • It enables a growing maturity, autonomy due to fast feedback, failing fast and early
  • It makes us real team-workers, “we fail together, we succeed together”
  • It leads to better programmers due to the need for XP practices and the need to know how to deliver backwards compatible software
  • It has an impact on the architecture and the design (see Accelerate)
  • Psychological safety: eliminates the fear of coding, of making decisions, of having code reviews
  • It gives a common goal, valuable for everybody: customers, devs, testers, PO, company
  • It makes everybody involved happy because of much faster feedback from customers instead of the feedback of the PO => it allows to validate the assumption that the new feature is valuable
  • It drives new ideas, new capabilities bc it allows experiments
  • Sets the right priorities: not to jump to code but to think about how to deliver new capabilities, to solve problems (sometimes even by deleting code)

How to start:

  • Agree upon setting CI/CD as a goal for the whole team: focus on how to get there not on the reasons why it cannot work out
  • Consider all requirements (safety net, coding and review practices, creating the pipeline and the quality gates) as necessary steps and work on them, one after another
  • Agree upon team rules making CI/CD as a team responsibility (monitoring errors, fixing them, flickering tests, processes to improve leaks in the safety net, blameless post-mortems)
  • Learn to give and get feedback on a professional manner (“I am not my work”). For example by reading the book Agile Conversations and/or practice it in the meetup

– – – – –

This bullet-point list was born during this year’s CITCON, a great un-conference on continuous improvement. I am aware that they can trigger questions and needs for explanations – and I would be happy to answer them 🙂

Project vs. Product Development – a Comparison

Last week I have realized that I had a blind spot: I thought that every developer is aware that selling software or delivering a product are not quite the same. As it turned out, I was wrong so I created this list to explain what I mean.

Goals And Interests In Project Development (aka Feature Factory):

  • The main stakeholder is the company paying for the features (called client further on), not the customer who is using them.
  • The responsibility for maintaining and evolving of the platform is not my job.
  • The requirements are defined by the client: I have no way to validate them because I have no contact with the users of the features. Feedback-based decisions are not possible.
  • Fast development but slow delivery.
  • Features are defined as a whole and delivered as a whole, not iteratively. Visual requirements (mock-ups) are un-negotiable because they are ordered as-is, even if the end user might not see it that way.
  • Perfection instead of usability.
  • Innovation is limited by restricted access to the infrastructure or other 3rd party services used by the client.
  • No involvement in long- and medium-term planning, as the goals of the client are not my goals. Very limited possibility to plan the architecture aligned with the strategy of the client.
  • The product my company sells is time and/or LoC. (Disclaimer: this would not be the case when working with Extreme Contracts)
  • The most important metrics are:
    • hours per week,
    • features per unit of time,
    • LoC

Goals And Interests In Product Development:

  • The main stakeholders are the end customers and the company itself (me and my team included).
  • The main goal is to identify users’ problems, develop solutions for them and solve them in the correct order. The job is no longer spending time with work or moving tasks on a Jira board, but to provide solutions.
  • Nowadays, with a large number of competitors who could appear every day, time-to-market (i.e. time) is decisive, but not at the expense of quality.
  • We own the maintenance and the evolution of the platform. It is our interest to produce high quality and robust software.
  • Through the cooperation of business analysts, UX experts, software developers and cloud experts, we are able to deliver features (capabilities) step by step, measure their benefits and decide on the next measures.
  • I can use all my skills and my company can benefit for them.
  • The user stories are written in a business-oriented manner, they can be taken literally. They document the proposed solution, can be cut into meaningful slices to be implemented quickly and reliably and to be delivered fast.
  • “Fail Fast” and “Inspect and Adapt” are the most important principles.
  • Usability, not perfection.
  • The most important metrics are:
    • customer satisfaction (measured with business metrics and the usage of delivered features),
    • lead time (time between idea and in use),
    • time to recovery,
    • change failure rate (Accelerate)

Book List (And Other Resources)

Basic Resources For Developer

  1. The Pragmatic Programmer – by David Thomas, Andrew Hunt
  2. Test-Driven Development: By Example – by Kent Beck
  3. Code Complete – By Steve McConnell
  4. Refactoring: Improving the Design of Existing Code – by Martin Fowler
  5. Fix The Small Things – by Kent Beck
  6. Working Effectively with Legacy Code – by Michael Feathers
  7. Ian Cooper: TDD, where did it all go wrong (Video)
  8. Some Underrated Elements of Success for the Modern Programmer – J. B. Rainsberger
  9. 97 Things Every Programmer Should Know – by Kevin Henney

Architecture (and Business)

  1. Domain-Driven Design: Tackling Complexity in the Heart of Software – by Eric Evans
  2. Martin Fowler’s Blog
  3. Community Collection of Maps, Heuristics, Methods and more – Open Source
  4. Encouraging DDD Curiosity as a Product Owner – Zsófia Herendi – KanDDDinsky(video)

Resources For Everbody Caring For Product(Project) Development and Strategy

  1. Impact Mapping: Making a Big Impact with Software Products and Projects – by Gojko Adzic
  2. Specification by Example: How Successful Teams Deliver the Right Software – by Gojko Adzic
  3. The Bottleneck Rules: How To Get More Done at Work, Without Working Harder – by Clarke Ching
  4. Agile Conversations – by Douglas Squirrel and Jeffrey Fredrick (there also is a Meetup to practice)
  5. Nick Tune’s Strategic Technology Blog
  6. Accelerate: Building and Scaling High-Performing Technology Organizations – byNicole Forsgren, Jez Humble, Gene Kim
  7. Team Topologies: Organizing Business and Technology Teams for Fast Flow – by Matthew Skelton, Manuel Pais
  8. The Software Architect Elevator: Transforming Enterprises with Technology and Business Architecture – by Gregor Hohpe
  9. Visual Collaboration Tools – by many

Crime, History

  1. The Mythical Man-Month: Essays on Software Engineering – by Frederick P. Brooks Jr.
  2. Your Code As a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs – by Adam Tornhill
  3. The Phoenix Project – by Gene Kim, Kevin Behr, and George Spafford
  4. The Unicorn Project – by Gene Kim

THE FIRST IDEAL: Locality and Simplicity

THE SECOND IDEAL: Focus, Flow, and Joy

THE THIRD IDEAL: Improvement of Daily Work

THE FOURTH IDEAL: Psychological Safety

THE FIFTH IDEAL: Customer Focus