Skip to content

Leaving my job as president. Launching a startup.

[Pour la version française]

Image by Better Than Bacon

Some say it takes courage. Some call it audacity. Others believe it is totally insane to leave a high-paying and high-profile job to launch a start-up.

I think that this type of career move is simply pursuing a dream, following a personal calling, and living life to the fullest.

There is the risk you cannot afford to take and there is the risk you cannot afford not to take. – Peter Drucker

Leaving my job as president

Last week, I announced my resignation as president of Pyxis Technologies to pursue a personal project, as of June 15th. I briefly talked about my personal project in a recent post and today, I can share a little more information on what exactly I will be doing starting this summer – but before I do so, some explanations.

The decision to leave Pyxis was a difficult choice. I now consider that the organization I took over as president 2 years ago is now well positioned to continue its development and growth. Profitability has significantly increased and revenues are up with the organization now focusing on its core activities: Agile coaching and ScrumMaster services, training, and software development. The timing to pass the torch to a new leader now seems right. As François Beauregard wrote on the Pyxis web site:

For his leadership and courage to always take the actions he believes are right, Martin had significant impact on Pyxis in a time of great change. Martin is more than a colleague, he’s a friend and I know we are close-minded and that we share the passion for developing people and organizations […] I sincerely wish him success in his future career plans because I am convinced that we will collaborate again in the future.

Launching a start-up

I will be starting a new management consulting and leadership coaching firm, with my colleague Yves. It’s a while I’ve contemplated the idea and I believe, now is the right time to jump.

Yves and I consider that managers are facing increasing complexity within their organization. In order to implement solutions that really work and that are sustainable, managers must have a systemic perspective of the environment in which they work. In addition, organizations are increasingly demanding more from their leaders and the leaders are not always adequately prepared to meet such demands. The firm we’ll be launching (more details soon) will support these managers to improve their organizational results by capitalizing on the professional and personal development of their people. More on the next project in upcoming posts…

——————–

Version française

Quitter mon poste de président. Démarrer une startup.

Certains disent qu’il faut du courage. Certains appellent cela de l’audace. D’autres croient qu’il est totalement insensé de quitter un emploi bien rémunéré et à haute visibilité pour lancer une “startup”.

Je pense que ce type de changement de carrière est tout simplement la poursuite d’un rêve, suivre sa voie personnelle et de vivre la vie au maximum.

Il y a le risque que vous ne pouvez pas vous permettre de prendre et il y a le risque que vous ne pouvez pas vous permettre de ne pas prendre. – Peter Drucker

Démission à titre de président

La semaine dernière, j’ai annoncé ma démission en tant que président de Pyxis Technologies, en date du 15 juin, afin de poursuivre un projet personnel. J’ai brièvement parlé de mon projet personnel dans un récent billet et aujourd’hui, je peux partager un peu plus d’information à propos de ce que je vais faire dès cet été – mais avant de le faire, je vous partage quelques explications.

La décision de quitter Pyxis a été un choix difficile. Je considère que l’organisation pour laquelle j’ai pris la présidence il y a 2 ans est maintenant bien positionnée pour poursuivre son développement et sa croissance. La rentabilité de l’entreprise a augmenté de façon significative, les revenus sont en hausse et l’organisation se concentre désormais sur ses activités principales: services d’accompagnement Agile et services de ScrumMaster, formation et le développement de solutions logiciels. Le moment de passer le flambeau à un nouveau leader me semble maintenant approprié. Comme François Beauregard a écrit sur le site web de Pyxis:

Martin est plus qu’un collègue, c’est un ami et je sais que nous sommes animés d’intentions proches et que nous partageons les passions pour le développement des humains et des organisations. Je lui souhaite du succès dans ses prochains projets professionnels et je suis convaincu que de nouvelles collaborations nous attendent.

Lancement d’une start-up

Je vais donc démarrer une nouvelle entreprise de conseils en gestion et de coaching en leadership, avec mon collègue Yves. Ça fait un bon moment que l’idée me trotte en tête et je crois que maintenant est le bon moment pour sauter dans cette nouvelle aventure.

Yves et moi considérons que les gestionnaires sont confrontés à un niveau de complexité croissant au sein de leur organisation. Afin de mettre en œuvre des solutions qui fonctionnent vraiment et qui sont durables, les gestionnaires doivent avoir une perspective systémique de l’environnement dans lequel ils travaillent. En outre, les organisations sont de plus en plus exigeantes de leurs dirigeants et les dirigeants ne sont pas toujours bien préparés pour répondre à ces exigences. L’entreprise que nous allons lancer (plus de détails bientôt) souhaite supporter ces gestionnaires afin d’améliorer leurs résultats organisationnels en capitalisant sur le développement professionnel et personnel de leur employés. Plus d’informations sur le prochain projet à venir …

Analytical-Mind has moved

Image by Curtis CronnMy most recent content can now be found on my new blog.

After writing almost 300 posts since October 2008, I have decided to stop publishing content on this blog. My new blog is geared toward forward-thinking leaders who wish to explore innovative practices. If (like many of us) you believe the traditional management technics and leadership approaches are no longer adapted to the current knowledge economy, you should find my new blog interesting.

Ciao,

martin

Adapting your leadership style to the maturity level of your self-organizing team

Unless they are adopting Agile for the wrong reasons, people managers find themselves facing an interesting decision – “Am I willing to let go some control in order to take advantage of the benefits associated with Agile?”.

Being human, it is difficult not to resist change unless we know what to expect from the future and clearly understand the implications for us. Once the future becomes clearer, we can start to appreciate the need to change. That’s just the beginning… Change for what?

In his book, Jurgen Appelo presents various levels of decision making and manager involvement in the context of Agile adoption. I took the liberty to build a matrix (see below) to match Jurgen’s various leadership styles to the 7 stances of a self-organized team [a pdf version of this matrix is available for download].

(1) Taken from: Agile self-organized teams – is the team self-organized or not?

(2) Taken from: Management 3.0: Leading Agile Developers, Developing Agile Leaders

The matrix presents which leadership style the manager should be using based on the level of maturity of your team. Hope you will find it useful!

Agile managers do not act like cowboys

Image by anyjazz65

Managers are expected to get their teams to deliver on the objectives that are established. Managers are also expected to keep their people happy and motivated. How can one accomplish these two seemingly incompatible expectations?

Let’s first distinguish management from leadership.

Management books often make a distinction between managers and leaders, depicting leadership as if it is more about heroics than management. […] Managers are then advised to transform themselves to leaders, turning employees into willing followers, instead of herding them like sheep. […] Separating leadership from management is like comparing women to humans. It doesn’t make sense. […] Comparing women to men seems more logical to me. – Management 3.0: Leading Agile Developers, Developing Agile Leaders

I agree with Jurgen that leadership is one of the ways to accomplish a manager’s role.

Along the same lines, I hear from time to time conversations within Agile circles and read Agile related blog posts promoting soft leadership, leading without authority and laissez-faire [The latter is sometime mistakenly perceived to be self-organization. Self-organization is something else and requires clear boundaries, but that’s for another post] as the answer to the management conundrum. Is that really the silver-bullet?

In almost all organizations, the manager’s role is fairly similar.

Management in all business and organizational activities is the act of getting people together to accomplish desired goals and objectives using available resources efficiently and effectively. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. […] Since organizations can be viewed as systems, management can also be defined as human action, including design, to facilitate the production of useful outcomes from a system. This view opens the opportunity to ‘manage’ oneself, a pre-requisite to attempting to manage others. – wikipedia

For a large number of individuals in management responsibility, authority is perceived to be the most effective tool to ensure compliance and to get people to do with is expected. Please bear with me, the analogy isn’t perfect but the image is powerful. For me, authority is similar to carrying a gun [or whatever your preferred weapon happens to be].

It is easy to obtain compliance and get people to do what we tell them to do when we – the managers – are the only people carrying a weapon. It is especially true if the weapon is constantly out of the holster and pointing directly at the team [figuratively speaking, of course]. So authority gets us compliance (for most part) and may allow us to meet our objectives (some of the time) but authority doesn’t bring the best out of people. Authority certainly doesn’t make people happy and motivated.

On the other hand, if we aim to keep people happy and motivated first, we are more likely to adopt a laissez-faire approach.

Lewin often characterized organizational management styles and cultures in terms of leadership climates defined by (1) authoritarian, (2) democratic and (3) laissez-faire work environments. Authoritarian environments are characterized where the leader determines policy with techniques and steps for work tasks dictated by the leader in the division of labor. The leader is not necessarily hostile but is aloof from participation in work and commonly offers personal praise and criticism for the work done. Democratic climates are characterized where policy is determined through collective processes with decisions assisted by the leader. Before accomplishing tasks, perspectives are gained from group discussion and technical advice from a leader. Members are given choices and collectively decide the division of labor. Praise and criticism in such an environment are objective, fact minded and given by a group member without necessarily having participated extensively in the actual work. Laissez-faire Environments give freedom to the group for policy determination without any participation from the leader. The leader remains uninvolved in work decisions unless asked, does not participate in the division of labor, and very infrequently gives praise. – wikipedia

When nobody carries a weapon, such as in the case of laissez-faire leadership style, people are freer to select goals that appeal to them and are more likely to be successful at reaching their objectives. Unfortunately, managing people (as in the wikipedia definition “getting people together to accomplish desired goals and objectives”) becomes extremely difficult and maybe impossible in a business context (trust me, we have tried that unsuccessfully).

To be an agile manager doesn’t mean to avoid using authority and to strictly rely on our influencing capabilities. It doesn’t mean to let people determine the business orientation that the organization will be taking either. As in many fruitless debates, taking an “either or” perspective doesn’t lead to the best answer. Agile managers need to be able to use authority, but not as their primary tool.

Let me explain.

Agile managers need to take the time to explain the objectives they aim to achieve and get people to follow them (leadership) into attempting to reach the objectives. Just like good diplomats, agile managers should begin with good listening skills, influence, and negotiation when they are faced with people resistance and challenges. Only in extreme cases should we turn to authority to get people to do what we need them to do. Like many things in life, using authority comes at a cost (diminished commitment from the team, reduced motivation) and as such, should be used wisely.

This leads me to my last point. In addition to management skills, people’s tolerance to stress needs to determine if they should be entitled to manage a team. As most psychometric tests can tell, we – humans – tend to operate differently when we are within our comfort zone (low stress) or outside our comfort zone (high stress). While in our comfort zone, we usually take advantage of many of our built-in or acquired skills which doesn’t increase one’s anxiety level. By contrast, stepping too much outside our comfort zone leads to decreased performance and substantially increased anxiety levels. People for who management is within their comfort zone or people who have better abilities to deal with stress are less likely to use authority as their primary tool. As such, agile managers are more likely to wait until the situation is critical before they even think of going “Clint Eastwood” on people.

So next time you are thinking of promoting someone in a management position, do not simply look for their skills. Assess their ability to manage their stress level.

12 tips to be a better coach

image by BernzillaI often hear people saying they are coaching others in an agile context. Coaching is often incorrectly used to mean: consulting, teaching, mentoring and a few other unexpected meanings.

Coaching is very useful to help people get from “point A to point B” and it can be used in various contexts, including coaching for Agile adoption or to help people managers modify their leadership style. Either way, to be powerful, coaching requires a few basic skills and a question from my friend Yves prompted me to describe 12 fundamental elements that I believe are required to be an effective coach. You are more than welcome to share your thoughts.

  1. Inner silence: To be truly effective at listening to what others are saying and how they are feeling, it is critical to block the voice inside your head – yes that’s right, that voice that rambles all the time saying things such as: I wonder what we’ll eat for dinner tonight?… Damn, I forgot to make reservation for dinner… I hope the kids did well on their math test today… I’m bored… I think I want a coffee right now. I heard the term monkey brain to describe this constant action of jumping around from one thought to the next. To be an effective coach, you will need your monkey brain to calm down so you can find inner peace.
  2. Stop all judgment: When you coach people, it is easy and unproductive to become judgmental. Comments such as: Wow, that’s a weird comment… I wonder why he’s saying this… There must be some secret meaning to that sentence… I don’t think I’l be able to help her on this topic… I feel insecure… This won’t help be effective at all. Simply listen to what is being said for what it is being said. Judgments will sidetrack your listening abilities and will make you a very poor coach.
  3. Stay focused: Now that you stopped all judgements and are able to keep the inner voice quiet, you need to remain focused for more than 6 seconds. Yes, just like meditation, this sounds like an impossible task at first but with practice, you will develop your focusing-muscle and the task will get easier with time allowing you to be more present to what the other person is expressing.
  4. Be present: Be in the moment – right there and then. Listen to what is being said, notice how the person is acting and give her your full attention and make the space secure for the conversation.
  5. Don’t aim for personal performance: Aiming for an academy award when you are coaching simply doesn’t work. You are not there to impress anyone. Ironically, the more you will try to impress the other person, the less effective you will be. She will will quickly notice that the focus is on you and not her which will make it pretty much impossible to actually support her development.
  6. Ask open ended questions and wait for the answers: Remember, you are not telling a story, you are there to listen. If you need clarification or want to encourage discussion, simply ask a short question. Trust yourself that the other person will understand your questions and if they don’t, they will quickly let you know. Once you have asked your question, wait for the answer.
  7. Trust your intuition: If you feel that you need to ask a certain question, then go ahead and ask it. If you believe it is better to wait, then wait. I believe what we call intuition is simply our brain and senses’ abilities to decipher subtle messages from the other person and give us clues as how to interact with them.
  8. Keep silent: After asking a question, never speak first. Maintain the silence until the other person breaks it. I am a very strong believer in keeping silent. Silence opens up a secure space for conversations and gives all the space to the other person.
  9. Pay attention to the non-verbal: Words are a great way to communicate but non-verbal clues are usually very useful to understand where the person stands – Are they at a rational level? Intuition level? Emotional level? This information will be very useful to adapt your coaching style.
  10. Dig deep: It is much easier to stay at the rational level in a discussion. It often leads to contextual information and detailed explanations. To make a real difference, you need to get to the underlying emotions – What are the person’s fears? Intentions? Motivations? Ask feeling-related questions, not logical or rational questions such as: “How do you feel about this event?” instead of “What do you think about this?”.
  11. Rephrasing: When rephrasing, use the same key words as the other person. The words are usually very meaningful to the other person and will open up relevant information for you.
  12. No context: Do not focus too much on the context. It is usually good to understand what triggered the actions or where the event took place, but the information usually has very little impact on the person you are coaching.

Are there other tips you would like to share?

Gartner’s Enterprise-Class Agile Development Defined

image provided by africa (http://www.freedigitalphotos.net/images/Family_g212-Family_p29227.html)Gartner’s analysts David Norton and Mike Blechar recently published “Enterprise-Class Agile Development Defined“. Although the content is very light and the findings not revolutionary, the research presents a high level differentiation between enterprise wide Agile adoption and enterprise class Agile adoption.

Enterprise wide Agile adoption

Our definition of EAD differentiates enterprise-class from enterprise-wide. Across the organization (enterprise-wide), organizations might be doing many self-contained/independent agile development projects that are totally unrelated and that meet specific tactical needs. Or, the projects may be first iterations of agile development projects intended to help organizations gain understanding and insight into how the application solution could subsequently be grown into a more complete solution, which will subsequently be integrated into the current application solution portfolio. Most of the agile development projects we see start out without real concern for the longer-term impact on the application ecosystem and broader solution architecture. They generally fail to scale to the needed enterprise-class solution characteristics we identify in this research, even though the project may consist of hundreds of developers and be classified as enterprise-wide.

Enterprise class Agile adoption

Enterprise-class AD includes assessing the impact on the current and future enterprise solution architecture for the organization to make the right business decisions.

One of the key finding presented by the authors is that:

Agile development methods are increasingly being used within organizations as business differentiators, which is raising their profile from tactical project level to a more strategic enterprise level.

And as such, one of their recommendation is that:

Enterprise-class agile development cannot be driven only by the CIO and application development (AD) teams. Strong business commitment is essential. Don’t attempt to drive enterprise agile from an IT perspective, as it will fail.

In their research, the authors have identified seven key elements that collectively, positively impact enterprise wide software development processes. Taken together, these key elements help organizations achieve an enterprise class Agile adoption.

  • Customer-Centric: Exceeds the notion of the business project sponsor to include the corporate strategies and organizational goals. The product owner and team members need to fully understand and be aware of the impact of the solution and its architecture on the overall corporate goals.
  • Collaborative and Cooperative: This is not just cooperation between IT and the business, but also within IT departments across the various sections of the organizations, including teams that are not co located.
  • Constant Feedback:  Though lengthy planning is often eliminated from Agile projects, due to organizational constraints it should not (and possibly cannot) be completely removed. This doesn’t mean to overly invest time and efforts but “just good enough” planning should allow projects to get started. As such, constant feedback isn’t limited to the communication between the IT and Business units but similarly with all support departments and various stakeholders.
  • Heterogeneous Environment: There is no magic formula for success, and adaptation is required for a successful adoption.
  • Throughout the Software Life Cycle: Agile practices, such as refactoring, applied throughout the life cycle, can extend the useful life of the application.
  • Continuous Delivery: Speaks to the need of continuous collaboration between IT and the Business units in the development of a product.
  • Adaptive Solutions: Discusses a compromise between a complete top-down architecture and an emerging architecture.

Tribal Leadership – What level of leadership are you at?

There are many perspectives about what leadership is and how it should be done. Contrary to many recipe books on this topic, Tribal Leadership is a useful tool to assess the stage of your personal leadership style and evaluate the impact and the consequences of each stage. Although the backdrop of the book is that a higher leadership stage is better, the real value for me was as a tool to understand the culture and more importantly the people we deal with as part of Agile transitions.

While the majority of leaders in the work place are at stages 2 and 3, Tribal Leadership shares tools and insights to help individuals and organizations break through to the next evolutionary stages – which are usually much easier for a transition.

To help you get a gist of where you may stand as a leader and possibly help you determine at what level people you work with are, the authors provided on their web site a quick map (below).

As Agile coaches, we must often work with teams and their leaders. Understanding the behaviours of the leaders and their motivation is extremely useful. As such, the book presents a model allowing the transformation of Level 1 leaders to higher levels – granted most people start at level 2 or 3.

The book provides rich insights into human behaviour, group dynamics and individual motivation. Overall, it provides a good framework to understand people’s behaviors and with some clear thinking, can lead into actionable strategies to help support an agile transition.

Tribal Leadership is available in audio book [285 Mb zipped file] and in a traditional book format (Tribal Leadership: Leveraging Natural Groups to Build a Thriving Organization).

See Dave Logan’s presentation at TED.

http://video.ted.com/assets/player/swf/EmbedPlayer.swf

Cracking the Code for Standout Performance (part II)

image by shadaringtonAs Agile team coaches or organizational coaches, we aim to increase the teams’ performance in an attempt to deliver better results. We improve quality, help the team work more efficiently, and have fun while delivering increased business value. Interestingly, many of the observations presented in Great Business Teams: Cracking the Code for Standout Performance (this is the second part of the book review) are in line with the Agile values and principles. Here are some of the keys points to remember:

THE LEADERS

The leaders have an important role in developing high performance teams. Their actions and behaviors will be closely observed and people will modify their own behaviors based on those of their leaders. Guttman highlights some of the leader imperatives to achieve high performance.

Develop and drive the horizontal vision

An horizontal organization means moving to an organizaton in which everyone operates according to a clearly defined set of decision-making protocols, where people understand what they are accountable for and then own the results.

For an organization to raise its level of performance every team, on every level, must be a great team. That is to say, it must be aligned in five key areas:

  1. business strategy
  2. business deliverables coming from the strategy
  3. roles and responsibilities at individual and business unit or functional levels
  4. protocols, or ground rules, for decision making and conflict resolution (see a recent post on this topic)
  5. business/interpersonal relationships and interdependencies

Create the right mindset

  • Being candid from “wary, closed with hidden agendas” to “candid, open, relaxed, easy to speak your mind” – from “no tolerance for confrontation, conflicts suppressed” to “tensions surfaced, confronted, and resolved”
  • Accentuating accountability: putting equal emphasis on cross functional, peer-to-peer accountability, as well as peer-to-leader acountability.

Provide the right skills

Such as influencing, active listening, assertion, giving and receiving feedback, conflict management, decision making and leadership.

Keep the game and guard the rules

Everyone is clear about and committed to the business strategy and the operational goals that flow from it; undertsands his or her roles and responsibilities, and adheres to agreed-upon protocols, or ground rules for decisions making and for interpersonal behavior, especially those relating to conflict management.

Here’s how great teams make decisions:

  • Identify the decisions that need to be made
  • Identify decision subteams
  • Assign accountability
  • Set objectives and timelines
  • Select the decision making mode
  • Identify information sources
  • Determine the shelf life of the decision

Raise the bar

Keep challenging the status quo, revisit the targets and get the team involved in the process.

Be player centered

Leadership is in large part about power – about how it is exercised, shared, delegated, and used. High performance leaders seek to leverage power, not monopolize – to put it to use to drive up their team’s or organization’s performance. Putting the power in the hands of the teams members provides the right conditions to deliver maximum payoffs.

THE PLAYERS

The road to a great team begins with two nuclear elements of team reality: the leader and the team members. Consequently, team members must show four very obvious characteristics.

Think like a director

Keep their eye on overarching goals and the need to stay on top of their competition.

Put team first, function second

They are team members first and functional representatives second.

Embrace accountability

Slowly move from an individual accountability for their own results toward accountability toward the success of the entire organization.

Become comfortable with discomfort

People need to be or become comfortable with the changes required of them and their leader.

Building an outstanding team requires time and energy and is achievable once people agree to work together and pull in the same direction.

Expected behaviors of a self-organized team

Picture by Creative DonkeyFollowing a recent post on the topic of self-organization, I’m offering a few examples of how people react / should react when a team is self-organized.

 

Not self-organized Self-organized
  • Waits to be told what to do
  • Figures out what needs to be done
  • Is a victim of circumstances
  • Is responsible for his actions
  • Gossips about the motives
  • Seeks information to understand
  • Whines about the constraints
  • Attempts to operate within the constraints
  • Complains about his colleagues’ performance
  • Holds his colleagues accountable
  • Waits for rules to be defined
  • Defines the rules of operations
  • Reactive
  • Proactive

What other behaviours have you noticed?

The PATH: a model to facilitate the diagnosis of the Agile maturity level

Pyxis created the PATH model to facilitate the diagnosis of the Agile maturity level within a team in order to recommend the appropriate intervention. PATH is:

  • An intervention approach within the organization;
  • A model allowing to lessen the impact of an Agile transition.

PATH is an acronym for Process-Added value-Technologies-Human, the 4 dimensions of software development.

Processes: Efficiently deliver value with a simple process adapted to the project’s needs (lowest cost within time).

Added value: Deliver functionalities and maximize their business value (prioritization and flexibility).

Technologies: Deliver quickly and consistently with appropriate engineering practices (sustainable pace and skills development).

Human: Deliver at a sustainable pace and in harmony while promoting team work (collaboration and communication).

In addition to the dimensions, the PATH model introduces 3 influence levels—vision, funnelling and emergence—that, when applied to all 4 dimensions, produces 12 intervention areas.

Vision

The ‘Vision’ level shows the orientation to meet established objectives. This level is generally linked to the strategic vision of the organization. The vision represents the objectives to achieve.

For instance:

Maximization of return on investment:

  • Connection between the IT group and business units, and globally between all stakeholders
  • Development of inter-project synergies in order to adopt best practices and pool them
  • Management of simple and adaptable projects in order to reduce administration fees
  • Capacity to innovate in order to be equipped with the tools required for the organization to evolve
  • Capacity to anticipate in order to gain a competitive edge
  • Greater respect for budget allowance

Maximization of a cooperation and collaboration culture:

  • Better team organization
  • Evolution of the strategy and change culture
  • Adaptation of the leadership model

Performance:

  • Quick project execution compared to traditional approaches
  • Quality improvement of software delivered
  • Establishment of parameters allowing to measure performance
  • Adaption of the competency model and expertise development
  • Process implementation to select initiatives

Funnelling

The main objective of the ‘Funnelling’ level is to implement mechanisms promoting collaboration (e.g. communities of practice, wikis, and blogs).

This level:

  • Allows to implement a communication approach in order to make the vision visible
  • Allows to make sure the field practices (emergence) are aligned with the objectives established at the ‘Vision’ level

Therefore, funnelling allows the emergence of the best practices arising from development teams as well as the dissemination of these practices to all groups that may benefit from them. Therefore, the ‘Funnelling’ level acts as an information catalyst and aggregate.

Globally, the objective of this level is to ensure reuse of:

  • Tools
  • Practices
  • Experience acquired by stakeholders

Emergence

The ‘Emergence’ level is the level for project teams developing software solutions. It is important to implement new development processes and train team members on how to apply Agile principles.

At this level, transformations imply:

  • New ways of doing
  • A behaviour oriented towards collaboration in order to achieve established objectives
  • The implementation of methods allowing to obtain best results
Follow

Get every new post delivered to your Inbox.