Skip to content

Posts from the ‘Management’ Category

Transforming employees into shareholders may not be a good idea

image by risayv

Logic would tell us that offering shares of your company to your employees (assuming they are offered at a good price) should clearly boost performance and allow the organization to achieve exceptional results. After all, wouldn’t most people work harder, reduce inefficiencies, increase their performance and chase sale leads once they become shareholders?

Turns out logic does not necessarily prevail in this situation and results may not be extra-ordinary.

Let me share with you our not-so-successful experience.

Our experience

I’ve already stated that Pyxis is an experimental laboratory and like many people, we understand that money by itself is not a good motivator. We also believe that sharing the wealth with the people who contribute toward achieving the business results is not only a good idea, but it is for us a morale obligation.

So at the end of 2007, the founder and then CEO agreed to sell 25% of his shares to the employees with the intend to increase performance and share the resulting wealth – in addition to using it as an employee retention strategy. At the time, almost 100% of the employees created a cooperative to own shares of their company. It is important to specify that our province offers important tax credits to employee-owned cooperative – which was an important driver in creating a cooperative.

The conclusion after more than 3 years of having employee-shareholders is that the intend and the objectives were right but the way to achieve them weren’t done right. Why is that? I asked myself.

Below are my conclusions but before we get into those, I believe it is important to understand the distinction between being an employee and being a shareholder.

What is an Employee?

An employee contributes labor and expertise to an endeavour. Employees perform the discrete activity of economic production. Of the three factors of production, employees usually provide the labor.

Specifically, an employee is any person hired by an employer to do a specific “job”. In most modern economies, the term employee refers to a specific defined relationship between an individual and a corporation, which differs from those of customer, or client. Wikipedia

What is a Shareholder?

A shareholder or stockholder is an individual or institution (including a corporation) that legally owns one or more shares of stock in a public or private corporation. Shareholders own the stock, but not the corporation itself. Wikipedia

Clearly, there is a distinction between the role and contribution of an employee versus that of a shareholder. For one thing, transforming employees (with their behaviors and attitudes) into full-fledged active shareholders doesn’t happen over-night. To be honest, it still didn’t happen after over 3 years for almost 1/3 of the employees. Did we hire people who were not driven by results? Well, maybe for a couple of people but certainly not over 30% of the people. So why is it that results didn’t go through the roof?

After much analysis of the situation and heated debates, I believe there are a few reasons why transforming employees into shareholders didn’t give outstanding results:

  • Creating a cooperative has a non-capitalistic connotation: People who initiated the process of selling shares to the employees also wanted to implement a coop as a way to distribute wealth. Unless our implementation of a coop is very different than elsewhere in the world, many people understood a coop to be a non-profit driven initiative and as such, acted accordingly. Having a coop own 25% of the shares led to non-capitalistic behaviors and consequently slowed down growth and profitability.
  • Becoming an active shareholder isn’t the norm: Unless you have owned and operated a business in the past, the notion of becoming an active shareholder isn’t easily understood by most people. Many people – still to this day – ask themselves what it means to be a shareholder and how they should act differently. Transforming employees into shareholders is an educational process and unless you invest in training people what it means, the transformation will not give great results.
  • Lacking entry criteria brings performance downwards: Since everyone got access to shares without exception, there was no motivation to increase performance – why work harder than the next guy when the results are shared equally. On the other hand, when past performance is used to determine who gets the privilege to own shares, individual and collective performance is increased and as a consequence, the overall performance of the organization goes North.

Consequently, attempting to transform employees into shareholders overnight was a mistake in our case. If we had to do it again, I would still give employees the opportunity to own shares but it would be done according a different approach:

  • Owning shares is a privilege and would be based on past performance;
  • Allowing employees to own shares would be done in small increments, and annually (let’s say x% per year);
  • Potential shareholders would need to demonstrate their understanding of what it means to be an active shareholder and would need to agree to certain protocols;
  • The percentage of available shares would be results-based – the better the organizational results, the more shares would become available.

Based on this experience, I would gladly grant shares to employees who clearly understood the meaning and responsibilities of being an active shareholder and who have demonstrated (and are still demonstrating) outstanding performance. Otherwise, there is no wealth to share…

As an Agile Leader, I believe that …

Image by Robert GoodwinAs a leader, I believe it is important for people I work with to know my beliefs. As the leader of a self-organized company, I want to share those beliefs.

I personally believe that:

  • people are good in nature and wish to accomplish meaningful goals;
  • people truly wish to be successful and should be trusted to achieve success;
  • collective intelligence leads to better decisions;
  • individuals working together will find the solution to their problems, they know more about their skills, competences and environment than anyone else outside the team;
  • long lasting knowledge is best learn through hands-on experience;
  • as long as we learn something from the experience, failure is an investment, not an expense;
  • true success is achieved when people are in it for the long run;
  • a systemic perspective is useful to understand the entire system;
  • short term goals are rarely optimal and tend to maximize locally and not globally;
  • motivation comes from within, external factor do not really motivate people;
  • motivated people deliver better results and are highly contagious;
  • no single individual can (and should) be attributed success;
  • success attracts successful people;
  • you should judge people by their intention not their actions.

What are your beliefs?

Agile transitions are hard. I wonder why people feel the need to control?

Image by Gabriela CamerottiWith the Agile approach, we constantly try to implement self-organized teams. Many of us believe that autonomy leads to improved results whereas control may bring consistency.

« The opposite of autonomy is control. Control leads to compliance; autonomy leads to engagement » – Drive, by Daniel Pink

I asked myself, “Why do people need to control?” and came up with 2 reasons: lack of trust and ego. I feel it is important to understand where people come from in order to understand the environment in which we live and operate. As coaches, it’s also important to know why people behave in such a way so we can help them.

I recently talked about fears, which is closely related to the need to control.

The problem with novelty, however is that, for most people, novelty triggers the fear system of the brain. Fear is the second major impediment to thinking like an iconoclast [...] There are many types of fear, but the two that inhibit iconoclasting thinking are fear of uncertainty and fear of public ridicule (Iconoclast: A Neuroscientist Reveals How to Think Differently).

Lack of Trust

If we are in control of our environment, then we have a far better chance of survival. Our deep subconscious mind thus gives us strong biochemical prods when we face some kind of danger (Control)

It seems normal to try to control our environment and the people around us if we aren’t confident in their motivation. As such, people tend to control. Lack of trust is closely related to fear – fear of uncertainty. In a business context, people try to control for some of these reasons:

  • to make results more predictable and ultimately to prevent mistakes
  • to reduce the perceived level of risk
  • to hide incompetence

Everything that the brain sees or hears or touches has multiple interpretations. The one that is ultimately chosen – the thing that is perceived – is simply the brain’s best guess at interpreting what flows into it [...] These guesses are heavily influenced by part experience (Iconoclast: A Neuroscientist Reveals How to Think Differently).

Ego

On the other hand, ego is a completely different beast. The motivation behind controlling to protect the ego is at least as challenging to address as the lack of trust. The reasons behind the need to control to protect the ego are:

  • to avoid an un-pleasant situation – including being ridiculed
  • the lack of humility
  • to hide a personal motivation

Once again to be successful as change agents, it is our role to dig into the reasons behind the need to control. I’m not talking about psychology, I’m simply talking about root cause analysis of the situation in an attempt to properly address the symptoms.

Once we understand the source of the need, we are in a much better position to positively impact people and successfully implement the transition.

The more radical and novel the change, the greater the liklihood of new insight being generated. To think like an iconoclast, you need novel experiences (Iconoclast: A Neuroscientist Reveals How to Think Differently).

911 – “I need help! I’m a people manager and my team is going Agile…”

Image by Michael RansburgIn line with a few posts I recently published (this one and this one) and following conversations with people (and managers) around me, I decided to take another stab at helping people managers transform into agile leaders. Contrary to popular beliefs, people managers in an agile context are not doomed to buy pizza for their team and getting out of their way…

One of the underlying principles of Agile is to help organizations become more adaptive and flexible in order to (more) quickly react to changes in their environment. In this context, the agile manager has an important role, despite the fact that his traditional responsibilities can greatly change.

In his new role the agile manager needs to acquire or develop these abilities:

  • Adapt your leadership style: Every team reaches a certain level of maturity and the agile manager’s leadership style needs to be adapted to the context of his group.
  • Make yourself available: Your team members will need help and they will need to turn to someone they trust. Make yourself available and keep an open mind when problems arise so you can actually do something useful for them.
  • Help your team remain focused: Well jelled teams tend to become enthusiastic about what they can accomplish and sometime lose focus and get distracted by shinny objects – this is especially true with software development teams. In his role, the agile manager can greatly help his team members keep their focus in order to achieve their objectives.
  • Secure resources: In every traditional organization, departments are typically assigned a budget to provide a certain level of service and as such, the self-organized team rarely has the maturity and visibility to obtain the budget it needs to protect and grow the unit. The manager remains the best spoke person for his team since he has developed the political abilities to influence people around him.
  • Become a consultant to the team: Develop your credibility as an expert in certain areas and make sure to bring that value to your team members. As a rule of thumb, you shouldn’t show up at their meetings unless you are invited.
  • Guard the team from disruption: Once the self-organized team demonstrates a high level of performance, others around will notice and are likely to request activities, tasks or special projects from the highly performing team. The manager must then block disruptions and maintain the team’s focus in order to remain productive.
  • Be a spoke-person and do marketing: The team will want to achieve a high level of performance and once it does, recognition from others is a likely contributor to their motivation. The manager is an position to promote the success of his team – and indirectly his own as the manager of a highly performing team. If you believe “marketing” to be inappropriate, think again. After all, the manager delegated some of his authority to the team and as such deserves to get recognition.
  • Increase communication and visibility: A lot happens outside the team. The manager has to bring the information about the organizational threats and opportunities back to his team. Sometime even gossips can be useful information for the team.
  • Prepare the team for the future: As the team undertakes some of the traditional management responsibilities, the manager can spend some time actually preparing the team members for the career development, especially if some of the members are interested in developing their management expertise.
  • Offer to help with retrospection: The team is typically very focused on their activities in order to achieve the objectives that were defined for them. As a consequence their retrospection are likely to focus on short term, immediate challenges they are facing and much less about the long term. The manager may offer to facilitate meetings geared toward the future.
  • Grow the team members: Observe the team in action. In collaboration with the individual team members, determine which area they wish to develop in order to achieve their career goals and support them by coaching them.

Overall, in such a context the agile manager needs to start focusing on a strategic perspective as opposed to a very tactical one which is often what managers do despite their many promotions over the years.

The change is likely to be positive not only for the team but also for the manager himself – only if he develops enough self-confidence and courage to start operating this way.

Between a rock and a hard place – The managers in an agile transition

Image by NCM3I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time.

In agreement with his teams, Steven initiated an Agile transition a few months ago. I was part of the team who presented to Steven the benefits of a transition and the impact on the team members and their managers. I saw Steven again in a group training I was giving a few weeks after the beginning of the transition to managers and executives. That time again, Steven was very excited and motivated about what he was hearing, except that during the training I could see the light bulbs over his head and in the questions Steven was asking – how is this going to impact my role as a manager? Steven saw the obvious benefits and understood some of the changes he would need to make to his leadership style but I could tell, it hadn’t fully sinked in.

So here we were, less than 3 months in the transition and Steven wasn’t as chipper as he used to be…

  • Me: “Hey, Steven. You look tired. How are you doing?”
  • Steven: “I’m OK… I’m tired… [silence] The transition is killing me!”
  • Me: “How so?” [I asked anticipating what he would tell me next]
  • Steven: “The team is having a blast and I can see their performance has increased compared to the past but I don’t think I can cope with this new approach”
  • Me: “You seemed so excited about the transition when we started. What changed?”
  • Steven: “I now realize what you meant when you talked about changing my leadership style and my role. I’m still up to the challenge but my boss is totally clueless about all of this”
  • Me: “What do you mean? Haven’t you brought him in the loop from the beginning?”
  • Steven: “Yes. Yes, I have but that’s not the problem. The team’s performance increase is directly linked to the new approach they have been using and the fact that I leave them a lot of autonomy but my boss still asks me to behave like I used to – like he manages his team today. That’s where it hurts the most. I can pretty much deal with everything else but I feel like I’m stuck between a rock and a hard place”

Unfortunately, we (as consultants) do not do such a good job at highlighting this fact before we begin a transition. We work closely with the teams to help them adopt better methods and practices, to increase their overall performance by allowing them to be self-organized. We work on getting the teams to a highly performing level. Then we go get executive sponsorship to secure the initiative (and the budget) and make sure we get support to handle difficult issues but what about the people in the middle?

We develop training programs for Agile managers and we support them with organizational coaching but we don’t do such a good job at telling them upfront how much pressure they will be under once the transition begins. How much their role is likely to change and their leadership style needs to be adapted to the new reality.

For those who haven’t yet have felt the pressure, here are some examples of what to expect:

  • You may be willing to trust your team and let them self-organize but is your boss in agreement with this new approach? Will he be as involved (micro-managing) in your activities as he used to be? And more importantly, will he be expecting you to be as involved with your team as you used to be?
  • You may be willing to tolerate mistakes in order to increase your team’s learning and with a strategic perspective to increase long term performance but will you hear about your inabilities to control your team during your next performance review?
  • You already produce status reports, dashboards, emails and others information to keep everyone (including your boss) informed of what is going on in your unit. Will you need to translate everything that the Agile team is producing to fit the traditional reporting mechanisms? Can you challenge what information is currently being produced to ensure it does bring value to people?
  • You expect your team members to handle the details of their activities and you believe in actually seeing (touching, feeling) the end results while your management team expects you to assess progress using Gantt charts. Do you need to educate your entire organization to the new approach? Does the fact that you are adopting Agile make you the evangelist for the entire organization?

Obviously, I don’t mean to scare anyone – especially the managers – with regards to adopting Agile. The approach has a lot of merit and value for many organizations but in order to help with adoption, coaches and consultants need to pay attention to the people in the middle and help them find their new place, otherwise we are very likely to find serious resistance and potential failure of such initiatives – nobody likes to be stuck between a rock and a hard place…

Yet Another Agile Maturity Model (AMM) – The 5 Levels of Maturity

I am very aware of the previous debates on the need for an Agile Maturity Model (see the Other Useful Links at the end of this post). I actually agree with Esther Derby’s recent post

How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter. What does matter is that your company is satisfying its customers, stakeholders, and employees. (Achieving Agility: Means to an End, or End in Itself)

But let’s face it, people like to know where they stand compared to others. Starting at a very young age, we have been raised and trained to compare our results to others in an attempt to reach the next level – whatever the next level may be.

We get into such comparison as:

  • Are my grades better than Tommy’s?
  • Can I run faster than Carl?
  • Am I stronger than black belt Anna?
  • Did I earn more frequent flyer miles than Frank?

It’s the same thing with Agile. People – managers and executives mostly – really have the need to know they are headed for the top of the maturity model. It may not make much sense but they have been raised and trained to measure, to compare, and to brag when comparing favorably or to adapt when comparison isn’t positive for them.

As I already stated, I agree with Esther when she says that it doesn’t really matter how Agile you are. What matters are the results. So along those lines, I believe it is important to associate the level of maturity and the related results which I believe exist and can be demonstrated.

Unfortunately, there isn’t much hard data to demonstrate that achieving a certain level of maturity provides x% of improved performance or y% cost reductions but most of us who have been implementing Agile within organizations would agree that that higher the maturity, the better the results. So it is based on these observations that I decided to present yet another Agile Maturity Model.

As recently reported by Forrester, Scrum being the most adopted Agile approach these days, the proposed maturity model heavily relies on the adoption of Scrum practices with a lesser consideration to other practices such as: Agile Modeling, Feature-driven development – FDD, Test-driven development – TDD, eXtreme Programming – XP, etc. By no mean I am rejecting or considering those other approaches non-important. I built this model mostly on Scrum because this is the comparison organizations are asking us to be evaluated on at this time.

The Agile Maturity Model

Agile Maturity Model

Level 1 – Team Level Maturity

At this level, team members have decided to adopt Scrum and/or software engineering practices without asking for approval from their manager. Some of the well known practices are used but without consistency.

Agile Maturity Model

Team

  • A Scrum Master is in place
  • The Team has adopted some of the Scrum practices and artifacts but may not use them consistently
  • The process isn’t documented and tends to vary by project
  • Agile practices have been self-taught
  • Process is limited to the solution team
  • The team doesn’t understanding the language used by the business representatives

Department

  • Outside the team, almost nobody has heard or understand what Agile means
  • Other teams are unaware or not interested in the approach used by the Agile team
  • Mostly business as usual

Business

  • Unaware or not interested in the approach used by the team
  • Business as usual
  • Complains that what the information technologies team delivers is not what is needed or asked for
  • Misunderstanding of the language used for the development team

Project Managers

  • Unaware or not interested in the approach used by the team
  • Follow the traditional project management approach

Managers

  • Unaware or not interested in the approach used by the team
  • Business as usual

Results

  • Team is slightly more productive
  • Moral is slightly improved
  • Much friction with project managers, people managers and the business as the team members try to teach people outside the team what Agile is and what it can do for them

Level 2 – Department Level Maturity

At this level, the practices adopted by the team members have started to be imitated by other teams within the software development department. Some of the managers have noticed the positive results of adopting the Agile approach and are tempted to replicate what they observed.

Agile Maturity Model

Team

  • A Scrum Master is in place
  • Some of the teams have adopted some of the Scrum practices and artifacts and are starting to use them consistently
  • Consistency across the teams is uneven and mostly depends on the leadership and perseverance of a few individuals
  • Some of the process is documented but it tends to vary by team
  • Agile practices have been self-taught or a coach was hired to help the team launch their initiative
  • Process is limited to the department

Department

  • Mostly business as usual
  • Agile is sometime discussed in departmental meetings with some interest from people outside the team immediately impacted
  • An increasing number of teams are adopting Agile practices

Business

  • A business analyst acts as the proxy for the business representative
  • Unaware or not interested in the approach used by the team
  • Collaboration between the development team and the business side remains mostly unchanged except maybe for increased interaction between the 2 groups
  • Business decision are still mostly made by business analysts or architects

Project Managers

  • Starting to be aware of the new practices used by some of the teams
  • Mostly resistant to change since they are lacking information about the new process
  • Follow the traditional project management approach
  • Do not consider the Agile approach to be very solid for large scale projects

Managers

  • Unaware or not interested in the approach used by the team
  • Business as usual

Results

  • Teams that have adopted the Agile approach are slightly more productive
  • Moral is improving
  • Productivity varies from one team to the next
  • Some teams’ productivity is decreasing since they have hit important hurdles
  • Some teams have abandoned the new approach and have gone back to their traditional approach
  • Some friction between the development and the business teams in light of the new approach

Level 3 – Business Level Maturity

At this level, the solution teams have integrated the business people in the model. Collaboration (and trust) has increased and a partnership relationship is increasing.

Agile Maturity Model

Team

  • Scrum Masters are in place
  • The 3 Scrum roles are well understood and respected
  • If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
  • External help has been used to achieve this level of maturity
  • Team members are attending Agile conferences

Department

  • There is confusion around the roles of: business analyst, architect, database administrators and project managers
  • The process is documented and tends to be consistent across projects
  • External help has been used to properly implement the Agile practices

Business

  • A Product Owner is clearly identified and may be dedicated to their project
  • The concept of incremental and iterative development is gaining more acceptance from the business representatives
  • Process is slowly expanding within the business side
  • Product Owners bring some of their colleagues to end-of-sprint demonstrations

Project Managers

  • Starting to be aware of the new practices used by some of the teams
  • Mostly resistant to change since they are lacking information about the new process
  • Follow the traditional project management approach
  • Do not consider the Agile approach to be very solid for large scale projects

Managers

  • Awareness is increasing at the director level within IT and Business of the new Agile approach
  • Many assumptions and misunderstanding remain
  • A strong evangelist is in place to promote the new approach and bring together the IT and business side of the organization

Results

  • Project teams using the Agile approach are more productive
  • Moral of the people using Agile is much higher than those outside the Agile teams
  • Some friction with project managers and people managers remain where most people tend to fall back to their traditional paradigms

Level 4 – Project Management Level Maturity

At this level, the project management approach is modified to include some of the Scrum practices. Although the department still mostly relies on the traditional PMBOK recommendations, Scrum has been integrated in the project management approach.

Agile Maturity Model

Team

  • There is a clear segmentation between the role of the Scrum Master and that of the project manager
  • If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
  • Interference with the team’s activities is almost eliminated
  • The team is autonomous and the Scrum rituals and artifacts are respected and standardized

Department

  • The department has adopted many of the Scrum practices and artifacts and are using them consistently
  • Much of the confusion around the roles of: business analyst, architect, database administrators and project managers have been eliminated
  • The process is documented and is consistent across projects
  • External help has been used to properly implement the Agile practices

Business

  • Product Owners are clearly identified and are dedicated to their project
  • The project manager is well accepted and is part of the Product Owner team
  • The concept of incremental and iterative development is fully accepted from the business representatives
  • Process is expanding to the business side

Project Managers

  • Projects managers are fully aware of the new practices used by the teams
  • Resistance to change has been replaced with adaptation of the traditional approach to include a more Agile approach
  • Agile is accepted as a solid approach for large scale projects

Managers

  • Awareness of the new Agile approach is increasing at director level and above within the IT, Business, and Project Management organizations
  • Some assumptions and misunderstanding remain for managers
  • Training initiatives have begun for management and attendance is high
  • A strong evangelist is in place at the management / executive level to promote the new approach

Results

  • Project teams using the Agile approach are more productive
  • Moral of the people using Agile is much higher than those outside the Agile teams
  • Friction between traditional roles are being handled

Level 5 – Management Level Maturity

At this level, managers have adapted their management style to support an Agile organization. Organizational structures and reporting mechanisms are better adapted for collaboration and improved for increased performance.

Agile Maturity Model

Team

  • Scrum Masters are in place
  • The 3 Scrum roles are well understood and respected
  • If there is more than 1 Scrum team, a Scrum of Scrum has been put in place
  • External help has been used to achieve this level of maturity
  • Team members are attending Agile conferences

Department

  • The department has adopted many of the Scrum practices and artifacts and are using them consistently
  • There is no confusion around the various roles surrounding the projects
  • The process is documented and is consistent across projects

Business

  • Product Owners are clearly identified and are dedicated to their project
  • The project manager is well accepted and is part of the Product Owner team
  • The concept of incremental and iterative development is fully accepted from the business representatives
  • Process is expanding to the management level of the organization

Project Managers

  • Projects managers are fully aware of the new practices used by the teams
  • The traditional project management approach has been adapted to include a more Agile approach
  • Agile is accepted as a solid approach for large scale projects
  • Review the best practices to adapt to changing realities

Managers

  • Have fully transferred the authority and responsibility to the teams to allow them to do their job properly
  • Avoid interference and micromanagement
  • Promote collaboration and teamwork
  • Support continuous learning and do not systematically penalize failures
  • Adapt their management style to the context of their team

Results

  • The various projects using Scrum are more productive than those using a traditional approach
  • Moral is high all around
  • Friction around the new approach has disappeared
  • Strong collaboration between all parties involved
  • Organization is able to quickly react to changes in its environment
  • Management is considering implementing Agile to projects that do not require software development

Level 6 – Corporate-wide Level Maturity

Utopia or the nirvana? At this level, the entire organization – the people, the processes and the tools are aligned with the Agile principles and values. As I haven’t had the opportunity to witness such an organization (yet), I am unable to describe the criteria to be used to qualify for this level.

Other useful Links

Getting Started – Reference Material for Managers Who Wish to Understand Agile and Scrum

Image by DarlingSnailFor those of us who have been working with Agile for a while, the values, the principles, the approach, the methods and the practices are almost second nature but for those who start to enter the Agile world, the ramp up can be challenging – especially if you are looking at all of this from a management position.

After being asked by a few people “Where can I start if I would like to know more about Agile?”, I decided to put together this short list of reference material. There is also a good discussion happening on LinkedIn.

I am missing anything? Is there material you would recommend to managers?

What is Agile?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.

The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. (Agile software development – Wikipedia)

“Agile Development” is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).

While each of the agile methods is unique in its specific approach, they all share a common vision and core values (see the Agile Manifesto). They all fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system. They all involve continuous planning, continuous testing, continuous integration, and other forms of continuous evolution of both the project and the software. They are all lightweight (especially compared to traditional waterfall-style processes), and inherently adaptable. As important, they all focus on empowering people to collaborate and make decisions together quickly and effectively. (Agile 101: What is Agile Development? | VersionOne)

Just what is agile software development? In 2001, a group of methodologists got together to agree on a common set of guiding principles around effective software development. Rather than summarize their agreements here, I’ll point you to their “agile manifesto”.

From a pure definition standpoint, agile is a conceptual framework generally centered on iterative and incremental delivery of working software, driven by the customer. The iterative part suggests that we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features. (A Brief Introduction to Agile — Developer.com)

What is Scrum?

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the team. This is done because the team will know best how to solve its problem. (Introduction to Scrum – An Agile Process)

Scrum is an iterative, incremental framework for project management and agile software development. Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.

Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project/program management approach. (Scrum (development) – Wikipedia)

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. (Scrum Alliance -What Is Scrum?)

The Scrum Roles

Scrum has three roles: Product Owner, ScrumMaster, and Team. (Scrum Alliance -Scrum Roles)

Tips for an Agile Transition

Perhaps, but not necessarily. Pilot projects are commonly done for two reasons: To see if something will work or to learn how to make it work. By now, enough other companies—very likely including some of your competitors—are using agile approaches like Scrum that there is no longer any question of if it works. The real question most organizations face is how to make agile or Scrum work for them. One or more pilot projects can be very helpful in providing those answers. (Transitioning to Agile)

Organizational Impact of an Agile Transition

When development teams adopt agile practices, product management is often caught off guard by the amount of work added to their already overflowing plate. Agile calls for new product management skills and traditional staffing models do not typically accommodate the new product owner role. Given that most product managers are already overworked, how can they manage these new activities to derive more value from software projects and products? (InfoQ: How Product Management Must Change to Enable the Agile Enterprise)

Agile methodologies are helping software organizations stay competitive by delivering products more frequently and with significantly higher quality. Making the switch to agile development also challenges traditional notions of project management, introducing new ways of managing time, cost and scope. Learn how to successfully manage agile projects with the resources below. (Agile White Paper: The Agile Project Manager | VersionOne)

When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of “manager” seems to be missing entirely. “Well I guess we’ll have to just get rid of ‘em all!” wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats. (Scrum Alliance -Manager 2.0: The Role of the Manager in Scrum)

About Agile Coaching

Agile methodologies introduce a newer role, typically called the “Agile Coach” that traditional methodologies will not focus on, or even mention. For those who have been working in an agile way for some time, it may seem like a natural complement, yet for those newer to this way of working it raises many questions like, “What’s so important about an Agile Coach: What’s wrong with a Line Manager, or a Team or Technical Lead: Why does Monster.com list 54 positions with this title:” (InfoQ: The Agile Coach, from A to Z)

Market Trends

Gartner’s analysts (Thomas Murphy and David Norton) predict that by 2012 “agile development methods will be utilized in 80% of all software development projects”. The authors explain that although Scrum will continue gaining in popularity over the coming years, organizations will not be successful in their transition unless they move toward a team-focused culture (Gartner Predicts 2010: Agile and Cloud Impact Application Development Directions | Analytical-Mind)

In their recently released study “Agile Development: Mainstream Adoption Has Changed Agility“, Forrester reports that “35% of respondents stated that Agile most closely reflects their development process”. The report is based on Forrester’s/Dr. Dobbs Global Developer Technographics Survey, Q3, 2009, which surveyed 1298 application development professionals. (Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility” | Analytical-Mind)

Recommended Blogs

Recommended Books

What the heck does an Agile Organizational Coach do?

Picture by icedsoul photography .:teymur madjdereyIf you are in the process of transitioning your organization to an Agile approach, you have certainly realized that moving to Agile impacts more than the software development team – if you haven’t realized it yet, you will eventually find out the hard way ;-)

In a large scale transition, it is necessary to work with the various managers to help them understand and assimilate the principles related to Agile and make them integrate those principles into their day-to-day actions. Therefore, an Agile Organizational Coach helps managers change their management approach to a leadership style better suited for an Agile environment.

The transition to a new leadership style is not limited to the software development teams. It also applies to the interactions and relationships with the business team’s managers. Making managers more Agile requires changes in their behavior, more specifically, it requires managers to:

  • Transfer certain powers to the team members themselves so they can determine how best to accomplish their tasks;
  • Define the desired vision, to adapt to the context of each team to ensure alignment with the overall objective of the project and ensure cohesion between the teams and their members;
  • Accept and publicly endorse the idea that the status quo is no longer acceptable and that the old methods are no longer adapted to the new reality;
  • Adapt their style of management when necessary to use an inclusive and democratic approach.

As such, the role of the Agile Organizational Coach is to:

  • Educate managers through appropriate training;
  • Create groups (communities) of interest and exchange to assist managers in their development;
  • Organize individual and group meetings with various stakeholders to understand their fears, their challenges, their resistance and to provide the necessary support to help;
  • Work with groups who require special support during the transition;
  • Participate in management committees where the presence of an agile expert is required.

    Are You a “Fiber One” or a “Cocoa Puffs” Manager?

    In line with my earlier post (Are you an Agile Leader? – Nine questions for people managers), I like to use metaphors to explain various concepts but I also like metaphors to determine the profile of the people attending my presentations. I recently used the cereal metaphor presented below (the power point slide is available here).

    In addition to being a good ice-breaker for the presentation, this slide usually gets people talking about (and sometime defending) their management style. Needless to say the “Fiber One” managers are often the ones who find the agile concepts harder to grasp.

    Which cereal are you?

    Are you an Agile Leader? – Nine questions for people managers

    Picture by angus mcdiarmidOne of the frequent obstacle encountered by project teams when transitioning to Agile is the resistance of their manager. When an executive declares that the organization is moving to Agile, many team members look forward to working differently – that is until their manager gets involved.

    As an organizational coach, I often use a simple questionnaire to assess the level of agility of the managers I deal with. Below are nine questions to help determine how Agile the manager I’m talking to actually is.

    Go ahead – try the short test.

    True or False?

    1. To get the best results, it is preferable to properly control the activities of the team members
    2. A process that is not well defined at the outset will always give sub-optimal results
    3. To reduce the loss of productivity, it is preferable to isolate team members in cubicles and use email as the preferred a mode of communication
    4. A team of experts with specialized knowledge is always more efficient than a multi-disciplinary team
    5. The best tools and processes are those selected by the organization and standardized for all groups
    6. It is generally preferable to thoroughly document what we people do even if it reduces their speed
    7. Money is the best way to keep individuals motivated
    8. It is more important to follow the plan than to adapt to changes
    9. A signed contract is better than an informal agreement to ensure cooperation between different departments

    How did you do?

    If you answered True:

    • 9 times (out of 9): As you enter an Agile transition, your current management paradigms are likely to be severely tested, but with the right mindset and the willingness to change you could be surprised. You may want to take this test again a few months after the beginning of the transition to see how much you have progressed.
    • Between 5 and 8 times (out of 9): You have some of the right reflexes but you haven’t fully grasped the concepts behind Agile. With some work and an open mind, you could modify your leadership style and eventually become an Agile manager.
    • Between 1 and 4 times (out of 9): You’re almost there. You are comfortable with most of the Agile concepts but still need to fine-tune some of your reflexes to make it to the top of the chart.
    • 0 time (out of 9): Congratulations! You seem to understand the Agile approach and the underlying concepts very well. If you behave the way you answered these questions, you are an exemplary Agile leader. Send me an email, I certainly would like to hear from you.
    Follow

    Get every new post delivered to your Inbox.