Agile Can Succeed Outside of Software but Transitioning Isn't Easy
Agile Can Succeed Outside of Software but Transitioning Isn't Easy
Like many other proponents of agile, I hear myself regularly stating that agile can be successfully applied outside of the software industry. While I firmly believe this to be true, I also believe that it can be significantly more challenging to be successful with agile in organisations outside of software and IT. In this post I want to highlight some of the reasons why.
A Non-Software Development Scenario
Many organisations have problems with their data quality. Their data stores usually consist of successful or unsuccessful software implementations; they have a massive over-reliance on uncontrolled spreadsheets, manual files and, of course, all the data stored inside the heads of veteran employees.
Because of this, it is not uncommon for such a business to buy a piece of software and then realise that a large data cleansing project is required before it can be populated and used with confidence.
The new system will be used differently by everyone in the business from management to operational field staff. Each data record would require work to done by various specialist functional areas across the business to ensure it is accurate.
I believe Scrum fits perfectly with this type of problem since each vertical sliced requirement can be a completed data record and, as said requirements are completed, they can be regularly integrated into the new system and accessed by users.
Agile Remains Tightly Coupled to Software Development
The first problem we may face is that it is simply more difficult for non-software people to learn and relate to agile. After all, books about agile are full of software development jargon and have full chapters dedicated to topics such as Extreme Programming, Test Driven Development and Continuous Integration. The same is true of most agile websites, blogs and training courses.
Recently, the word “software” has been replaced with “product,” but all the available examples continue to be focused on software, which makes the word “product” somewhat of an empty gesture – in other words, a rose by any other name is still a rose.
Thus, it is understandable why some people think that agile only works for software development, and continue to be sceptical when we suggest they read a book or take an online course that only talks about software.
Barriers to Ensuring Change is Driven Bottom-Up and Top-Down
The problem described in the previous section also makes it much more difficult for non-software organisations to achieve the correct mix of bottom-up and top-down support that is required to successfully drive change.
In the software industry, the development team at the bottom often take it upon themselves to implement agile and then use the positive results of that decision to gain support from influential senior management at the top. Or, senior managers see the results that other companies are getting with agile and drive the change from the top with a goal of getting complete buy-in from below.
Both cases happen because it is impossible to be a professional in the software industry and be unaware of agile. This is not true of other industries, and sometimes we find ourselves having to implement agile methodologies from the middle, which is far more challenging.
Applying the Concept of DevOps
DevOps is the term used to refer to a set of practices that emphasize the collaboration and communication of software development teams and IT Infrastructure with a view to automate the process of software delivery and infrastructure changes. DevOps also aims to establish a culture where quality software products can be released rapidly, frequently and reliably.
We increase our chance of success by having good DevOps, so it is a fair assumption that other industries will need something similar to release their products in the same manner. Sourcing or creating a DevOps for a specific non-software industry is significantly more difficult, especially if there are real operational or cultural changes required when releasing products.
Creating Cross Functional Development Teams
Good agile software teams are cross-functional, meaning that they possess all the necessary skills to get vertical slices of the product done. This is a relatively simple endeavour because the resource is usually under the umbrella of Software Development or IT.
In other industries, however, it can be much more difficult to create a cross-functional team since members can come from highly independent functional areas. For example, a data record may require work from various technical departments as well as the HR, Finance and Health and Safety departments. Each area has its own management structure, political agenda and mini-culture, which makes building truly cross functional teams much more challenging.
In software development, the idea of quality assurance is very well defined and includes aspects such as whether or not the code is well written, has been peer reviewed, checked into version control, has automated test coverage, has been manually tested and has earned the approval of the Product Owner. Of course, these things usually become items on a checklist called the “definition of done” that has to be true in order for the requirement to be considered complete.
When our product is not software, we need to define what quality means and create our own definition of done.
For instance, on a large manual data cleansing project, what would quality represent? What would the definition of done be?
Of course, we would need more information on the type of data such as the complexity involved in arriving at the values to be entered, dependencies and whether our system can help validate in anyway.
Try to think about a non-software product and what its definition of done would be. It is not easy, and it is unlikely you’ll find one as easily as a software professional would.
The Starting Line is Further Back
I may be biased, but in my experience, the software industry is amongst the more mature in regards to general project or product management. It is unusual to find that there is no formal approach in place, and there is normally a good general awareness of prioritisation, scope, benefits realisation and resource and asset profiling.
Many traditional software teams realise on their own that no matter how well they adhere to so called traditional “best practices,” they continue to have no or limited success. This creates a healthy mix of bottom-up and top-down motivation to transition to agile, not least because of the vast array of supporting material and success stories that are widely available specifically for the software industry.
Not all industries are as mature in their project management approach and tend to have little or no understanding of managing a balanced portfolio. Because of this, I have seen coaching conversations similar to this:
Agile Coach: “Perhaps consider stopping this task, it is a huge productivity leak.”
A Manager: “Yeah, in an ideal word I would, but we need huge productivity leaks here.”
In this situation, people are asking how agile can be changed to fit with the organisation, instead of asking how the organisation can change to fit with agile.
And, as mentioned earlier, the supporting material and success stories specifically for their industry don’t exist or are much harder to find. In these cases, our challenge is much greater than transitioning a good traditional software company to agile.
I’ve only had a chance to raise some of the additional challenges that I think exist when transitioning a non-software organisation to agile in this post, and I’m very aware that I haven’t offered any solutions. However, I will follow up with some useful advice soon.
I certainly don’t have all the answers for all challenges in all industries, so I would love to generate some useful discussion and ideas here. Feel free to share your thoughts in the comments section below, and let me know what would help you feel confident about the success of agile in your industry or organisation.
David Cassidy is an Agile Coach with over 20 years’ experience in the software industry.Learn More