Book a demo

Features

Pricing

Contact

Blog

Login

logo_agile_analytics 5 (1).png

Logo Agile Analytics

Subscribe

Subscribe to Agile Analytics' newsletter

Introducing Agile Analytics Teams Reporting

We’ve got some exciting news from Agile Analytics. Our new feature, "Teams Reporting," is here! 

We’ve got some exciting news from Agile Analytics. Our new feature, "Teams Reporting," is here! This gives you all the metrics to track and improve your team’s performance.  

Teams Reporting empowers your teams to see how they score compared to their (Service Level) objectives, how much Error Budget is left, and whether the team focuses on Features or Non-Feature work. This new addition to Agile Analytics comes from the philosophy that productivity, risks and service level information inside software projects must be combined from all three contexts of the project: Development, Operations and Project. Combining these three parts enables a full 360-degree view of the team’s performance.

Teams Reporting include all the metrics from Agile Analytics reported per team: 

The reports are sprint-based by default, covering one sprint as the time, though you can customize this to fit your needs.
     
Measuring team performance helps you see where things are going smoothly and where they need to be improved. It boosts collaboration, aligns everyone toward common goals, and drives continuous improvement. In short, it’s your new go-to for making your team more productive and efficient.

Why Measuring team-based performance is essential?

Measuring team-based performance is essential for several reasons:     
     
      
1. **Spotting Bottlenecks:** We can quickly identify and address inefficiencies by tracking performance.

2. **Aligned, Common Goals:** This ensures that all team members work toward the same objectives, improving focus, cohesion, and autonomy.

3. **Continuous Improvement:** Regular measurement allows for ongoing assessment and refinement of processes, leading to higher-quality outcomes.


Ready to see the difference Agile Analytics can make for your team? Sign up now for a free trial or contact our experts and experience the power of Teams Reporting firsthand. Our experts are on hand to help you set everything up and get the most out of your trial. Don't miss this opportunity to revolutionize your team's performance with cutting-edge metrics and insights.

Team Topologies - The Reverse Conway Manoeuvre

From the book [“Team Topologies”](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies) by Matthew Skelton and Manuel Pais comes an interesting fix to Conway’s Law: 

From the book [“Team Topologies”](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies) by Matthew Skelton and Manuel Pais comes an interesting fix to Conway’s Law: 

> Organisations, who design systems, are constrained to produce designs which are copies of the communication structures of these organisations. 

So let's start with a quick recap of Conway’s law's implications. Specifically: the negatives/blind spot of organisations: **An organisation that's arranged in functional silos** (where teams specialise in a particular function: such as QA, DBA, or security) **is unlikely ever to produce software systems that are well-architected for end-to-end flow**.

To increase an organisation’s chances of building effective software systems optimised for end-to-end flow, a *“Reverse Conway Manoeuvre”* (or Inverse Conway Manoeuvre) can be undertaken to reconfigure the team intercommunications before the software is finished.

Nicole Forsgren wrote about this first, back in 2015, in her excellent book [Accelerate](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Fp%2Faccelerate%2F9200000080652224%2F&name=Accelerate).

> Our research lends to support to what is sometimes called the 'inverse Conway maneuver,” which states that organizations should evolve their team and organizational structure to achies the desired architecture. The goal is for your architecture to support the ability of teams to get their work done - from design through to deployment - without requiring high-bandwidth communication between teams

Let’s look at a deliberate simplification of Conway’s law in an organisation that develops software. In the first (out of 4) figure, you see four teams each comprised of front-end and back-end developers. They work on different parts of a system and then hand them over to a central database administrator (DBA) for database changes. The flow of changes may look like Figure 1.

According to Conway’s law, the software architecture that naturally emerges from such a team design would have separate front-end and back-end components for each team and a single, shared core database (Figure 2). In other words, the use of a shared DBA team is likely to drive the emergence of a single shared database; the same goes, in the opposite direction, for Front-end and Back-end developers: it will lead to separate UI and app tiers, see figure 2.

We now apply the Reverse Conway Manoeuvre and design our teams to match the required software architecture by having a separate developer for the client applications and the API, and a database developer within the team rather than separate it, see figure 3.

Figure 3: Organisation using Microservices

According to Conway’s law, this team design in the organisation will most ‘naturally’ produce the desired software architecture. Each of the separate teams has a self-sustaining system, no central database, and by having end-to-end capabilities using client and API developers in the team and datastore knowledge handy, the team and architecture are optimised for end-to-end flow! see figure 4.

Figure 4: Architecture, microservices and post Conway Manoeuvre

Conway’s law is not exclusively applicable to Software development: software delivery and software deployment can suffer from Conway’s Law.

If we consider the following pipeline with a centralised QA and Operations (pre-DevOps) you will get ‘interesting’ releases of your product.

Optimising for end-to-end flow and changing the organisation because of this optimisation has been a standard practice since Continuous Delivery gained popularity in 2012. We make QA and Ops part of the new ‘delivery teams’ in this scenario. We transform the central QA and central Ops into a distributed team that operates inside the different end-to-end optimised teams. (DevOps, BizDevOps etc.)

What remains are the platforms: these are maintained by the platform teams. We’ve written a good article about this here on our site:  [How to setup a successful Cloud Platform Team](https://zensoftware.nl/en/news/2022/6/how-to-setup-a-successful-cloud-platform-team).

For software architecture and software delivery, the organisation and communication lines in it are best explained by ‘Conway’s Law'. By performing the **Reverse Conway Manoeuvre**, you change the organisation to optimise your software architecture and delivery for optimal flow.



Observing and managing end-to-end flow is at the core of our product. Agile Analytics provides critical insights into your organisation’s software development operation.

What is agile?

Agile, Scrum, and Kanban are popular methodologies used in software development and project management. Each approach has unique characteristics, but all share a common goal: to make the development process more efficient and effective.


Agile methodology is a flexible and iterative approach to software development. It emphasizes collaboration, continuous improvement, and customer satisfaction. The Agile Manifesto states that working software is more important than comprehensive documentation and that responding to change is more valuable than [following a plan](https://agilemanifesto.org/).

Scrum is a framework within the Agile methodology. It emphasizes teamwork, accountability, and frequent progress checks. An organisation that employs Scrum knows the following roles: a Product Owner, a Scrum Master, and a Development Team member. Teams are autonomous and consist of 7 members (5 min, 9 max). The teams work in time-boxed iterations called **sprints**, with the goal of delivering a potentially shippable product increment at the end of each sprint. The scrum master guards the process, and the Product Owner decides what goes into a sprint and guides the teams in implementing his/her product vision.

Kanban is another framework within the Agile methodology, it stems from Lean and the Toyota Production System (TPS). It emphasizes visualization, workflow optimization, and continuous delivery. Kanban teams use a board with columns that represent different stages of work. Each task is represented by a card that moves from one column to the next as it progresses through the workflow. instead of sprint retrospectives like the ‘scrum-folk’ have: Kanban teams use Kaizen ('Good Change' from Japanese) sessions to reflect and improve on the process and outcomes.

Agile Analytics is a platform for optimizing software development. The platform allows teams to gain insights into their entire pipeline and integrates against all the tools used rather than being limited to Jira or Git. Agile Analytics integrates various systems like your project management system (Jira, Azure DevOps), monitoring systems (AWS CloudWatch, GCP Cloud Monitor, Azure Monitor), collaborative communication systems (Slack, Teams or Discord), and continuous delivery (like Github, Gitlab or Bit Bucket). Using this platform, teams can make more informed decisions and become data-driven! We’d love to show you how we can [supercharge your software operation](https://www.agileanalytics.cloud/request-demo)! 

In conclusion, Agile, Scrum, and Kanban are popular methodologies that are used in software development and project management. Agile is a flexible and iterative approach to software development, Scrum is a framework within the Agile methodology that emphasizes teamwork and accountability, and Kanban is another framework within the Agile methodology that emphasizes visualization and workflow optimization. These methodologies can be used separately or together depending on the project's needs. When the teams are working agile, measuring key metrics like productivity changes, our [next article shows you how to get insights into key metrics in an agile software development environment.](https://www.agileanalytics.cloud/blog/2023/4/how-to-measure-software-development-productivity)

How to setup a successful Cloud Platform Team

Most organisations have centralised (Cloud) platform teams (or they should). Setting up these teams is a fun challenge but a challenge nonetheless. In 2019  Matthew Skelton and Manuel Pais published their book [“Team Topologies”](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies). They share the secrets of successful team patterns and interactions to help readers choose and evolve the correct team patterns for their organisation, ensuring that the software is healthy and optimises value streams.

- [Pitch](#pitch)
- [Four Team Types](#four-team-types)
    - [Stream-aligned team](#stream-aligned-team)
    - [Enabling team ](#enabling-team)
    - [Complicated subsystem team](#complicated-subsystem-team)
    - [Platform Team](#platform-team)
- [Interaction Modes](#interaction-modes)
    - [X-as-a-Service](#x-as-a-service)
    - [Facilitating](#facilitating)
- [The complete picture](#the-complete-picture)
- [Want more?](#want-more)



Most organisations have centralised (Cloud) platform teams (or they should). Setting up these teams is a fun challenge but a challenge nonetheless. In 2019  Matthew Skelton and Manuel Pais published their book [“Team Topologies”](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies). They share the secrets of successful team patterns and interactions to help readers choose and evolve the correct team patterns for their organisation, ensuring that the software is healthy and optimises value streams.

So you want to facilitate, transform or otherwise improve the use of Cloud or PaaS services inside your organisation, and you want to start a platform team. What is a good definition of a platform?

> A **digital platform** is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.      source: [martinfowler.com](martinfowler.com)

In this article and the [“Team Topologies”](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies) book, the above counts as a valid definition of a platform.

Now we'll try to establish an archetype/mould for the teams we are trying to create. [Team Topologies](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies) distinguishes four types of teams, we'll choose 'platform' for our platform team, obviously but the other team types play an important role as enablers, specialists or customers. 

###### Stream-aligned team {#stream-aligned-team}

The stream-aligned Team is your organisation's most common and primary team type. Typical examples are **feature teams**. The 'stream' means the continuous flow of work aligned to a business domain or organisational capability.

This type of Team is aligned to a single, valuable stream of work like:

- A single product or service
- **A single set of features**
- A single-user journey
- or a single user persona

This Team works on the full spectrum of delivery (from idea to production).

###### Enabling team {#enabling-team}

Enabling teams are continuously improving their capabilities to stay ahead. An Enabling team comprises specialists in a given technical (or product) domain. They help bridge this capability gap and have a strong collaborative nature. They avoid becoming “ivory towers” of knowledge and increase the autonomy of stream-aligned teams by growing their capabilities. Teams should not form a permanent dependency on an enabling team. We'll use this archetype for our **Cloud Acceleration Team**. 

###### Complicated subsystem team {#complicated-subsystem-team}

Responsible for building and maintaining a part of the system that depends heavily on specialist knowledge. The goal of a complicated-subsystem team is to reduce the cognitive load of stream-aligned teams. 

Examples : 

1. Video processing codec
2. Mathematical model
3. **Real-time trade reconciliation algorithm**
4. Transaction reporting system for financial services
5. Face-recognition engine

###### Platform Team {#platform-team}

The Purpose of this type of Team is:

- To enable stream-aligned teams to deliver work with substantial autonomy
- To provide internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services

Now that we've listed the four archetypes of the Team. Let's describe 2 (of the 3) interaction modes between the teams.

One Team consumes something (such as a service or an API) provided "as a service" by another team. Responsibilities are delineated, and -if the boundary is effective - the consuming Team can deliver rapidly. The Team providing the service seeks to make their service as easy to consume as possible.

Example: Stream-aligned teams consuming Platform-as-a-service from a platform team.

###### Facilitating {#facilitating}

One Team helps another team to learn or adopt new approaches for a defined period of time. The Team providing the facilitation aims to make the other Team self-sufficient as soon as possible, while the Team receiving the facilitation has an open-minded attitude.

Example: An enabling team helping a stream-aligned or platform team.



# The complete picture {#the-complete-picture}

If we put the interaction types and the team types together, we see a **Cloud Platform Team** (in blue) providing the Platform-as-a-Service to the Stream-aligned **Feature Team** (in yellow). The Stream-aligned Team is assisted by the Complicated-subsystem team (in orange/brown) for Specialist **Trade Systems** Knowledge and is facilitated (dotted overlap) by the **Cloud Acceleration Team** (in Purple).

Using these described roles & responsibilities, your organisation can utilise platforms at scale and avoid under-engineering, over-engineering and long queues because of overloaded central Cloud Teams. These queues lead to nasty side-effects like security issues, shadow-IT, higher attrition and lower engineer engagement. [Team Topologies](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies) allows your organisation to be very clear about the Team's responsibilities and way of interacting with other teams. This prevents all the above side effects and allows for **optimal flow in your organisation**.

Effective software teams are essential for any organisation to deliver value continuously and sustainably. [Team Topologies](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies) is a practical, step-by-step, adaptive model for organisational design and interaction based on four fundamental team types and three team interaction patterns. 

It is a model that treats teams as the fundamental means of delivery, where team structures and communication pathways can evolve with technological and organisational maturity. There is a good summary of the book that can be [found here](https://yoan-thirion.gitbook.io/knowledge-base/xtrem-reading/resources/book-notes/team-topologies), or you can purchase the book [here](https://partner.bol.com/click/click?p=2&t=url&s=1228221&f=TXL&url=https%3A%2F%2Fwww.bol.com%2Fnl%2Fnl%2Ff%2Fteam-topologies%2F9200000104858740%2F&name=Team%20Topologies).


New European Cybersecurity Regulations are coming! Increased Accountability for Corporate Leadership

Recent legal developments in Europe in the Cyber security field are set to impact businesses throughout Europe, particularly those involved in software development. With stricter regulations on the horizon, The NIS2 Directive is the EU-wide legislation on cybersecurity (The EU cybersecurity rules introduced in 2016 were updated by the NIS2 Directive).

Recent legal developments in Europe in the Cyber security field are set to impact businesses throughout Europe, particularly those involved in software development. With stricter regulations on the horizon, The NIS2 Directive is the EU-wide legislation on cybersecurity (The EU cybersecurity rules introduced in 2016 were updated by the NIS2 Directive). It provides legal measures to boost the overall level of cybersecurity in the EU. Companies must reassess and enhance their cybersecurity measures to comply with the impending changes.

Increased Accountability for Corporate Leadership

One key aspect of the new European policy is the heightened accountability placed on corporate leadership. Under the new regulations, company executives will be **explicitly** responsible for their organisation’s cybersecurity policies. Failure to fulfil these duties could result in personal liability, including potential temporary suspension from their positions.

Historically, many executives have delegated cybersecurity matters to IT departments, with their involvement limited to budget approvals. However, the upcoming regulations demand a more proactive role from them. They are now required to approve cybersecurity measures, oversee their implementation, and ensure the security of their direct suppliers.

Implications for Software Development Operations

Now that companies are digitally interconnected, a weak backdoor at a small supplier can affect the entire chain. The new regulations, therefore, compel large companies to take more responsibility for their suppliers. They must assist them, for example, by sharing their knowledge.

The rules will be enacted in the Netherlands in 2025 and in other EU countries. These regulatory changes necessitate organisations to complete their comprehensive review of procedures and enhance the security of software development operations. Developers must integrate cybersecurity considerations into every stage of the software development lifecycle, from design to deployment. This includes implementing robust authentication mechanisms, encryption protocols, and secure coding practices to mitigate cyber risks effectively.

Furthermore, software development companies must extend their cybersecurity efforts to encompass their supply chain. Collaborating with suppliers to enhance their security posture is essential in safeguarding the ecosystem against potential threats. For instance, make sure all your hosting providers and cloud providers have the necessary certifications in the cybersecurity field.

While the new regulations present challenges, they also create opportunities for innovation and growth within the software development industry. Companies proactively investing in cybersecurity measures can gain a competitive edge by demonstrating their commitment to data protection and risk mitigation. Additionally, the demand for cybersecurity professionals will likely surge, creating opportunities for skilled individuals in the job market.

The impending European cybersecurity regulations NIS2 underscore the critical importance of robust cybersecurity practices in software development operations. By proactively enhancing security measures and aligning with regulatory requirements, companies can mitigate risks, protect sensitive data, and ensure their corporate leadership is safe from personal liability because of security issues.

Introducing Agile Analytics by ZEN Software, your go-to solution for enhancing code security. Start your journey towards robust cybersecurity practices with Agile Analytics Leaks, a feature designed to fortify your code's defences. This tool seamlessly identifies leaked keys within your codebase, proactively mitigating the risk of unauthorized access and potential data breaches. By integrating Agile Analytics Leaks into your development workflow, you strengthen your software against evolving cyber threats. Embrace this opportunity to safeguard your digital assets effectively while experiencing the efficiency and reliability of the Analytics App.

Sign up now for a **60-day free trial** and discover the transformative capabilities of Agile Analytics firsthand.

 

Traditional Analytics or Agile Analytics: which one fits you best?

 In this article, we explore the key differences between Agile Analytics and Traditional Analytics to help organisations make informed decisions about their analytical strategies.

All organisations do analytics to extract insights from their data. Some organisations even make most of their decisions based on this data. Are there any distinct ways in which we can do analytics? We’ve found two prominent approaches: Agile Analytics and Traditional Analytics. Each has its own set of principles, practices, and advantages. In this article, we explore the key differences between Agile Analytics and Traditional Analytics to help organisations make informed decisions about their analytical strategies.

As the name suggests, this form of analytics has been around since Big Gates was modelling on his desk back when Microsoft was still a cool startup.

**Sequential Process:**

Traditional Analytics typically follows a sequential, waterfall-like process. It involves distinct phases such as data collection, cleansing, transformation, analysis, and reporting. Each phase is completed before moving on to the next, often resulting in lengthy project timelines.

**Rigorous Planning:**

In the traditional approach, extensive planning is done upfront to define requirements and scope. Changes to the project scope are often challenging to accommodate once the project is underway.

**Fixed Scope and Deliverables:**

Projects are planned with fixed scope and deliverables, making it challenging to adapt to evolving business needs or to incorporate new data sources during the project.

**Comprehensive Documentation:**

 Documentation is a key aspect of traditional analytics. Detailed documentation is created at each stage to provide a comprehensive understanding of the entire process.

**Long Development Cycles:**

The emphasis on thorough planning and documentation often leads to longer development cycles, and insights are delivered at the end of the project.

Since the early 2010s everything needed to become ‘agile’, because as we learnt everything is agile is better? well, it depends but for analytics, approaching things in a more ‘agile’ fashion actually makes sense

**Iterative and Incremental:**

 Agile Analytics, inspired by the principles of Agile software development, adopts an iterative and incremental approach. It divides the project into smaller, manageable iterations or sprints, each delivering a potentially shippable product increment.

**Adaptive Planning:**

 Agile Analytics embraces adaptive planning, allowing teams to respond to changing requirements and priorities. Planning is continuous and flexible, enabling adjustments based on ongoing feedback.

**Embraces Change:**

 One of the core principles of Agile is its adaptability to change. Agile Analytics acknowledges that requirements evolve throughout the project, and it accommodates changes to ensure that the end product aligns with business needs.

**Collaboration and Communication:**

 Agile places a strong emphasis on collaboration and communication within cross-functional teams. Regular meetings, such as daily stand-ups, facilitate constant communication and coordination among team members.

**Early and Continuous Delivery:**

 Agile Analytics aims for early and continuous delivery of insights. This allows stakeholders to gain value incrementally throughout the project, rather than waiting for a comprehensive solution at the project's end.

Agile Software Development and Agile Analytics go hand in hand, sharing principles of flexibility and collaboration. Aligning analytics with an Agile mindset is crucial for the following reasons:

1. **Rapid Adaptation:** Agile development involves frequent requirement changes. Agile Analytics is flexible and adapts quickly to evolving project needs.
2. **Frequent Releases:** Agile development operates on short cycles. Agile Analytics ensures rapid insights to support the quick-release cadence of Agile teams.
3. **Collaborative Decision-Making:** Agile promotes team collaboration. Agile Analytics involves stakeholders, ensuring insights align with business goals.
4. **User-Centric Focus:** Agile emphasizes delivering value to users. Agile Analytics provides rapid feedback on user behaviour, enhancing user-centric solutions.

In summary, aligning analytics with an Agile mindset promotes collaboration, flexibility, and continuous improvement, ensuring timely and relevant insights for Agile development teams. This integrated approach supports data-driven decision-making and contributes to overall project success.

Experience ZEN Software’s Agile Analytics

The next step is to employ an Analytics platform based on the same tenets for your Software Development. With Agile Analytics, you measure critical metrics like feature/non-feature balance, deployment frequency, and SRE Error budgets and monitor DORA metrics and Error Budgets.

Measuring Error Budgets in Agile Analytics

Gain unparalleled visibility into your sprint performance. Don't miss this chance to break free from traditional constraints and propel your organization to new heights.

We can help you out with a DevOps Assessment, Continuous Delivery conversion, a Lean Software Development Transformation or an SRE implementation. Start your Agile Analytics journey today!

Why is this a big deal?