This is the first in a two-part post that describes the mindset and methods of this digital engine. Part 1 looks at mainly Mindset and method, whilst part 2 looks at the technologies that enables them.
For an effective digital organisation, developing an appropropriate mindset is a prerequisite to effective use of tools and technologies before people blindly implement such things as kanban boards only.
When you scratch the surface of a Devops and Agile mindset, you will find that there are similarities in many attitudes and approaches. That’s a good thing. Although they may hail from different corners and may use different terms, Digital requires it.
The first, called Agile, is true to its name, promoting adaptability and collaboration for maximal focus on developing code that delivers customer outcomes quickly. The second, DevOps, bridges the gap between the Development and Operations teams where they start to work together to streamline workflow and massively increase their overall speed and reliability on delivering code at massive scale.
For more information on tools and technologies of API Libraries, Micro Services and Application Platforms, please see part 2 (to be released). Let’s dive a bit deeper on the Mindset Aspects.
Unlike the familiarly rigid Waterfall method, in which long-term projects are mapped out stage by stage, Agile avoids burnout and disappointing delivery by creating a dynamic work environment.
It does this through the 12 Principles of the Agile Manifesto, as well as advocating these four values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These core values provide guidance while allowing plenty of flexibility - an approach that over 70% of organisations find favorable for certain tasks. Over several decades of Agile implementation, we’ve found certain techniques best facilitate the principles:
Scrum Software Product Development
The best known application of Agile, Scrum is a strategy centered around short work cycles, transparency, and evolving customer needs. It’s core structure typically entails:
- Daily Standup Meetings - To ensure the whole team’s up to date, as to better prevent against unforeseen issues or looming conflicts.
- Product and Sprint Backlog - To prioritize products for Sprints, which are iterations of 2 to 4 weeks where developers organize themselves to build said products.
- Breaking Down User Needs - To further prioritize tasks for each product accordingly.
- Sprint Retrospectives - To review performance and assess how to approach future Sprints.
… And it relies on a team consisting of a Product Manager (who prioritizes the Backlog), the Developers (who product the software), and a Scrum Master (who helps focus overall scrum activities).
The benefit of this approach is the quick turnaround: at the end of each sprint, the team receives feedback and the customer receives a deliverable.
Extreme Programming (XP)
Developers run into software bugs - it’s inevitable. What we can control is how we respond; XP transcends band-aid quick-fix solutions to reduce overall errors through these workplace themes:
- Relaxed Minds - Realistic deadlines and expectations make productivity soar and mistakes decline.
- Pairing - Two minds (writing the same code) are greater than one.
- Mistake-Friendly Atmosphere - Letting lessons be learned and corrected rather than covered up.
- Easily Modifiable Code - Simple modular structures, for instance, allow for frequent changes and more responsiveness.
- Build Tests Before Code - Easily identify your code’s success criteria.
- Refactor - Account for slack time in your scheduling (to pay down technical debt)
- And more… As the philosophy continues to evolve.
When successfully implemented, the XP mentality results in greater flexibility, less burnout, and an improved overall experience for our development teams.
Have you ever experienced a software Groundhog Day? Where the same type of problem continues to resurface and you keep fixing it the same way?
Adopted from Toyota’s production system, Lean looks at the whole development life cycle, improving workflow to find solutions that prevent such recurrences. Of the guiding principles of Lean, Eliminating Waste is the biggest point of emphasis. In software terms, “waste” can describe waiting time, partially completed work, extra processes and features, task switching, and defects.
To combat waste, Lean has a toolbox at our disposal: Value Stream Mapping to identify it, Fishbone Diagrams and the “Five Why’s” to pinpoint the root causes, and Brainstorming to drum up potential solutions.
When applied effectively, the result reduces waste consequences like production costs and lead time.
This visual management technique inspects the real-world process of your whole development lifecycle by examining and redistributing resource allocation at key stages.
The magic lies in spotting bottlenecks as they begin to stack up and shifting people’s priorities to handle more urgent tasks. With this mentality founded on broader role descriptions and fluid responsibilities, it’s much easier to smooth out bottlenecks quickly before they impact customers. And it particularly lends itself to delivering results on a continuous basis.
For an easy read on Agile, I recommend Head First Agile by Andrew Stellman and Jennifer Greene.
Historically, Developers and Infrastructure/Application Support teams have worked in silos, with “Us vs. Them” attitudes that bred inefficiency and high lead times.
The DevOps approach merges development and support into one holistic process to exponentially improve productivity, reliability, team cohesion, and quality of service. The environment is predicated on frequent communication and documentation, as well as these strategies.
Searching for a bug after deploying new code can be like looking for a needle in a haystack. But with automated regression testing, we can do just that - scan through thousands of scenarios and check whether, say, the payment processing still works smoothly.
Due to the sheer number of test scripts in each new modular unit of code, automation saves us from performing an astronomical number of laborious routine tests. In other words, it improves and accelerates our chances of finding the needle.
Continuous Integration and Delivery
Let’s consider Ebay: They frequently make small website changes to optimize user engagement. How can they do this hundreds of times a day without the site crashing? With Continuous Integration and Continuous Delivery (CI/CD) technology.
The key aim of these techniques is shortening lead time to delivery while improving quality of code by applying changes “little and often.” Thus, errors can be resolved quickly and new applications can easily be deployed and installed. Furthermore, this latter step - from testing code to delivering it in a live environment - can be automated to take as little as ten minutes, effectively reducing testing costs and improving customer experience.
These techniques brings all the of the different software development aspects into one "pipeline" and are typically facilitated by CI / CD automation tools, such as Gitlab or Azure Devops.
For an easy read on Devops, I recommend The Phoenix Project by Gene Kim and Kevin Beh.
Has your organisation implemented some aspects of digital and not others? How deep has the change in mindset been as a result of using these new practices? Are the benefits of digital enablement obvious from the customer’s perspective?
When you start to compare the likes of Amazon.com against a standard high street retail shopping experience, you begin to understand how different these organisations are at a fundamental level.
Assessing the maturity of your organisation against the Principles of Digital Transformation (see previous post) and the practices required by the Digital Engine will help you grasp the degree of change required by your organisation to attain those benefits.
Transforming your business to a digital business, much like changing a plane engine mid-flight is a risky proposition. Indeed, can the organisation make it? If you were to retrofit a jet engine to propeller plane, would it still fly.
Transforming your business to a digital business, much like changing a plane engine mid-flight is a risky proposition. Indeed, can the organisation make it? If you were to retrofit a jet engine to propeller plane, would it still fly?