Skip to content

Posts from the ‘agile’ Category

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.

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.

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

Agile teams – What people managers can learn from parents

image by candrewsBefore I explain what people managers can learn from parents, I feel the need to defuse what some readers may have in mind. I am not suggesting that employees and team members are children or act like babies [although, sometimes ... - sorry, I'm digressing].

The Art of Parenting

If you have children, you should quickly relate to the fact that nothing really prepares us to be good parents. Sure, while growing up we assimilate patterns, behaviours, and skills from our environment – including and often to a large extent from our own parents. At a later stage in our children-free life, some of our friends start to have kids and we observe them – sometimes with curiosity, sometimes out of sheer voyeurism, and sometimes with envy – and that’s when we contemplate the idea of having kids of our own.

Then, one day out of the blue, the kind doctor tells your spouse that she is pregnant – in our case with twins! But that’s an entirely different story ;)

Then comes the next stage of learning to become a parent, we spent countless hours on amazon.com previewing and ordering books, lot’s of books. Except for a few best sellers, the others titles vary based on our perceived areas of weakness and the bad pattern we noticed from our parents when they raised us.

And one day, a beautiful baby boy is born and/or a pretty baby girl – once again, in our case we got one of each.

Once the sleepless nights are over and the baby is capable of learning, parents slowly transfer increasingly complex tasks to their child: holding the milk-bottle, feeding themselves, walking without holding mommy’s hand, abandoning the diaper, selecting how much ketchup to put on their food, picking their own clothes, walking to school by themselves, deciding what time to go to bed, going to a movie without supervision, and so on up to the point when the child moves out of the house to start their own independent life.

What people managers can learn from parents

It is obvious that parenting is very different from managing people, no doubt about that. On the other hand, their are some similarities.

Nothing prepares people to become good managers. Sure, while growing up in our professional career we assimilate patterns, behaviours, and skills from our environment – including and often to a large extent from our own managers. Granted, some people had the opportunity to learn about management during their school years and that could be an added bonus.

As with parenting, once we decide to get into management we spend countless hours on amazon.com previewing and ordering books, lot’s of books. Except for a few best sellers, the others titles vary based on our perceived areas of weakness and the bad pattern we noticed from our previous managers.

How that applies to Agile teams

Agile management is somewhat similar to the art of parenting with the manager transferring to its team increasingly complex tasks and responsibilities. Helping the team self-organize doesn’t mean to abandon the team to itself without help or some supervision. Along the same lines as parenting, there comes a time when the manager must determine how much responsibility to transfer and what level of support to provide.

Similar to the role of the parent, the agile manager is there to support the team’s development and make it successful and autonomous until one day – maybe – the team is highly performing and can become independent.

The myths of self-organized teams

Image by Lauren_MillerMany Agile practitioners will push forward the concept of self-organized teams as a first step towards an Agile transition. Unfortunately, self-organization is often mis-understood and many become frustrated with the concept. Below are myths taken from real life situations – including the inner workings of our organization.

  • Self-organized teams can only work with experienced people. Although more experienced individuals may make it easier to self-organize, they can also make it much more difficult due to their old work habits. Overall, the age of the team members or their actual experience doesn’t impact their ability to self-organize. Self-organization has more to do with the people’s willingness to self-organize and the support they get from their manager than it has with age or experience.
  • Self-organized teams don’t need a leader. Wrong, self-organized teams still need a leader to move them through the various stages and toward their end goal. This being said, it doesn’t mean that the leader has to be a manager or a person in authority. Quite the contrary. Emerging leadership is a much better way to achieve self-organization but management needs to be patient because self-organization takes time.
  • Self-organized teams don’t need managers. Why not? Managers are a key success factor to support self-organization. Once again, this doesn’t mean that the manager is included in the self-organized team or that the manager will be leading the team. As Jurgen puts it – “Agile managers work the system around the team, not the people in the team”.
  • Self-organized teams are for everyone. Not necessarily, some people may not be ready for self organization or they may not be willing. Everybody has the capacity to be part of a self-organized team, it is simply a matter of wanting to be part of such a team because it is demanding and requires people to become responsible and accountable.
  • Self-organized teams are easy to implement. Really? If it was easy, why wouldn’t everyone adopt self-organization? The fact is that starting at a young age, we keep being told what to do (brush your teeth, go to bed, pick up your clothes, do your homework, show up at the office at 9am, finish the report for your boss, go on vacation in July, retire at 65, etc.) Wanting to be self-organized and taking control of your life is counter-intuitive and difficult. People in self-organized teams often act as victims of circumstances during the early stages (I can’t do this because the system won’t allow me) and then start to notice the opportunity the freedom of choice brings.
  • Self-organized teams quickly increase the team’s performance. No, it won’t. The team’s performance will indeed increase and for the long run but self-organization requires time, energy and much efforts to deliver results. If you are interested in quick-wins with minimal investments (time and/or money), I would suggest the Agile magic pill.

Autonomy or self-organization is a strong contributing factor for motivation and motivated individuals lead to improved performance and better results. Attempting to implement self-organized teams without understanding the risks and the energy required isn’t a good idea.

Don’t tell me you really want to increase your team’s performance – I won’t believe you

Image by Trucker TomI bet you $50 that even if I told you the way to boost your team’s performance without increasing your costs – you wouldn’t do it. The situation is actually worst than that! I’ll add another $50 that I even know what you will tell me once I tell you. You will say “We can’t do that in our organization“.

Ready to find out?

Stop assigning people to projects and let them pick the project they wish to work on – that’s it!

I can hear you – “We can’t do that in our organization” – there, I just saved $100.

Seriously, it is that simple. Think back to a project you worked on – were you assigned or did you select it yourself? Now do this exercise. Think back to something you enjoy, I mean you truly enjoy – were you assigned or did you pick it yourself?

Have you ever heard of Tom Sawyer withewashing the fence? As Mark Twain once said, “Work is something you are forced to do while leisure is something you choose to do”.

I don’t mean to pretend that work is a hobby but many organizations ignore people’s intrinsic motivation and personal drive when they (i.e. the managers) assign people to projects. No matter what the project is about, there will always be people interested in working on such a project. Ever heard of Crowdsourcing?

In most organizations, it may not be easy to let people select their own project, but it is feasible. Some organizational constraints may need to be modified, project assignment may need to be done differently, some resource planning may be required but all of this is feasible.

As one of the participant highlighted “I used to be bored to death in my normal job until one day, I asked (begged) to be part of a specific project. I’m so glad they granted my wish. I now work 55 hours a week! I am super motivated and nothing is going to make me want to leave that project”. Still think letting people select their project is a bad idea? – Analytical-Mind.

Go ahead, give it a try and see the results for yourself. I have tried this approach on many occasions and the results always impress me.

The strength of a real team is under-estimated

Image by Dawn (Willis) ManserProject kick-offs have been used for years as a way to launch a new project. It is assumed that bringing people together in a room where the project sponsor presents the project’s objectives and time-lines is a good way to get things going. To be sure that the newly formed team will perform well, some organizations even order sandwiches or sushi and add diet software drinks or beer, and so the project begins.

I really don’t have a strong opinion about project kick-offs but I do see a great opportunity to start building a real-high-performing-team from day one is often missed.

Having been part of great (and not so great) teams over the years, I’m obsessed about creating real teams – the ones we remember forever because we delivered outstanding results while being highly energized, and had a great time doing it. It is similar to the concept of Flow proposed by Mihály Csíkszentmihályi.

Flow is the mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity. [...]

According to Csíkszentmihályi, flow is completely focused motivation. It is a single-minded immersion and represents perhaps the ultimate in harnessing the emotions in the service of performing and learning. In flow, the emotions are not just contained and channeled, but positive, energized, and aligned with the task at hand. To be caught in the ennui of depression or the agitation of anxiety is to be barred from flow. The hallmark of flow is a feeling of spontaneous joy, even rapture, while performing a task[2] although flow is also described (below) as a deep focus on nothing but the activity – not even oneself or one’s emotions.

Colloquial terms for this or similar mental states include: to be on the ball, in the moment, present, in the zone, wired in, in the groove, or keeping your head in the game. Wikipedia.

So back to creating a real strong project team (The Wisdom of Teams: Creating the High-Performance Organization). Why not start with something simple, real simple? Establishing rules and protocols of operation for the team.

As a first step in launching a new team, I usually start with an initial meeting (the duration varies based on the size of the team and the project being undertaken) during which I ask the team members to establish their working protocol – how they wish to work together.

Here are some of the questions the team members need to answer prior to doing anything else – including actually starting the project:

  • What do we wish to accomplish together?
  • What ground rules will we play by?
  • How do we make decisions?
  • How long can discussions and debates go on for? Do we use time-boxes in meetings? For decision making?
  • How do we resolve disagreements?
  • How often do we need to meet? For how long?
  • How will we communicate with each other?
  • How do we keep track of our action items?
  • How do we deal with team members who do not live up to the team’s expectations?
  • What rules do we have to include new team members? To expel existing team members?
  • How will we know if we are successful as a team?

Some of these questions may appear to be trivial. While establishing a team protocol doesn’t need to take a lot of time (and can easily be combined with a team building activity), not establishing such a protocol will quickly lead to inefficiencies, waste of time, and increased frustration for the team members. Want a few examples?

  • Did you ever find out that some project team members’ personal objectives had nothing to do with the project? Trying to motivate those people will drain your energy and your focus.
  • Has a detailed technical decision ever been taken by a senior manager with weird consequences? Guidelines may have prevented the decision from being escalated in the first place.
  • Have you participated in meetings where key people didn’t show up or showed up late with the consequence of having some decisions over-ruled? Determining up front the rules around meeting attendance and decision making will greatly alleviate such frustrations.

These are only a handful of examples but time and again, I have had the privilege to launch teams on the right foot. The consequences are positive and the cost is minimal. It may not be as cheap as buying sandwiches for the team during the project kick-off but the investment will last much longer.

From team self-organization to enterprise self-organization

I had the opportunity to facilitate a discussion table at the “Déjeuner-Causerie” in Montreal (last week) and in Quebec City (this week) where over 50 people gathered in each city to share their experience with Agile adoption.

From team self-organization to enterprise self-organization

Before I get into the main topic covered during the 3 hour breakfast, the participants shared with the group their topics of interest. Though the participants were at various stages of their Agile transformation and had different experiences with Agile, they shared common interests and as such asked interesting questions:

  • What is self-organization and what does it really mean?
  • Can self-organization really work?
  • How far can you push self-organization?
  • How do you get management on board?
  • Can this work in any culture?
  • How can people be motivated to work together?
  • We are only starting with Agile, what do you recommend I read?
  • and many more!

This post is a quick summary of the various conversations. Since most of these topics require further explanation, I will expand on some of them in upcoming posts (and conferences). For now, I wanted to share some of the discussions.

What is self-organization and what does it really mean?

Self-organization is one of the basic pillars of Scrum and is often misunderstood. People (and in particular managers) assume that letting a team self-organize is the equivalent of complete chaos. To avoid getting into such a situation, self-organization requires some constraints.

Self-organization is the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning. This globally coherent pattern appears from the local interaction of the elements that make up the system, thus the organization is achieved in a way that is parallel (all the elements act at the same time) and distributed (no element is a coordinator). – Wikipedia

In his book, Jurgen Appelo wrote,

No self-organizing system exists without context. And the context constrains and directs the organization of the system. – Management 3.0: Leading Agile Developers, Developing Agile Leaders

As I already mentioned, Pyxis is an experimental laboratory and as such we have attempted to let people self-organize without (or with very minimal) constraints. In an upcoming post I can share some of the conclusions of that experiment but for the sake of this post, I’ll leave it as a “failed experiment”.

So back to constraints. In our context, the constraints are as follows:

Though we apply it at an organizational level, the concept of constraints can be applied at an Agile project team level where the Vision is the equivalent of the Agile project charter, the Finance is the equivalent of the project budget, the Strategies can be replaced with the project’s objectives or outcomes, while the Culture remains.

Can self-organization really work?

Yes, it can but it isn’t easy. Self-organized teams tend to go through various stages and success isn’t immediately achieved. Unless an organization is willing to invest into building a successful team, self-organization won’t really work.

How far can you push self-organization?

That’s really up to each organization. For instance, we have successfully pushed the concept as far as letting employees determine their own salary. Sounds crazy? Sure does, but that’s only because you haven’t factored in the organizational constraints.

You have probably imagined people getting together and giving each other huge raises. That’s what would happen if there were no organizational constraints. Once the constraints are well determined and understood, the team members can determine who deserves what as long as they fit within their team’s budget.

How do you get management on board?

That’s a difficult one to answer. The first question managers typically ask is “What will my job be?”. People managers are used to controlling what their team does, when they do it and even how they will be delivering the work. As Dan Pink mentioned:

  • People are more motivated when they are self-organized;
  • People take their own commitments more seriously than the commitments made by others on their behalf;
  • Teams and individuals are more productive when they are not interrupted;
  • Teams improve when they can settle their own issues;
  • Changes in the composition of the team affect the productivity of the team members;
  • Face-to-face communication is the most productive way to share information. – Drive: The Surprising Truth About What Motivates Us

That’s the reason why Agile managers need to alter their leadership style in order to success in an Agile context.

Can this work in any culture?

Probably not. Well, not without some organizational commitment. During last year’s Agile Conference, Michael K. Spayd explained that some cultures are more likely to adopt Agile than others. As such, true self-organization is more likely to succeed in a Collaboration culture or in a Cultivation culture. William E. Schneider’s book (The Reengineering Alternative: A Plan for Making Your Current Culture Work) is very useful to help determine the 4 different types of cultures. Fortunately for us, Pyxis is a cultivation / collaboration culture.

How can people be motivated to work together?

Unfortunately, they can’t! Contrary to popular beliefs, people can’t be motivated – only they can motivate themselves.

To improve the team’s performance and the project’s results, we suggest that Agile project teams be staffed by asking people to volunteer for a project. Projects are typically staffed when project managers or people managers select the people who will take part of a specific project. Although that might seem like a good idea, it is much more powerful to seek volunteers. As one of the participant highlighted “I used to be bored to death in my normal job until one day, I asked (begged) to be part of a specific project. I’m so glad they granted my wish. I now work 55 hours a week! I am super motivated and nothing is going to make me want to leave that project”. Still think letting people select their project is a bad idea?

We are only starting with Agile, what do you recommend I read?

There are so many great books and blogs to help you get started with Agile. A while back, I published a getting started guide. I also read the following blogs:

I referred to the following books during my presentation

Upcoming events

If you wish to be notified of upcoming events, send an email to metrempe@pyxis-tech.com.

Is it better to work for a small organization or a large one?

Image by LegozillaThere obviously isn’t a clear and straight forward answer to this question. The answer depends on the perspective of the person you ask and what they value. After working 10 years in corporate America, I came back almost 3 years ago to work for a smaller organization (less than 100 employees). Two of my colleagues (Yves and Ida) also recently made the switch. We got together to exchange our thoughts on why we believe working for a smaller organization is better for us.

Martin: You have spent a large part of your career working for large organizations, what struck you when you joined Pyxis?

Yves: One first obvious observation goes along something I experienced before in a young publicly traded technology startup (less than 100 employees). For a given amount of effort you invest towards an initiative, whether on a individual scale, with a group or at the enterprise-wide level, your ROI (Return on Investment) is quite higher in a small organization than in a large one. The outcome on the initiative may end up being very successful in both environments, but in the small organization context:

  • The decision-making process will be faster and will involve less people;
  • The frequency at which you will be able to challenge and refine a set of actions on your initiative will be higher. Furthermore, your chances for celebrating at the end increases accordingly;
  • The whole initiative will execute at a faster pace and will complete sooner most of the time. Hence, a key variable inducing a positive impact is the reduced number of hand-offs between departments or people.

Ida: The first blatant differences I noticed were the lack of anonymity (you don’t feel like a number) and the lack of rules and regulations. The lack of anonymity puts you out there right away and is an enabler to allowing you to contribute and make a difference right off the bat. The fact that there aren’t many rules and regulations can also help in allowing you to make that difference faster, with no red tape to slow you down in your tracks.

Martin: Changing organization is an important decision that is usually done without having all the information. In hindsight, what information would have allowed you to make a better decision?

Yves: Organizational culture; without a doubt! Although I usually spend as much time being interviewed as making my very own due diligence on the organization, culture remains the number one factor for which you never get enough insights.

In an interview process, I do take extra care at being very transparent and straightforward on my value proposition. I do expect the same in return from the organization; and it is usually the case. However, the organizational part of the equation is far more complex than one individual being interviewed; putting everything he or she has on the table.

In hindsight, I do realize that most of my career changes would not have been different with more organizational culture intelligence at hand, so, same decision at the end. But gathering more info on that side of the story allows you to prepare yourself much better for the ‘culture tango’ coming at you.

Ida: From my perspective, I don’t feel that any additional information would have helped me make a better decision. The decision was a good one because of my mind set. I was ready for a change. I knew that a change in company or industry wouldn’t cut it, it had to be a bigger change of sorts, and ironically the BIG change translated into moving to a SMALL, privately owned company.

Martin: Many people who join smaller organizations feel more appreciated and a stronger sense of contribution toward the organizational goals. What are your thoughts on these?

Yves: Most of your actions in an smaller organization are very visible; for the better or for the worst… This allows you to have a positive impact towards your colleagues and the enterprise itself, without seeing all your efforts being diluted inside complex chains of commands, large hierarchies and impractical politics.

So, the visibility factor brings more appreciation and a stronger sense of contribution most of the time. It is actually a key attribute of smaller organizations, from my own point of view. This stimulates people at performing towards excellence, knowing their chances of being recognized for their hard work are quite high.

Ida: In a smaller organization, the impact is immediate. A decision can be made and an action is put in place. The lack of heavy hierarchies means that each individual is much more empowered to get things done and not necessarily have to wait for various levels of approvals as in large organizations. This empowerment is motivating, energizing and stimulating.

Likewise in a smaller organization, the breadth and depth of one’s responsibilitiesis usually much wider than in larger companies. This in itself provides additional satisfaction since people are not «boxed in» to a role that is strictly defined, allowing them the latitude to spread their wings.

Martin: What do you miss about working in a larger organization?

Yves: Sometimes, smaller organizations are facing challenges less prevalent in larger ones. For instance, financial stability may be a focus discussed over a monthly, or even over a weekly basis in a small company. Whereas in a larger organization, these matters will be discussed less often and more upon large-scale changes like restructuring plans and/or financial results being bellow expectations.

Furthermore, larger companies are having less of a hard time raising capital for their growing needs; in comparison with smaller organizations which are struggling a good deal in order to maintain an attractive balance sheet for banks and venture caps.

I still remember those funny days about 12 years ago; when it was so easy for startups to raise literally millions of venture cap out of PowerPoints or based on theoretical MBA classroom business cases. Hopefully these days are gone and we all now raise money based on common sense and sound financial practices. This however, illustrates how difficult it can be for a smaller organization to secure its financial future in 2011.

Ida: My answer to what I miss about a large organization is a two part answer, and each part contradicts the other, let me explain. Similar to Yves reply, financial stability is the most noticeable aspect that I miss. The luxury of knowing that there are enough funds to pay all expenses when they come in, invest in projects, expansions, acquisitions, etc. and be around in the long run, fosters an environment of growth, possibilities and positive reflections, in theory.

I say, in theory, because the existing reality in most large corporations, even though highly profitable, is the continual squeeze to do more with less. Hence the pressure is such that you are never profitable enough. It becomes an endless race. Factor into this internal pressure, pressures from the market and shareholders, legislation, the economy, and so on, and it becomes the endless race with umpteen hurdles. This is the part that I don’t miss, but it is very much tied to that financial stability I spoke of above.

Martin: Thank you Yves and Ida for sharing your thoughts on this topic. This was an interesting exercise. We may do this again in the near future.

Follow

Get every new post delivered to your Inbox.