Reduce Cost of Translation
(by Thomas Köppner & Amir Khan)
Going back, if we look on the software development lifecycle (SDLC), we realiaze there have been alot of changes over the past 20 years. How were we used to develop software 15–20 years ago? We use to have strict process driven approach with seperated silos, responsibilities, teams (better would be to say independent group of people also departments), different tools (mostly solving focusing on the people using them) and strict culture & mindset. Looking from a very top view, there were several entities (people, technology & resources) involved to provide software, which helps organization to emphasize their key business processes and gain market advantage. It was usual that software delivery took 6–24 month to be released into production. Today we can not imagine that a software delivery would take that long.
The problem why the traditional approaches had delays in delivering the product was caused by the time it took from the idea to be implemented and delivered to the business.
For example, when a business user comes up with a great idea on how to enhance business and generate more revenue. He needs to:
- describe his idea
- calculate a business case
- provide a detailed requirements specification documents, and
- discuss it with all business analyst and owners involved
This usually takes 2 months or longer! A lot of time is been spent with:
- Formatting huge documents, tracking changes, sending changes back and forth
- Translating the business need to a functional / technical specification
Then two months later the development team gets a huge specification document which typically is:
- hard to read
- hard to understand
- and still incomplete, although it has hundreds of pages
The development team will try their best and implement what they understand and what they think is the best solution for the business.
6–9 months later when the software is been built, it is been passed to the quality assurance team. They define test cases based on the specification from what they understand. Then they execute the tests (mostly manual) in 3 or 4 cycles where they test, find defects, send defects to development, development provides a fix, QA is doing a re-test and so forth.
Typically this QA, stabilization and bug fixing phase lasts another 1 to 3 months. This means a minimum of:
- 2 months analysis and specification
- 6 months design and implementation
- 1 month qa and bug fixing
Equals to 9 months in total!!! Until there is a first running piece of software at which the business department is been confronted with and could provide feedback!
And what happened after these nine months:
- The world has changed, the business has changed and the business idea might no longer be relevant or at least not as it has been originally designed
- Some of the business requirements have been implemented, but not the most important ones, because the developers had no insight into the goals
- Even if the software is working fine, does not crash and does not produce any errors, it still is not doing what the business did expect
In this waterfall project like example there was no additional value provided to the business for around nine months. In contrast, agile development focuses on rapidly delivering business value. Agile practices therefore accelerate the delivery of business value and also incorporate early feedback. It minimizes the risk associated with software development by delivering faster and in smaller pieces.
As a result of its iterative planning, agile teams are able to adapt to changing requirements. This ensures that value is been provided to the business even if the world and business requirements are changing during the project phase. Finally, as a result of agile practices, a software system is been delivered that addresses the business and customer needs better than ever before.
Also the barriers between business, development and testing team have been broken. The mindset and culture has changed to work in teams and be cross functional.
With Behaviour Driven Development (BDD) we have targeted the right direction within software development. Using higher frequency of the feedback loops between the involved personas BDD is targeting on the spot of the cost of translation. Using defined framework with keyword all involved personas can embrace BDD to speed up the pace of delivery. One language, one way of working, on understanding, results into reduction of cost of translation.
Different individuals work with different tools, which is perfect. Each organization has a lots of tool islands. One each island sits a small group or team, but these teams are most often still not interconnected, which is absolutely ok and supports the idea of self-organizing teams. The following graphic visualizes these tools islands and give some examples of the different tools they use:
As a next step we are moving faster towards DevOps, which will finally break the barriers between the agile development teams and IT operation teams. The cost of translation from an overall perspective will have a huge reduction, however the cost of translation is not only related to the information provided to the personas, but also in what medium is it provided. Currently if we look into our organizations, we find a lot of media breaches, tool chains which are not seemlessly integrated.
For example:
- There is a team using JIRA for backlog management,
- another team uses ALM/QC for test management,
- some works with Jenkins,
- others with TeamCity and so on and so forth.
Currently, we are pointing on culture & mindset as the show stopper to transforming towards agile / DevOps, which it really is, no doubt about that. But on long term, the challenge of DevOps will not be the culture, mindset or way of working — these are things which can be educated and solved — it will be more to provide one single source of truth. A system which reflects the complete application lifecycle management in a seemless integrated DevOps tool chain.
Today we face issues and waste a lot of time to find and spot the problems (even we are transformed into agile methodology), such as: If there is a build failure — now to identify which code commit broke the build, which test case caused the error or how many test cases are executed. With different build systems, source code management & testing tools, we need to look up the information on the system which it contains. Today with growing number of artifacts, agile project management systems struggle and breaks down into performance issues. The majority of today’s agile project management tools were built to support individual teams and they are serving well. But scaling these tools to enterprise will break the whole process.
ALM Octane was build to reduce the cost of translation while transforming towards DevOps. The task of the agile teams is to build high quality products and not to fix environment and traceability issues. With ALM Octane all different teams with their tool islands can be integrated seemlessly and avoid any kind of media breaches.
EMBRACE, ADOPT, INTEGRATE & SCALE — ALM Octane integrates by nature your DevOps toolchain and enables your organization to seamlessly follow the process. ALM Octane is open minded and integrates into your DevOps tool chain.
ALM Octane is a lifecycle management solution support all teams across the DevOps lifecycle:
- Keep your Agile teams or Agile vs. Waterfall teams connected from the very beginning,
- Reduce TCO by consolidating separate tools,
- Modernize your test and quality management,
- Achieve end-to-end automation,
- Extend Agile practices to QA and Operations
ALM Octane leverages modern ways of maintaining relationships between lifecycle activities and artifacts. It drives focus in teams with tagging and intelligent search so that teams can rapidly find the information needed to collaborate on quality and code readiness at any time.
Try it out today: https://www.microfocus.com/en-us/products/alm-octane/free-trial
This article was created and edited by Thomas Köppner & Amir Khan
