Lightweight agile only needs 2 goals

Most of the time, developers want to deliver useful software. They want their business partners and end users to be happy, even delighted to use their software. They struggle with this. Sometimes forget this. I haven’t worked with everyone, but for every developer I have worked with and gotten to know, this is true.

Given this, a desire to make customer happy with useful and delightful software, what would I do if I went back into IT management? If the desire was right and the software development practices were not effective, then I think I would introduce 2 ideas. I would not send everyone to agile training. I would not introduce stand-ups, paired programming, or burn-down charts. I would not change the language. All of that is too difficult. Too heavy.

What 2 ideas would I introduce to my team? I would insist on just 2 things. Here’s what I might say . . .

First I want us to develop a new review & feedback system. On a regular basis, we need to review what we’re doing and figure out how to do it better. Sometimes this would cover the last hour, when we where in a meeting. Sometimes it would cover the day, so tomorrow will be more effective. Sometimes it will cover a week or one month, so we make sure we capture the big and important issues. And to make sure we are on the right track we will also hold an annual review to check our overall direction and strategy, too.

Second I want us to start integrating code into the trunk multiple times a day. Anything less than twice a day means you’re in too many meetings! The reason for doing this is to reduce risk, because if you’re spending time working in a silo then you are adding or ignoring risk.

 

So, why these 2 ideas? Why did I ignore the rest of the principles surrounding the agile manifesto? Because everything the agile manifesto wants is covered in these two ideas. I am both forcing change and giving them a means to talk about the problems and incorporate the differences into their processes.

The first idea I will introduce is all about giving them the foremost thing a team or company, an individual or company needs is the ability to review it’s process and work, to honestly assess the output and performance, and be able to improve upon what they’ve done.

The second idea I will introduce is all about forcing fast feedback. Jez Humble has said, “If it hurts, do it more frequently and bring the pain forward.” It was counter-intuitive for me, but I finally learned he is right. We need to stop avoiding the painful parts of the process because we are making it worse. For example, if integration is difficult, waiting makes it more so. Do it so often the issue becomes irrelevant.

By requiring continuous integration as my second idea, I force the team to look at their environments, their tools, their permission structures, their process, their tests, their requirements, and more. Each change will cascade other changes, and in so doing, push the group to accommodate the greater needs. We may never call what we do “agile” even though I expect, with some time, we will be living the agile dream!

 

Okay, this is my dream. What do you think? What’s missing? Can you convince me even these 2 steps are too heavyweight?

  6Comments

  1. Curtis Michelson   •  

    Dude, that approach is so lightweight, it’s about to float off the table and into the ether! Put a paperweight on it. 😉

    Seriously, I think Item1 (the feedback loop) is key. But here’s the thing – the quality of any feedback session is in direct proportion to its facilitator and its participants, which is in direct proportion to the nature of the organization in which the development team works. This is where Agile butts up against the really wicked problem – culture.

    I think you’re onto something good here, but I think you’re sidestepping what is the really big elephant in the room – organizations (not developers or their practices) are what defines agility. Agile COMPANIES enable and empower their developers to be agile. That top-to-bottom support changes everything, and makes all else possible. Without that – your two ideas alone – will not help any team of developers do their work better and delight their customers.

    • Jeffrey   •     Author

      “Put a paperweight on it.” Genius turn of phrase!

      I like your thoughts on facilitation as an expression of the facilitator’s skill and participants trust, which is based on culture. I think you’re right, or mostly right. My example was using me as the IT leader. It doesn’t have to be me, but it did, and I presume a few things there. One, I am a pretty good facilitator. I know how to get build participation, elicit opinions, and keep the group and conversation focused. Two, the team(s) may need more attention that I can give them. I am cool with bringing a coach or facilitator to help my team(s).

      For your second point, if I’m in charge, then I can impact the organization and culture. It’s part of my responsibility. So yes, in this example I presumed I had the power to be provide top-to-bottom support at some level. No one will disagree with you and say they don’t want agile companies. It would be a foolish statement.

      I do not agree with your conclusion though. Just because the company is agile doesn’t mean I cannot enable and empower developers, or delight customers. Based on your answer, introducing agile to a single team or department is futile because it doesn’t have all the support I dream of getting. This doesn’t match my experience, or the coaches I know.

      Yes, we all want support to make the company agile, but it doesn’t usually happen this way. Agile often starts in a single team, a single department, sometimes a single individual. It might take longer to reach a critical mass, the politics may be a large burden, or the effect may be blunted because there isn’t enough buy-in. This doesn’t mean we should not start the journey. Every journey starts with a single step.

      I will gladly start with an edict from the Board of Directors to make the organization agile. Until I get that edict, I will be focused on the groups who are ready for change, whatever their size and scope.

      • Curtis Michelson   •  

        I think I overstated my conclusion. You’re right, we are all free actors and some of us better leaders than others, and able to put dents in the culture, even in tucked away workgroups, despite the company’s waterfallish, ways. HOWEVER, I’ll still stand by the fact that real agility is a systemic culture change (and emergent phenomena?), and when it really takes hold with executive support, there’s no stopping it. You Mr. Facilitator, stop being Sisyphus, and start being Hercules.

  2. Kent McDonald   •  

    Jeffrey,
    That’s a good, potentially barely sufficient description of how to build the stuff right.

    Thing is (and it’s generally against my nature to add any more than needs to be there) this doesn’t seem to address any way of knowing are we building the right thing, and whether we should be building anything at all. Figure out how to address that, and I think you may be on to something.

    Of course Curtis brings up some very important points as well.

    In cases like this, I like to invoke Einstein – Make things as simple as possible, but not simpler.

    • Jeffrey   •     Author

      I like @Curtis’ phrase “put a paperweight on it” more than “barely sufficient.” 🙂

      You might be right. This is just a thought experiment and it might not work as well in the practice. As I sit and think it through though, the more I think these two steps will get the team to delivering value. Here’s why:

      1. First, the teams are building fast. They’re checking in code to the trunk, which is going to lead to feature toggles and branching by abstraction.
      2. Second, the plan really works best after we have a solid automated test suite, which as the boss I’m going to insist is run against the entire code base, not just what’s live-in-production.
      3. Third, with our emphasis on honest feedback, I believe the teams will quickly determine the need to reduce the extraneous and unused, start refactoring the existing cruft, and add only what’s valuable.
      4. Fourth, once the team gets to thinking about value, it should pretty easily add this as a core purpose.

       
      My fundamental belief is people are good. They want to do good work and be appreciated for that. I think developers love it when they write an elegant line of code and they love it when they delight their customer. I’m counting on the second love to subtly guide them to discovering the need to focus on value. Heck, to not focus on value is to add extraneous stuff which just makes more work for them. Even if the team was selfish, rather than selfless, I think they would discover doing less by focusing on value is better than doing more by coding every idea possible.

      • Kent McDonald   •  

        Yes, it’s a thought experiment.

        To do the idea justice it needs to become a real experiment.

        I’d say the team I work with on the Agile Alliance Conference Submission System is awfully close to this. That of course comes with the big caveat that not only are the guys working on that good, they are also experienced developers. And there are two of them.

        So something to consider – are there specific environmental conditions where you think this would be most effective. Important things to consider when designing an experiment to test it out.

Comments are closed.