Be & Do Agile !
Project management, software craftmanship, product management… We support your teams in their transition to agility. Let’s reflect on the framework and practices best suited to your activity and your teams and let’s become agile!
It’s not just yogi’s who are agile!
Improve your performance with agility.
Revitalise your teams with support in agile project management, software craftmanship and prod-uct management. Increase customer satisfaction with regular delivery and without compromising quality. Our experts can support you through your agile transition and improve your time-to-market and your capacity to adapt to changes.
Agile project management
Clients’ needs are constantly changing, so you need to understand new technologies quickly… You have to adapt and reinvent yourself to stay competitive. Being agile is crucial. But how do you be-come and stay agile? Why? Where to begin? Our agile project management expertise shows you the way.
Software Craftsmanship
Developing an agile software development team requires the implementation of an agile frame-work and adopting a new culture. But that’s not enough. As the final product is comprised of code, it is important to take an interest in the agility of the code itself and the practices that lead to it: the software craftsmanship.
Product Management
The primary objective of an agile approach is to regularly deliver value for users by building good products that respond to their needs at the right time. Project culture considers respect for scope, costs and deadlines as criteria for success. Product management focuses on user satisfaction, re-turn on investment (ROI) and time-to-market.
Are you passionate ? So are we !
Join us.
Our latest publications on agile project management
Why should you use a consultancy in agile project management?
What is agility?
Many definitions of agility exist but most are incomplete, as agility is a multi-dimensional concept and each dimension has its own significance.
For an overview of agility, it can be represented as a pyramid, viewed from top to bottom, given the overwhelming importance of the upper sections:
Agility is a state of mind. In other words, it is a culture shared by the entire organization that wants to be agile. The agile mindset puts the focus on users and their satisfaction and highlights the no-tion of team beyond the individuals who make it up. These teams have common goals, take collec-tive decisions and are autonomous in their tasks. In an agile culture mistakes are accepted, as teams constantly experiment and learn about their technical, functional and human environment. People’s attitude are positive because they are influenced by constructive reasoning. In this con-text, error is a means of learning and evolving in the right direction, and therefore something posi-tive. Learning constantly is part of the agile spirit. Finally, there is no agility without excellence and a continuous focus on quality.
In the field of software development, we address the aspect of technical excellence through “software craftsmanship” expertise.
The 4 values of the Agile Software Development Manifesto, a kind of founding text of the agile movement are:
“People and their interactions instead of processes and tools.”
“Operational software instead of exhaustive documentation.”
“Collaboration with the client instead of contractual negotiation.”
“Adapting to change instead of following a plan.”
These 4 values reinforce the agile mindset, indicating that agility puts the focus on humans, the value they produce, feedback, learning and the ability to adapt to any changes.
The 12 principles also described in the Agile Manifesto illustrate how the 4 values can be imple-mented.
A set of frameworks and methods (such as Scrum or Kanban) form part of the toolkit of our “Agile Project Management” expertise, which we use to implement agility in our clients’ businesses.
The use of visual management boards and user story mapping are among the practices used within the framework.
Agility is an incremental approach because it induces the construction of a product by accretion. It is also an iterative approach because we use what we have learned from previous iterations in order to adapt products and processes.
Unlike traditional approaches, agility is an empirical and not a predictive approach. Teams learn as they move forward.
Why you should adopt an agile approach?
To pitch the objectives of agility in one phrase, the approach enables regular provision of valuable services to users at the right time, adapting in time to changes in the environment. Moving towards agility must not be a goal in itself.
The primary reason to adopt an agile approach is to develop the ability to adapt to change and to learn. Why is it important to learn? How do we adapt to change? Most companies evolve in a changing context, which casts doubt over their evolution in the future. The market for a positioned product can evolve in time, but no one can predict this evolution for sure. Competitors can change. Clients needs can change over time. Another area in which uncertainty can arise at any moment is how to technically make a product, because technologies, tools, and ways of doing things also evolve. This uncertainty about what to produce and how to make it is complex, added to which is the complexity of the human organisation that makes the product. The primary purpose of agility is to have a better understanding of this complexity through experimentation and the learning pro-vided by feedback, be that at the product level, technical level or human level. Through regular feedback, we can minimise tunnel effects at all levels of the system: production, technical and hu-man organisation.
Equally important as adapting to change, is improving the time-to-market. That is, to deliver the right functionality at the right time to deliver the values the customer expects. In short, agility helps improve user satisfaction and always creates the product increment with the highest business val-ue right now.
The Agile Manifesto places people, human interactions and collaboration at the center, thereby restoring meaning to everyone’s work. Adopting an agile approach is useful for increasing the in-volvement of people, generating more accountability of individuals and teams, and increasing the overall efficiency of an organisation.
What issues does scaled agility address?
Scaled agility allows multiple agile teams to work together on the same questions pertaining to one or several products. An ideal agile team should correspond to the size of a team fed by two pizzas! However, the reality of the topics covered or the products built by some organisations often in-volves more people than the size of a “pizza team.” This brings us to the realm of agility at scale.
By definition, the aim of scaled agility is a set of teams that are all agile. The first issue that scaled agility faces is to build upon what’s important to an agile team – focusing on delivering value and on the autonomy of teams.
Scaled agility is absolutely not the ‘industrialisation’ of one team’s agility with greater granularity. That is, it does not simply replicate the way one team works in order to reduce complexity. At scale, complexity is always present and we need to work with it.
The second issue that scaled agility needs to resolve is synchronising team to deliver value. Scaled agility tools aim to focus on managing teams’ dependencies.
Finally, scaled agility has implications for the organisation. The concept of a feature team, that is a multidisciplinary team able to fulfill a function from end to end, is key in the implementation of scaled agility, in order that each team retains a maximum of autonomy. However, scaled agility does not prohibit the component team model, that is, a team with expertise working on a compo-nent of the value chain. It depends on the context. However, a component team model tends to be an exception in an agile organisation at scale.
Another implication of scaled agility across an organisation is the establishment of cross-functional communities of practice in feature teams. For example, if multiple teams are working on a single product, they share the same code base. It is essential for teams to agree on how the code is writ-ten and its architecture. Sychronisation!