Author: eli

  • This might kill your vibe, but I’m not worried about AI replacing Software Engineers

    —

    by

    eli
    in

    I started learning to code in the late 1990’s using gcc, make, and emacs. The 2000’s were a huge pivot point in Software Engineering. Three major changes which were very related came together to fundamentally change how software saw built. First, modern IDE’s changed how coding was done. Second, high level languages like Java, C#,…

  • Conway’s Law and Agile Congruence

    —

    by

    eli
    in

    In a recent discussion with a fellow Software Engineer about Agile Congruence, he stated that the model did not consider software architecture. More directly he said, “I can be effective at agile software development and delivering in small batches of changes but if my architecture sucks it still might not let me be agile enough.”…

  • Introduction to Agile Congruence

    —

    by

    eli
    in

    One of my responsibilities at my former employer was to give an introductory talk about the Technology Team and our SAAS platform to new hires. This is always an interesting experience because of the diverse range of backgrounds in the audience. Accountants, Financial Analysts, Developers, and new graduates among others will all have very different…

  • A Brief History of Agile Software Development

    —

    by

    eli
    in

    In the 20th century organizations viewed software development investments as projects. They would plan the project, document the requirements, implement the software, test the software, then release the software. While this process made sense on the surface, a lot of the software that it produced failed miserably after it was released. Processes that follow this…

  • The Nadler-Tushman Congruence Model

    —

    by

    eli
    in

    The Nadler-Tushman Congruence Model, shown below, was introduced in 1980 in an article in the journal Organizational Dynamics. This model has gained great popularity in the Organizational Behavior community and is commonly taught in graduate Business Administration programs.  The model begins with a set of inputs. These inputs are thought of as outside of the…

  • Releasing Software as an Organizational Change Process

    —

    by

    eli
    in

    The key hypothesis of Agile Congruence is the relationship between releasing software and the Nadler-Tushman model. Enterprise software is the automation of an organization’s formal processes. Each time an organization releases software, it changes the “work” component of the organization in the Nadler-Tushman model. With each software release the people, culture, and org structure components…

  • The Agile Congruence Framework Overview

    —

    by

    eli
    in

    In their paper A model for diagnosing organizational behavior, Nadler and Tushman define a process for implementing their change model. In that spirit, Figure 3 shows an overview of the process for using Agile Congruence to implement a software driven organizational change process. While I use these steps when implementing technology changes, I don’t go…

  • The Agile Congruence Framework Part 1

    —

    by

    eli
    in

    There is some reason that your organization wants to change and make an investment in technology. In the past when I have assumed that all stakeholders were on the same page with the problem that we were solving I was usually wrong. Taking the time to identify and understand the symptoms and ensure that there…

  • The Agile Congruence Framework Part 2

    —

    by

    eli
    in

    4. Analyze Gaps and Build your Backlog In the process laid out by Nadler and Tushman this phase was labeled Identify Problems. In the world of agile software development these problems are captured using tools like User Stories. Modern UX techniques can also be used to help with this Analysis. At Chatham, when facing some…

  • The Agile Congruence Framework Part 3

    —

    by

    eli
    in

    8. Decide to Continue or Re-Evaluate At this point on any iteration you may find that there are no changes that can be made where the value of the change justifies the cost. There are times early in the process where we have found that we should delay development and wait for other organizational changes…