This is the fourth article in a series where I’ll talk about the essential traits of an E-g consultant.
When we go into that new project, we believe in it all the way. We have confidence in our ability to do it right.
– Walt Disney
In software development, much effort is devoted to address the “How” question from a process standpoint: How are we going to build successful software?
The answer, of course, is “it depends”.
In a previous part to this series, I talked about how varied and wild the technology landscape is across our client portfolio. While it’s not quite as varied, the methods our clients use to build software are also diverse.
For the purposes of this article, we’ll simplify things and talk about the process of software engineering as a continuum of one method to another. Generally speaking, the more traditional method is Waterfall and the more contemporary method is Agile. In case you’ve not followed the links to read about each in more depth, I’ll grossly oversimplify them.
Waterfall is a process by where you try to completely specify the software you want to build and then take a series of steps to complete the project. The steps are commonly:
- Requirements – What should it do?
- Analysis & Design – How do we think it should do it?
- Implementation – Make it run
- Testing – Make sure it runs the way you want it to run
- Deployment – Make it available for the users
- Maintenance – Support it
Agile goes like this:
- Make a list of features and prioritize them
- Flush out some details on the important items
- Pick the most important things you can build in a chunk of time
- Build and test the things
- Show the things to the product owner
- Deploy the chunk of features
- Talk about what you can do better next time
- Change your mind about what you want and repeat until everybody loves it
There’s many variations to each process type and organizations will pick pieces from multiple methodologies and mix them together to their liking. The end result is that you will almost never find two companies who build software the same way.
Another facet that accompanies software process is documentation. For example, regulated industries (e.g. Pharmaceuticals) are accountable to regulatory bodies that have strict standards that must be followed. Not only do such situations heavily influence application design, but they have a huge impact on an organization’s ability to move quickly through software development cycles.
Yet another significant knob on the process panel is that of coordination with the various interested parties. Some organization have significant marketing or training efforts that impose constraints on the software development process. Others may have separate business units that provide critical services (e.g. infrastructure) and there could be heavyweight processes associated with those interactions. One example of this would be a requirement to get signatures from six different people just to make a small web server configuration change.
There are certainly an abundance of opinions on what methods are the best. Additionally, there are plenty of opportunities for improvement in almost every environment. We have experienced consultants who have been around the block with process and we love it when our clients ask for our thoughts. One great benefit of being exposed to so many methods is that it gives us a humble, healthy perspective of what works well and what doesn’t – even in different cultural contexts.
E-g consultants have to be prepared for a wide range of possibilities when it comes to process. Just as with technology, we have to be prepared to accept the methods chosen by our clients and choose to thrive in them. Many of our clients are able to embrace lightweight agile methods but some either haven’t been able to impart the necessary cultural shifts or have encountered other challenges that necessitate more traditional methods. Can it be challenging to go from something lightweight to something that’s not? Absolutely. Adapting to change is simply what we must do if we’re going to be successful at bringing value to our customers.
If you feel like you can do the process two-step and have fun while you’re at it, you might make a great E-g consultant.
This article is Part 4 of a 5-part series. For additional reading on why “you might want to be an E-g consultant” click one of the links below:
- Part 1: Location
- Part 2: Work Environment
- Part 3: Technology
- Part 4: Process
- Part 5: People
Gitflow, Maven, and CI Done Right: Part 1 – Teaching Maven New Tricks