Building Great Software Starts with Agile GovernanceThat’s why Pentagility equips teams with a modular toolkit of rules and dashboards that helps them go faster in the right direction.

Principle 1: The client is the most critical part of the team

If the Collaboration Framework represents Pentalog’s commitment to accelerating value delivery, its most important function is to remind us that the client is always the most critical part of the team.

We want clients to experience that feeling even during the pre-sales process. As we begin defining solutions, we do more than provide talent, we propose time-tested operational practices that set the stage for high-performing relationships.

Sometimes, clients come to us with an existing workflow and delivery model, often they are looking to us for guidance. We always start with a few basic rules which, time and time again, have proven invaluable in fostering productive collaboration.

At the end of the day, the Collaboration Framework is intended to help clients to ensure that our work remains aligned with the business and delivers what matters. The framework is a living governance artifact to bind us to our commitments.

Needless to say, we always seek to incorporate the client’s perspective on the collaboration first and foremost. We also offer a basic set of topics we cover with clients, which may be more or less elaborate depending on the nature of our work.

These basic rules typically include:

• Assignment of a Client Responsible Party
• Listing of the key business stakeholders
• Visibility on the business context
• Access to Tooling & Documentation
• Prompt & Complete Feedback
• User Acceptance Testing (UAT)

From that point, we can have a discussion with the client about the level of excellence needed as a delivery standard. These choices stem from the client’s business priorities in such a way as to focus the effort where it matters most.

Principle 2: Rules set a baseline of reasonable expectations

Rules define the reasonable expectations a team can have of itself and the client can have of Pentalog. This is why, for Pentagility, rules are always modular, so they can be launched and re-configured quickly and evolve over time.

We include rules to govern the commercial engagement and the services we are delivering. Many rules are familiar, such as scrum master, sprints, definitions of ready and done, burn-down charts, etc.

We also incorporate rules from growth, such as minimal viable tests (MVTs), growth sprints and product market fit, and we have a series of well-honed practices aligned with these rules. We can consider several staffing scenarios to illustrate the point:

• In an outsourcing relationship, the inclusion of an agile rule for a scrum master makes expectations about quality more or less reasonable.
• Similarly, the presence of specialists in security, UX/UI, DevOps, etc., brings unique rules defining what can reasonably be expected from these experts. A few brief examples add intuitive context:
  • For security, for the management and protection of data
  • For UX/UI related to the user experience, the interactions
  • For DevOps the development and infrastructure practices

These kinds of rules help structure the day-to-day agile workflow, typically framed by a cadence of 2-week sprints, ensuring everything we do remains iterative and closely bound to the client’s business goals.

Other Pentalog rules such as project director and steering committee may be less familiar, but they are no less important. Especially for complex endeavors involving agile teams, these roles are critical so that we can foresee risks and plan accordingly.

Principle 3: Rules are additive and always follow the service

It is easy to see that not all projects are the same. That’s why rules always follow the service.

From a commercial standpoint, the complexity will be the highest in a managed team (where Pentalog assumes team and product leadership), less in staff augmentation (where Pentalog provides talent), less for consulting projects, and least of all for on-demand services.

This explains why rules are always additive: when a client chooses to add additional services, additional rules are implemented to expand the governance perimeter. Therefore, governance always follows the most robust rules implied by the activated services.

Each type of service comes with different ways of working – drawing on agile, scrum, kanban, lean, growth, design thinking, and other approaches – with Pentagility, we are continuously evolving and learning how to be better, faster and smarter as new ideas emerge.

Pentalog has also established rules based on our own experience (particularly around governance), enriching industry practices. These rules cover steering practices that have emerged from Pentalog’s decades of work delivering IT services, and in particular, through outsourcing, where remote connections with clients are the norm.

Within the collaboration framework, which can be understood as a set of predefined operational protocols, there is an essential foundation of rules that typically covers:

• Roles & Responsibilities
• Events & Artifacts
• Processes, guidance, procedures
• Flow
• Definition(s) of “Ready” and “Done”
• Security & data protection
• Project Steering expectations
• Learning, feedback loops, knowledge sharing across teams
• Guidelines, standards, norms and best practices
• Other items deemed necessary

Principle 4: Visibility of outcomes promotes self-reflection

The key to improvement is always focusing on what matters to the client. Then we find ways to improve so we can do more of that faster.

One client may have exceptional requirements related to security or data governance, for instance, or mandate a zero-bug policy. In these scenarios, the team should aspire to high states of excellence, or maturity, related to the rules governing these topics.

Another client may have a goal of velocity, with delivery of working product paramount to meet business expectations. Here the client will understand the need for a trade off with lower levels of product quality and methodological maturity.

Over the years, we have continuously sought to embrace new rules proposed by our clients, who have shown us how to adapt to their realities. At the same time, we likewise sought to innovate with new rules identified by our own teams as they solved new kinds of problems.

As we have grown more skilled customizing frameworks for clients our methodology has become more resilient. This gives us the chance to re-absorb learnings into our core.

Principle 5: Learning with clients makes governance agile

Regular inspection of performance is the bedrock of trust. Pentagility combines visibility over the rules defined in the Collaboration Framework with regular meetings among the stakeholders through the format of the Steering Committee Meeting.

These meetings represent a kind of global governance ceremony that should take place at regular intervals to review KPIs and other topics and plan accordingly. Meetings should be monthly (ideally) and structured using dashboards.

Typically, attendees of a steering committee include the key client business stakeholders, as well as Pentalog team members such as the project director, scrum master, people master or growth master, depending on the type of project.

Steering meetings typically cover the following topics:

• KPIs or OKRs (which may include deliveries, issues, technical debt, code coverage, cycle time, cumulative flow, team mood, team rotation, among others)
• Risks
• Roadmap
• Maturity model (excellence)
• Data Governance
• Budget (consumed/forecast)
• Shared Action Plan

Steering lets us evaluate if the rules should evolve, if standards of excellence should change if new rules need to be added or others removed. Steering gives the client the chance to understand the value we are delivering or hold us to account when we are not.

Steering documentation should be accessible to everyone. Whenever possible, we publish reports directly within project management systems such as Confluence.