The First of Five Challenges to Large Organizations that Force Agility

Daniel R Greening, PhD. Managing Director, Senex Rex

As a company grows, agility can erode over time. And so, when we’re in startups, we can generate features really fast when a customer demands something, we have a turn-around time of less than a week often, and we can deliver something of value. When a company gets older, it just continues to apply those same principles it applied when it was smaller. So those principles, generally, sacrifice long-term productivity for short-term gain.

In the short term, for example, it might be beneficial to copy and paste existing code that has a feature that’s related to what you want to do to a different file, and then modify that new file. And the reason you do that is you want to avoid risking that a feature that already exists will stop working because you were messing with it when you added something else.

But this can create a serious problem. What you’ve done is that you’ve started duplicating code, and you’ll likely be in a similar situation in the future where you’ll duplicate the code again. If you keep doing that, what ends up happening is that bugs in the original piece of code that you copied are replicated in every copy. If you want to make an architectural change in the way the system works overall that affects one or all of them you have to implement the change in every single file.

So that is a case where we are sacrificing long term productivity where we would be able to easily make a significant change in the future; we’re not able to do that anymore because we sacrificed that ability for short term expedience.

Companies do this all the time, especially when they hire younger computer scientists who have no experience in this area. They often incur a huge amount of technical debt. Most startups have significant problems in this area.

And so, when you get to larger enterprises of course they are rife with problems. One of the problems that we see in larger companies is that it’s very hard to make a change in your code and actually see how that code change will affect the whole system. Why? Because the short term mindset has meant that we never actually created end-to-end builds for example or other stuff like that.

So here are some challenges that you can post to the organization of ideal worlds that they should strive for. When they do strive to achieve this, just the act of striving to achieve it will improve their agility along the way.

Challenge 1: Each Employee can Build the Entire System

Every engineering employee should be able to build the entire system from end to end, run all of the automated tests (whatever automated tests there might be; maybe there are none) they should be able to configure the system, they should be able to run the system and test to see that features work on their laptop, unattached to the net.

You say this to many people and they almost disbelieve it could be done, and yet today we have multiprocessor laptops with 4 cores in them and half a terabyte of storage in very high-speed flash memory on laptops. For SaaS (Software as a Service) software, programmers could have versions of those systems running locally on their development laptops. We even have source control systems like git that can operate completely independently of a network connection to a central repository. All major database vendors have free licenses that allow developers to run a version of a database and run it locally where the licensing restrictions say that if you’re developing code; once you make the finished product available to customers or users for production use, then you pay. This is true for Oracle, MySQL, and it’s true for almost everything you might worry about in the database world.

You can do virtually anything on your laptop. Here’s the advantage: In most large enterprises we have teams. For example, one client that I’m working with today has around 1,200 developers. Any one feature might require the involvement of a succession of 7 teams ranging from bottom level library teams through intermediate level teams such as audio compression or information transmission; even all the way to clients at the top level and ultimately, configuration systems and that sort of thing.

Companies that are not agile overall, have dependency chains between teams like this. They usually can’t build the entire system from bottom to top; each team has a wall around them that says “This is our code. We teach our team members some kind of manual configuration process, and we don’t really have time to teach all you other people outside how to do this, and we don’t have time to automate this process.” In agile companies builds are uniform across the organization, so once you learn how to do build one team’s software you can easily build another team’s software.

Large enterprises grow organically, and as a result they look like a jungle. From team to team it’s often hard to know what the rules are. So if we take this challenge and say any engineer should be able to build the whole system, it forces behavior that should have happened long ago.

Why do It?

The advantage gained is that any engineer in the company can make a change in their particular code or maybe some other piece of code, not check it into a repository but just run it on their local laptop, try the new feature. They can ask simple questions: Does my code realize the feature? Does the system continue to operate properly otherwise?

This makes feature development much faster. No longer do you have to make a phone call to another team and say, “Hey, I need a new version of your library” or “Hey, I don’t know your code, I don’t know how to change it to do this thing; could you please do it.” Instead developers can look at other peoples’ code. If other development teams have exclusive rights to production versions of a component, you can say, “Here’s a patch for your code. Try it for yourself, see if it’s decent. I already ran it through our automated tests.” Their life is simpler, the feature gets released faster.

In many large development groups with separated teams controlling their components, writing and testing a feature could be a multi-week operation. When a common build mechanism and source repository are used, changes can be developed and tested end-to-end by the team needing a new feature. Only the final check-in to production needs to be handled by the owners of the code.

Build and test delays impede programmer productivity. If build and test take 8 hours, programmers are likely to code multiple features, batch them all up, push the “build” button on their way home, come back the next day and look at the output.

Agile practices advocate getting one feature completely done and shipping or showing that feature to users as soon as possible. Through this rapid market feedback, features can better meet user needs and developers can focus more on features likely to generate profit.

How to Do It

If you have all your code in a common repository, that’s a good starting point. At least, developers can get all the code onto their machine, hopefully with one command.

Migrate all builds to use the same system. Pick only one: Maven, Ivy, Ant, Team Foundation Build, etc. Articulate the dependencies in the build system in the same way. Use a centralized repository for libraries and other assets, such as Maven, Ivy, etc.

Establish a single mechanism for configuration. Have a default configuration that works well with any developer platform that might be running it. Have an IDE that allows one to browse these components and, finally, have an automated test strategy that can be run locally.

Summary

When developers can modify any component, when they can build the whole system on their own, and when they can test the whole system end-to-end, we can expect much faster feature development, much higher quality, much better features.

Accepting this Enterprise Challenge will make your company more agile.