Delivery – renierbotha ltd

Scrum of Scrums

June 13, 2023November 13, 2023Leave a comment

The Scrum of Scrums is a scaled agile framework used to coordinate the work of multiple Scrum teams working on the same product or project. It is a meeting or a communication structure that allows teams to discuss their progress, identify dependencies, and address any challenges that may arise during the development process. The Scrum of Scrums is often employed in large organisations where a single Scrum team may not be sufficient to deliver a complex product or project.

The primary purpose of the Scrum of Scrums is to facilitate coordination and communication among multiple Scrum teams. It ensures that all teams are aligned towards common goals and are aware of each other’s progress.

Here are some key aspects of the Scrum of Scrums:

Frequency:

The frequency of Scrum of Scrums meetings depends on the project’s needs, but they are often daily or multiple times per week to ensure timely issue resolution.
Shorter daily meetings focussing on progress, next steps and blockers can be substantiated by a longer weekly meeting covering an agenda of all projects and more detailed discussions.

Participants – Scrum Teams and Representatives:

In a large-scale project or programme, there are multiple Scrum teams working on different aspects of the product or project.
Each Scrum team is represented by one or more members (often the Scrum Masters or team leads) in the Scrum of Scrums meeting. Each team selects one or more representatives to attend the Scrum of Scrums meeting.
These representatives are typically Scrum Masters or team leads who can effectively communicate the status, challenges, and dependencies of their respective teams.
The purpose of these representatives is to share information about their team’s progress, discuss impediments, and collaborate on solutions.

Meeting Structure & Agenda:

The Scrum of Scrums meeting follows a structured agenda that may include updates on team progress, identification of impediments, discussion of cross-team dependencies, reviewing and updating the overall RAID log with associated mitigation action progress and and collaborative problem-solving.
A key focus of the Scrum of Scrums is identifying and addressing cross-team dependencies. Teams discuss how their work may impact or be impacted by the work of other teams, and they collaboratively find solutions to minimise bottlenecks and define a overall critical path / timeline for the project delivery.

Tools and Techniques:

While the Scrum of Scrums is often conducted through face-to-face meetings, organisations may use various tools and techniques for virtual collaboration, especially if teams are distributed geographically. Video conferencing, collaboration platforms, and digital boards are common aids.

Focus on Coordination:

The primary goal of the Scrum of Scrums is to facilitate communication and coordination among the different Scrum teams.
Teams discuss their plans, commitments, and any issues they are facing. This helps in identifying dependencies and potential roadblocks early on.

Problem Solving:

If there are impediments or issues that cannot be resolved within individual teams, the Scrum of Scrums provides a forum for collaborative problem-solving.
The focus is on finding solutions that benefit the overall project, rather than just individual teams.

Scaling Agile:

The Scrum of Scrums is in line with the agile principles of adaptability and collaboration. It allows organisations to scale agile methodologies effectively by maintaining the iterative and incremental nature of Scrum while accommodating the complexities of larger projects.

Information Flow: & Sharing

The Scrum of Scrums ensures that information flows smoothly between teams, preventing silos of knowledge and promoting transparency across the organisation.
The Scrum of Scrums provides a platform for teams to discuss impediments that go beyond the scope of individual teams. It fosters a collaborative environment where teams work together to solve problems and remove obstacles that hinder overall progress.
Transparency is a key element of agile development, and the Scrum of Scrums promotes it by ensuring that information flows freely between teams. This helps prevent misunderstandings, duplication of effort, and ensures that everyone is aware of the overall project status.

Adaptability:

The Scrum of Scrums is adaptable to the specific needs and context of the organisation. It can be tailored based on the size of the project, the number of teams involved, and the nature of the work being undertaken.

In summary, the Scrum of Scrums is a crucial component in the toolkit of agile methodologies for large-scale projects. It fosters collaboration, communication, and problem-solving across multiple Scrum teams, ensuring that the benefits of agile development are retained even in complex and extensive projects.

In Summary, the Scrum of Scrums is a crucial component in the toolkit of agile methodologies for large-scale projects. It fosters collaboration, communication, and problem-solving across multiple Scrum teams, ensuring that the benefits of agile development are retained even in complex and extensive projects.

It’s important to note that the Scrum of Scrums is just one of several techniques used for scaling agile. Other frameworks like SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum), and Nexus also provide structures for coordinating the work of multiple teams. The choice of framework depends on the specific needs and context of the organisation.

Solution Design & Architecture (SD&A) – Consider this…

September 24, 2020October 18, 2023Leave a comment

When it comes to the design and architecture of enterprise level software solutions, what comes to mind?

What is Solution Design & Architecture:

Solution, Design and Architecture (SD&A) is an in-depth IT scoping and review process that bridges the gap between your current IT environments, technologies, and the customer and business needs in order to deliver maximum return-on-investment. A proper design and architecture document also documents the approach, methodology and required steps to deliver the solution.

SD&A are actually two distinct disciplines. Solution Architect’s, with a balanced mixed of technical and business skills, write up the technical design of an environment and work out how to achieve a solution from a technical perspective. Solution Designers put the solution together and price it up based from assistance from the architect.

A solutions architect needs significant people and process skills. They are often in front of management, trying to explain a complex problem in laymen’s terms. They have to find ways to say the same thing using different words for different types of audiences, and they also need to really understand the business’ processes in order to create a cohesive vision of a usable product.

Solution Architect focuses on:

market opportunity
technology and requirements
business goals
budget
project timeline
resourcing
ROI
how technology can be used to solve a given business problem
which framework, platform, or tech-stack can be used to create a solution
how the application will look, what the modules will be, and how they interact with each other
how things will scale for the future and how they will be maintained
figuring out the risk in third-party frameworks/platforms
finding a solution to a business problem

Here are some of the main responsibilities of a solutions architect:

Ultimately, the Solution Architect is responsible for the vision that underlies the solution and the execution of that vision into the solution.

Creates and leads the process of integrating IT systems for them to meet an organization’s requirements.
Conducts a system architecture evaluation and collaborates with project management and IT development teams to improve the architecture.
Evaluates project constraints to find alternatives, alleviate risks, and perform process re-engineering if required.
Updates stakeholders on the status of product development processes and budgets.
Notifies stakeholders about any issues connected to the architecture.
Fixes technical issues as they arise.
Analyses the business impact that certain technical choices may have on a client’s business processes.
Supervises and guides development teams.
Continuously researches emerging technologies and proposes changes to the existing architecture.

Solution Architecture Document:

The Solution Architecture provides an architectural description of a software solution and application. It describes the systems and it’s features based on the technical aspects, business goals, and integration points. It is intended to address a solution to the business needs and provides the foundation/map of the solution requirements driving the software build scope.

High level Benefits of Solution Architecture:

Builds a comprehensive delivery approach
Stakeholder alignment
Ensures a longer solution lifespan with the market
Ensures business ROI
Optimises the delivery scope and associated effectiveness
Easier and more organised implementation
Provides a good understanding of the overall development environment
Problems and associated solutions can be foreseen

Some aspects to consider:

When doing an enterprise level solution architecture, build and deployment, a few key aspects come to mind that should be build into the solution by design and not as an after thought…

Solution Architecture should a continuous part of the overall innovation delivery methodology – Solution Architecture is not a once-off exercise but is imbedded in the revolving SDLC. Cyclically evolve and deliver the solution with agility that can quickly adapt to business change with solution architecture forming the foundation (map and sanity check) before the next evolution cycle. Combine the best of several delivery methodologies to ensure optimum results in bringing the best innovation to revenue channels in the shortest possible timeframe. Read more on this subject here.
People – Ensure the right people with the appropriate knowledge, skills and abilities within the delivery team. Do not forget that people (users and customers) will use the system – not technologists.
Risk – as the solution architecture evolves, it will introduce technology and business risks that must be added to the project risk register and addressed to mitigation in accordance with the business risk appetite.
Choose the right software development tech stack that is well established and easily supported while scalable and powerful enough to deliver a feature rich solution that can be integrated into complex operational estates. Most tech-stacks has Solution Frameworks that outline key design options and decision when doing solution architecture. Choosing the right tech-stack is one of the most fundamental ways to future-proof the technology solution. You can read more on choosing the right tech stack here.
Modular approach – using a service oriented architecture (SOA) model to ensure the solution can be functionally scaled, up and down to align with feature required, by using independently functioning modules of macro and micro-services. Each service must be clearly defined with input, process, output parameters that aligns with the integration standard established for the platform. This SOA also assist in overall information security enhancements and fault finding in case something goes wrong. It also makes the developed platform more agile to adapt to continuous business environment and market changes with less overall impact and system changes.
Customer data at the heart of a solution – Be clear on Master vs Slave customer and data records and ensure the needed integration between master and slave data within inter-connecting systems and platforms, with the needed security applied to ensure privacy and data integrity. Establish a Single Customer and Data Views (single version of the truth) from the design off-set. Ensure personal identifiable data is handled within the solution according to the regulations as outlined in the Data Protection Act and recently introduced GDPR and data anonymisation and retention policy guidelines.
Platform Hosting & Infrastructure – What is the intended hosting framework, will it by private or public cloud, running in AWS or Azure – all important decisions that can drastically impact the solution architecture.
Scalability – who is the intended audience for the different modules and associated macro services within the solution – how many consecutive users, transactions, customer sessions, reports, dashboards, data imports & processing, data transfers, etc…? As required, ensure the solution architecture accommodate the capability for the system to monitor usage and automatically scale horizontally (more processing/data (hardware) nodes running in parallel without dropping user sessions) and vertically (adding more power to a hardware node).
Information and Cyber Security – A tiered architecture ensure physical differentiation between user and customer facing interfaces, system logic and processing algorithms and the storage components of a solution. Various security precautions, guidelines and best practices should be imbedded within the software development by design. This should be articulated within the solution architecture, infrastructure and service software code. Penetration Testing and the associated platform hardening requirements should feed back into the solution architecture enhancement as required.
Identity Management – Single Sign On (SSO) user management and application roles to assign access to different modules, features and functionality to user groups and individuals.
Integration – data exchange, multi-channel user interface, compute and storage components of the platform, how the different components inter-connects through secure connection with each other, other applications and systems (API and gateway) within the business operations estate and to external systems.
Customer Centric & Business Readiness – from a customer and end-user perspective what’s needed to ensure easy adoption (familiarity) and business ramp-up to establish a competent level of efficiency before the solution is deployed and go-live. UX, UI, UAT, Automated Regression Testing, Training Material, FAQs, Communication, etc…
Enterprise deployment – Involvement of all IT and business disciplines i.e. Business readiness (covered above), Network, Compute, Cyber Security, DevOps. Make sure non-functional Dev-Ops related requirements are covered in the same manner as
Application Support – Involve the support team during product build to ensure they have input and understanding of the solution to provide SLA driven support at to business and IT operations when the solution goes live.
Business Continuity – what is required from an IT infrastructure and platform/solution capability perspective to ensure the system is always available (online) to enable continuous business operations?

Speak to Renier about your solution architecture requirements. With more than 20 years of enterprise technology product development experience, we can support your team toward delivery excellence.

Also Read:

Release Management as a Competitive Advantage

November 2, 2018November 10, 2022Leave a comment

“Delivery focussed”, “Getting the job done”, “Results driven”, “The proof is in the pudding” – we are all familiar with these phrases and in Information Technology it means getting the solutions into operations through effective Release Management, quickly.

In the increasingly competitive market, where digital is enabling rapid change, time to market is king. Translated into IT terms – you must get your solution into production before the competition does, through an effective ability to do frequent releases. Doing frequent releases benefit teams as features can be validated earlier and bugs detected and resolved rapidly. The smaller iteration cycles provide flexibility, making adjustments to unforeseen scope changes easier and reducing the overall risk of change while rapidly enhancing stability and reliability in the production environment.

IT teams with well governed agile and robust release management practices have a significant competitive advantage. This advantage materialises through self-managed teams consisting of highly skilled technologist who collaborative work according to a team defined release management process enabled by continuous integration and continuous delivery (CICD), that continuously improves through constructive feedback loops and corrective actions.

The process of implementing such agile practices, can be challenging as building software becomes increasingly more complex due to factors such as technical debt, increasing legacy code, resource movements, globally distributed development teams, and the increasing number of platforms to be supported.

To realise this advantage, an organisation must first optimise its release management process and identify the most appropriate platform and release management tools.

Here are three well known trends that every technology team can use to optimise delivery:

1. Agile delivery practises – with automation at the core

So, you have adopted an agile delivery methodology and you’re having daily scrum meetings – but you know that is not enough. Sprint planning as well as review and retrospection are all essential elements for a successful release, but in order to gain substantial and meaningful deliverables within the time constraints of agile iterations, you need to invest in automation.

An automation ability brings measurable benefits to the delivery team as it reduces the pressure on people in minimising human error and increasing overall productivity and delivery quality into your production environment that shows in key metrics like team velocity. Another benefit automation introduces is consistent and repeatable process, enabling easily scalable teams while reducing errors and release times. Agile delivery practices (see “Executive Summary of 4 commonly used Agile Methodologies“) all embrace and promote the use of automation across the delivery lifecycle, especially in build, test and deployment automation. Proper automation support delivery teams in reducing overhead of time-consuming repetitive tasks in configuration and testing so them can focus on the core of customer centric product/service development with quality build in. Also read “How to Innovate to stay Relevant“; “Agile Software Development – What Business Executives need to know” for further insight in Agile methodologies…

Example:

Code Repository (version Control) –> Automated Integration –> Automated Deployment of changes to Test Environments –> Platform & Environment Changes automated build into Testbed –> Automated Build Acceptance Tests –> Automated Release

When a software developer commits changes to the version control, these changes automatically get integrated with the rest of the modules. Integrated assembles are then automatically deployed to a test environment – changes to the platform or the environment, gets automatically built and deployed on the test bed. Next, build acceptance tests are automatically kicked off, which would include capacity tests, performance, and reliability tests. Developers and/or leads are notified only when something fails. Therefore, the focus remains on core development and not just on other overhead activities. Of course, there will be some manual check points that the release management team will have to pass in order to trigger next the phase, but each activity within this deployment pipeline can be more or less automated. As your software passes all quality checkpoints, product version releases are automatically pushed to the release repository from which new versions can be pulled automatically by systems or downloaded by customers.

Example Technologies:

Build Automation: Ant, Maven, Make
Continuous Integration: Jenkins, Cruise Control, Bamboo
Test Automation: Silk Test, EggPlant, Test Complete, Coded UI, Selenium, Postman
Continuous Deployment: Jenkins, Bamboo, Prism, Microsoft DevOps

2. Cloud platforms and Virtualisation as development and test environments

Today, most software products are built to support multiple platforms, be it operating systems, application servers, databases, or Internet browsers. Software development teams need to test their products in all of these environments in-house prior to releasing them to the market.

This presents the challenge of creating all of these environments as well as maintaining them. These challenges increase in complexity as development and test teams become more geographically distributed. In these circumstances, the use of cloud platforms and virtualisation helps, especially as these platforms have recently been widely adopted in all industries.

Automation on cloud and virtualised platforms enables delivery teams to rapidly spin up/down environments optimising infrastructure utilisation aligned with demand while, similar to maintaining code and configuration version history for our products, also maintain the version history of all supported platforms. Automated cloud platforms and virtualisation introduces flexibility that optimises infrastructure utilisation and the delivery footprint as demand changes – bringing savings across the overall delivery life-cycle.

Example:

When a build and release engineer changes configurations for the target platform – the operating system, database, or application server settings – the whole platform can be built and a snapshot of it created and deployed to the relevant target platforms.

Virtualisation: The virtual machine (VM) is automatically provisioned from the snapshot of base operating system VM, appropriate configurations are deployed and the rest of the platform and application components are automatically deployed.

Cloud: Using a solution provider like Azure or AWS to deliver Infrastructure-as-a-Service (IaaS) and Platform as a Service (PaaS), new configurations can be introduced in a new environment instance, instantiated, and configured as an environment for development, testing, staging or production hosting. This is crucial for flexibility and productivity, as it takes minutes instead of weeks to adapt to configuration changes. With automation, the process becomes repeatable, quick, and streamlines communication across different teams within the Tech-hub.

3. Distributed version control systems

Distributed version control systems (DVCS), for example GIT, Perforce or Mercurial, introduces flexibility for teams to collaborate at the code level. The fundamental design principle behind DVCS is that each user keeps a self-contained repository with complete version history on one’s local computer. There is no need for a privileged master repository, although most teams designate one as a best practice. DVCS allow developers to work offline and commit changes locally.

As developers complete their changes for an assigned story or feature set, they push their changes to the central repository as a release candidate. DVCS offers a fundamentally new way to collaborate, as developers can commit their changes frequently without disrupting the main codebase or trunk. This becomes useful when teams are exploring new ideas or experimenting as well as enabling rapid team scalability with reduced disruption.

DVCS is a powerful enabler for the team that utilise an agile-feature-based branching strategy. This encourages development teams to continue to work on their features (branches) as they get ready, having fully tested their changes locally, to load them into next release cycle. In this scenario, developers are able to work on and merge their feature branches to a local copy of the repository.After standard reviews and quality checks will the changes then be merged into the main repository.

To conclude

Adopting these three major trends in the delivery life-cycle enables a organisation to imbed proper release management as a strategic competitive advantage. Implementing these best practices will obviously require strategic planning and an investment of time in the early phases of your project or team maturity journey – this will reduce the organisational and change management efforts to get to market quicker.

How to Innovate to stay Relevant

August 21, 2018October 18, 20235 Comments

Staying relevant! The biggest challenge we all face – staying relevant within our market. Relevance to your customers is what keeps you in business.

With the world changing as rapidly as it does today, mainly due to the profound influence of technology on our lives, the expectations of the consumer is changing at pace. They have access to an increasing array of choice, not just in how they spend their money but also in how they are communicating and interacting – change fueled by a digital revolution. The last thing that anyone can afford, in this fast paced race, is losing relevance – that will cost us customers or worse…

Is what you are selling today, adaptable to the continuous changing ecosystems? Does your strategy reflect that agility? How can you ensure that your business stays relevant in the digital age? We have all heard about digital transformation as a necessity, but even then, how can you ensure that you are evolving as fast as your customers and stay relevant within your market?

Business, who has a culture of continuous evolvement, aligning their products and services with the digital driven customer, is the business that stays relevant. This is the kind of business that does not require a digital transformation to realign with customer’s demand to secure their future. A customer centric focus and a culture of continuous evolution within the business, throughout the business value chain, is what assure relevance. Looking at these businesses, their ability/agility to get innovation into production, rapidly, is a core success criterion.

Not having a strategy to stay relevant is a very high and real risk to business. Traditionally we deal with risk by asking “Why?”. For continuous improvement/evolution and agility, we should instead be asking “Why not?” and by that, introduce opportunities for pilots, prototypes, experimentation and proof of concepts. Use your people as an incubator for innovation.

Sure, you have a R&D team and you are continuously finding new ways to deliver your value proposition – but getting your innovative ideas into production is cumbersome, just to discover that it is already aged and possibly absolute in a year a two. R&D is expensive and time consuming and there are no guarantees that your effort will result in a working product or desired service. Just because you have the ability to build something, does not mean that you have to build something. Focusing the scares and expensive resources on the right initiatives makes sense, right! This is why many firms are shifting from a project-minded (short term) approach to a longer-term product-minded investment and management approach.

So, how do you remain customer centric, use your staff as incubators of innovation, select the ideas that will improve your market relevance and then rapidly develop those ideas into revenue earners while shifting to a product-minded investment approach?

You could combine Design Thinking with Lean Startup and Agile Delivery…

In 2016, I was attending the Gartner Symposium where Gartner brought these concepts together very well in this illustration:

Instead of selecting and religiously follow one specific delivery methodology, use the best of multiple worlds to get the optimum output through the innovation lifecycle.

Using Design Thinking (Empathise >> Define >> Ideate >> Prototype) puts the customer at the core of customer centric innovation and product/service development. Starting by empathising with the customers and defining their most pressing issues and problems, before coming up with a variety of ideas to potentially solve the problems. Each idea is considered before developing a prototype. This dramatically reduces the risk of innovation initiatives, by engaging with what people (the customer) really need and want before actually investing further in development.

Lean Startup focuses on getting a product market fit, by moving a Prototype or MVP (minimum viable product) through a cycle of Build >> Measure >> Learn. This ensures a thorough knowledge of the user of the product/service is gained through an active and measureable engagement with the customer. Customer experience and feedback is captured and used to learn and adapt resulting in an improved MVP, better aligned to the target market, after every cycle.

Finally Agile Scrum, continuing the customer centric theme, involves multiple stakeholders, especially users (customers), in every step in maturing the MVP to a product they will be happy to use. This engagement enhances transparency, which in turn grow the trust between the business (Development Team) and the customer (user) who are vested in the product’s/service’s success. Through an iterative approach, new features and changes can be delivered in an accurate and predictable timeline quickly and according to stakeholder’s priorities. This continuous product/service evolvement, with full stakeholder engagement, builds brand loyalty and ensures market relevance.

Looking at a typical innovation lifecycle you could identify three distinct stages: Idea, Prototype/MVP (Minimal Viable Product) and Product. Each of these innovation stages are complimented by some key value, gained from one of the three delivery methodologies:

All of these methodologies, engage the stakeholders (especially the customer & user) in continuous feedback loops, measuring progress and capturing feedback to adapt and continuously improve, so maximum value creation is achieved.

No one wants to spend a lot of resource and time delivering something that adds little value and create no impact. Using this innovation methodology and associated tools, you will be building better products and service, in the eye of the user – and that’s what matters. You’ll be actively building and unlocking the potential of you’re A-team, to be involved in creating impact and value while cultivating a culture of continuous improvement.

The same methodology works very well for digital transformation programmes.

At the very least, you should be experimenting with these delivery approaches to find the sweat spot methodology for you.

Experiment to stay relevant!

Let’s Talk – renierbotha.com – Are you looking to develop an innovation strategy to be more agile and stay relevant? Do you want to achieve your goals faster? Create better business value? Build strategies to improve growth?

We can help – make contact!

Read similar articles for further insight in our Blog.