So you have initiated an Agile transition and have faced some resistance to change! Or maybe, you assessed your current level of Agile Maturity and are hoping to achieve the next level. Better yet, you and your team are planning to launch an Agile transition that is not driven by the wrong reasons.

That’s great!

If you haven’t already done so, you may want to read: Getting Started – Reference Material for Managers Who Wish to Understand Agile and Scrum and What consultants don’t tell you before you begin an agile transition.

Let’s cut the chase and get to the point. Are you ready? Here it is. The secret to a successful Agile Transition -> Make people look good!

Yes. That’s it. Surprised?

I’m not talking about psychological manipulation. I’m talking about finding what drives the people you are working with and the managers around them and then capitalize on their drivers in order to get them to get on board with the transition – and better yet become evangelist for your transition. Here are some examples:

• Suzy is hoping to get promoted to Vice-president within her organization. She heads a business line from which you need support and a dedicated Product Owner. Why don’t you explain to Suzy how innovative her group would appear to others if she agreed to embark on the Agile initiative?
• Peter is struggling to increase the performance of his group. So far, he hasn’t shown much interest in the transition but you found out that he has been under high pressure from his manager to increase the performance of his team. Why wouldn’t you show Peter how using an Agile approach could help get his manager off his back?
• Monica is a project manager who has lost several key people in previous months. She is usually by-the-book (i.e. PMBoK) but during a recent lunch, she admitted that she would be willing to try something different if only it would help her retain the contributors she needs to make her project successful. Why don’t you take this opportunity to get the project manager on board with Agile by offering to help her?

Don’t get me wrong. I am not asking you to lie, to cheat or to fake the objectives and expected outcome. I’m telling you to get others on board and working WITH you by telling them the whole story and helping them understand that there is something in it for THEM too.

Agile relies heavily on communications and interactions. Why don’t you start with all the people directly and indirectly impacted by the transition? Sure, it will require more time in the short term to influence people into supporting you but in the long run, you will be glad you did it.

Go ahead. Try to figure out what drives people around you or what issues they are facing. Find a solution that can help them and you’ll end-up with a win-win scenario and a successful transition.

You might be interested in these related posts:

1. Agile Transition – What about the teams outside the transition?
2. Book review: Outliers: The Story of Success
3. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers

A few weeks ago I referred to Daniel Pink’s book (Drive: The Surprising Truth About What Motivates Us) to show how autonomy, mastery, and purpose greatly impact people’s motivation and how we can use these dimensions to help in an Agile transition.

Today’s post is about Alessia and her painting.

Alessia is a happy 9 year old girl. She is self motivated when it comes to painting. She always:

• gets up on time for her Saturday morning classes;
• is anxious to go to her classes;
• is learning quickly and
• does very nice work.

If you have young children, you certainly already know how difficult it is to get them to do something they don’t want to do – pick up their clothes, get up on time, hang their towel after their shower, etc. But when kids are self-motivated, things are completely different. Don’t you find?

Grown-ups aren’t much different. When people are told to do things or are assigned tasks, the quality of the work can’t be as optimal as when THEY decide to do it. Not only isn’t the quality as good but the amount of energy required to deliver the task is much higher than if the individual wanted to do it in the first place.

Granted, relying on self-motivation requires people managers to come up with ways to make the tasks interesting or fun, or they can also rely on the concept of Autonomy (or self-organized teams) which is so strongly emphasized with Agile.

Needless to say, if kids can self-organize and be self-motivated, so can grown-ups. All they need is the right environment to do so.

I am proud of my daughter

Don’t worry Giordano, daddy will write a post about you too

You might be interested in these related posts:

1. The kids are having a great time at Sportmax
2. Timmy's story: Is it better to be right or to be helpful?
3. More time does not create better decisions

Last week, I attended the breakfast conference presented in Montreal by Ken Schwaber.

As always, Ken gave a great presentation focusing on the “definition of done” in Scrum and the impact of incorrectly defining what done really means.

As I was listening to the presentation, I looked outside the window overseeing René-Levesque boulevard and noticed an asphalt truck and city workers filling a pothole – then it hit me… As interesting and valuable Ken’s presentation was, we need a systemic approach if we want Scrum to succeed in organizations. Let me explain…

Nobody likes to drive on a street with potholes. So what do cities do? Obviously, they fix them! If you live in Montreal, you realize that every year, the city fills thousands of potholes in an attempt to keep their streets in a good driving conditions but no matter how much efforts (and money) the city invests, the potholes keep appearing.

Isn’t this like implementing Scrum within an organization?

As attendees to Ken’s presentation, weren’t we simply like city workers attending an asphalt conference? It is as if an asphalt guru was explaining to us the right mix of tar and rocks to make the most resistant asphalt when in reality, the problem isn’t really with the asphalt itself but with the city’s traffic management approach.

Same goes for Scrum.

The definition of done is critical. The right people in the right roles is important. Dedicated teams members is crucial. But what about the managers in the organization? Are they supporting Scrum? I mean, are they really supporting the use of Scrum within their organization?

Don’t get me wrong. I truly believe doing Scrum the right way is critical but it is not sufficient to be successful. If your managers aren’t on board, you can try to implement as many of the Scrum best practices as you want – including the right definition of “done” – your teams will never reach the highest level of performance they could. Get the managers on board and your Scrum implementation will be greatly improved.

You might be interested in these related posts:

1. Agile Data Warehouse
2. Introduction to Scrum – Shareable Power Point Presentation
3. 4e Salon Business Intelligence in Montreal

I finally registered to attend the upcoming Agile conference in Orlando. Just like last year, I’ll be posting my thoughts on the various sessions I’ll be attending.

An invitation for my fellow bloggers or to people who are passionate about Agile Organizational Coaching. Drop me an email (mproulx [at] pyxis-tech [dot] com) if you would like to chat or meet for lunch.

I’ll be there with Eric and Jean-René, two great coaches.

You might be interested in these related posts:

1. Someone is looking for a job
2. Looking for a challenge? You may be interested in an Agile Organizational Coach Job
3. Interesting blog posts (February 1, 2010)

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

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.

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.

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.

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.

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.

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

• The Agile Maturity Model (AMM) posted on April 1, 2010.
• Does Agile Need Its Own Process Maturity Model? posted on June 1, 2009.
• Scott Ambler Revisits Agile Process Maturity Models posted on April 27, 2009.
• Agile CMMI: Complimentary or Oxymoronic? posted on December 19, 2008.
• The Agile Maturity Model posted on August 2, 2008.
• Does the Agile Community Need a Maturity Model? posted on October 16, 2007.
• An “Agile Maturity Model? posted on June 7, 2006.

You might be interested in these related posts:

1. Gartner’s “The Current State of Agile Method Adoption”
2. Agile Transition – What about the teams outside the transition?
3. Secret Revealed! Guaranteed Success for your Agile Transition

I already talked about silence as a communication tool but I can now estimate the value of silence at nearly $600,000 per hour. I recently came to this surprising conclusion when I bought my new car a few weeks ago.

Before I tell you my surprising story, I need to explain a few things about silence. During my coaching development program, we were explained that leaving room for silence allows the other person to clearly express their thoughts and feelings. Without silence, those thoughts and feelings would be unspoken and hence, unknown.

Keeping silence in a conversation also puts an uncomfortable pressure on the person spoken to – to speak. Try it for yourself and see how strange the situation becomes when no one is speaking.

To help us as coaches, we were told to keep our mouth shut and mind focused by counting in our head. You leave room for silence and start counting (in your head, otherwise there is no silence!). 1, 2, 3, 4… While you are counting, the other person feels some pressure and most probably will start talking – usually what follows the silence is very useful information.

So back to my story.

After seeing a few dealers and selecting the car I was going to buy, I entered into the typical negotiation scheme with the car salesman.

• Salesman: “$xx,xxx. This is my final price”
• Me: “Sorry, that’s too high. I did research on the Internet and I have a pretty good idea what the markup is on this car”
• Salesman, looking shocked: “Let me see what my supervisor can do for you”
• Salesman, coming back after a few minutes: “It’s your lucky day, my supervisor says that he wants us to reach our quota, so we’ll take out another $1,500″
• Me: “That’s nice but it’s still higher than what I’m willing to pay for this car”
• (…) a few more rounds of negotiation (…)
• Salesman, somewhat surprised: “You know, (blah, blah, blah)…”
• Me: “I understand. Listen, thank you for your time. I’m not in a hurry so I’ll keep shopping”
• Salesman, getting anoid: “Listen, if you are that serious. I’ll take out another $1,000 but that’s really the best I can do!”
• Me, pulling out my credit card to make a deposit: “I don’t believe this is the best price you can make. What else can you do…”
• SILENCE
• Me (counting in my head): “1, 2, 3, 4, 5, 6…“
• Salesman: “I’ll take out another $1,000 but I can’t and won’t go down anymore”
• Me: “Deal!”

$1,000 off the final price for 6 seconds of silence. Isn’t that a nice hourly rate!

You might be interested in these related posts:

1. Using silence as a communication tool
2. The new employee has an opinion
3. It's Sunday and I can't wait to go to work tomorrow

As Agile Coaches, we aim to be efficient. We analyze the situation around us, we ask questions, we experiment, we share our thoughts and observations, we make suggestions and recommendations. We try to be helpful.

Are we always efficient in the way we ask our questions? Could we ask our questions differently for better impact?

Below is a list of qualities associated with Powerful Questions taken from the reading material of the certification program I’m currently undertaking.

• Clarity
• Brevity
• Relevance
• Direct
• Single Subject
• Positive expression
• Allow silence for the response

To be powerful, the questions should also have an impact. To be impactful, the question should aim at:

• Personal issues and remain contextual;
• Motivation behind the actions;
• Consequences of the actions.

And include the question “what else?”.

What we are looking for in the levels of information provided is:

• Facts
• Emotions
• Opinions

Finally, to be truly powerful, the questions should take the person out of his comfort zone in order to explore new horizons. Questions such as the following are usually very helpful:

• What would happen if …?
• With hindsight, what can you see?
• If you were an expert in this field, what would you do?
• If you had a magic wand, what would you do?

Formulating a question isn’t always easy but to be an impactful coach, properly asking the question is critical. Hopefully, these few tips can help you become a better coach.

You might be interested in these related posts:

1. What Is Coaching? And Other Relevant Questions
2. It's Sunday and I can't wait to go to work tomorrow
3. On my way to coaching certification

A few weeks ago, I wrote about The Nine Dimensions of Agile Leadership. As a follow up to that post, I came up with a preliminary Agile Leadership Assessment Questionnaire. Without being scientific and statistically representative, this assessment highlights the strengths (and weaknesses) of the leadership supporting the agile initiatives.

Simply download the questionnaire and select your answers (column D) to each question. The second tab of the spreadsheet presents a graphical representation of the results (as shown below).

You can download and try the Agile Leadership Assessment Questionnaire for your projects. This work is licensed under a Creative Commons Attribution-Noncommercial 2.5 Canada License.

Share your thoughts with me on this tool.

You might be interested in these related posts:

1. Results of my 360 degrees feedback. What my colleagues had to say.
2. Using a 360-degree feedback form to assess your leadership
3. Scrum Artifact: Burn Down Chart

For 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

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

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

You might be interested in these related posts:

1. Scrum Role: Scrum Master
2. What is Scrum?
3. Scrum Role: The Scrum Team

In a large scale transition similar to the one we have undertaken a few months ago, it is difficult (and maybe impossible) to transition all the teams / departments at once. Similar to the prioritization of the product backlog, we have selected a handful of projects to launch immediately. Unfortunately, this means that many (many more) projects will not begin their transition for a while since the organization we work with has decided that coaches are required to help them succeed.

As such, we have decided to implement a strategy for those “out of transition” teams. Below is the approach we selected in order to make the transition successful without negatively impacting the performance (and the workload) of those directly involved in the transition. Based on our experience, we felt it was important to have a strategy (albeit minimal) to support other projects to be implemented using an Agile approach.

The reasons why it is important to have a strategy for those “out of transition” projects are as follows:

• To maintain a unifying vision of what we are trying to accomplish with Agile;
• To maximize our efforts in the development and selection of tools supporting Agile;
• Not to ‘abandon’ the projects that were not deemed highest priority;
• For other projects to be executed successfully in an Agile mode even if they are not part of the intial selection.

Therefore, we suggested having a reduced service catalog for the “out of transition” projects. Examples of services that can be offered are:

• Training courses offered to the selected projects could also be attended by “out of transition” participants;
• A simple audit of the “out of transition” projects’ practices and high level recommendations for improvement;
• Limited support;
• Access to the corporate wiki for information, knowledge sharing and best practices.

So far, the recommendation has been well received by the “out of transition” projects. In the months to come, we will be able to determine if we made the right decision.

You might be interested in these related posts:

1. What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful
2. What consultants don’t tell you before you begin an agile transition – Part 2: Impact on some of the traditional roles
3. What consultants don’t tell you before you begin an agile transition – Part 1: Impact on the organization

Following an earlier post on this topic and based on the increasing popularity of Agile Leadership, I have revisited my previous model with the experience we are gaining with the transitioning a large Canadian financial institution. Although the transition is still underway, our increasing experience is allowing us to improve the model.

The fundamental objective of this model remains to increase return on investment (ROI) and employee satisfaction / motivation within the project teams while applying the 4 Agile values and 12 underlying principles.

LEADERSHIP

Leadership is stated as the “process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task” – Wikipedia.

Objectives setting and performance management

Goal setting involves establishing specific, measurable and time-targeted objectives - Wikipedia.

Performance management includes activities to ensure that goals are consistently being met in an effective and efficient manner - Wikipedia.

This dimension of the model focuses on:

• Using a clearly defined vision, identifying and communicating clear objectives so that people know what to do;
• Aligning the goals of the team members amongst themselves and with the focus on delivering business value to the organization;
• Providing frequent feedback to employees so they can adapt their performance accordingly;
• Evaluating the performance level of the project team, in addition to individual performance.

Management and leadership style

Management in all business areas and organizational activities are the acts of getting people together to accomplish desired goals and objectives - Wikipedia.

Leadership style refers to a leader’s behaviour. It is the result of the philosophy, personality and experience of the leader - Wikipedia.

This dimension of the model focuses on:

• Switching from a traditional “command and control” to a “servant leadership” style;
• Abandoning an autocratic and prescriptive style to make room for autonomy and emergence;
• Allowing space for teams to become autonomous;
• Adopting a situational leadership style based on the maturity level of the team;
• Evaluating the end results rather than the means used to implement the plan;
• Assisting the team in addressing its needs;
• Providing the necessary support to develop individuals;
• Giving people the right to make mistakes;
• Facilitating collaboration.

ENVIRONMENT

Surroundings are the area around a given physical or geographical point or place - Wikipedia.

Work environment and organizational culture

Organizational culture is an idea in the field of Organizational studies and management which describes the psychology, attitudes, experiences, beliefs and values (personal and cultural values) of an organization - Wikipedia.

This dimension of the model focuses on:

• Establishing a favorable work environment to support the success of an Agile project;
• Providing open and collaborative spaces;
• Providing simple tools such as whiteboards;
• Reserving small enclosed meeting rooms;
• Using furniture that can easily be moved;
• Providing hardware and software that reduces the costs and initial delays to start-up projects.

PROJECT TEAM

A project team is a team whose members usually belong to different groups, functions and are assigned to activities for the same project - Wikipedia.

Autonomy and accountability

Autonomy is a concept found in moral, political, and bioethical philosophy. Within these contexts, it refers to the capacity of a rational individual to make an informed, un-coerced decision - Wikipedia.

Accountability is a concept in ethics and governance with several meanings. It is often used synonymously with such concepts as responsibility,answerability, blameworthiness, liability, and other terms associated with the expectation of account-giving - Wikipedia.

This dimension of the model focuses on:

• Giving authority to the team to allow it to do its job properly;
• Transferring the authority and responsibility to the team:
  • The way to do things and organize work (the HOW?)
  • On the allocation of tasks and ideally on the composition of the team (the WHO?)
  • On the estimation of effort required to complete tasks (the HOW MUCH?)
  • It can even be the place (the WHERE?) and the work hours (the WHEN?)
• Avoiding interference and micro-management;
• Giving autonomy to individuals to make them accountable;
• Creating teams of reasonable size to facilitate collaboration and communication;
• Letting people who are closest to the action make the final decisions;
• Providing the necessary support when the team requests it.

Collaboration and teamwork

Collaboration is a recursive process where two or more people or organizations work together in an intersection of common goals - Wikipedia.

Teamwork is work performed by a team - Wikipedia.

This dimension of the model focuses on:

• Promoting collaboration and teamwork;
• Maintaining a climate of trust and respect within the team;
• Developing the concept of compromise;
• Taking a position of cooperation and negotiation rather than honoring contracts;
• Encouraging discussion and debate of ideas in order to bring out the best decisions.

Communication and knowledge sharing

Communication is a process of transferring information from one entity to another - Wikipedia.

Knowledge sharing is an activity through which knowledge (i.e. information, skills, or expertise) is exchanged among people, friends, or members of a family, a community or an organization - Wikipedia.

This dimension of the model focuses on:

• Encouraging the use of face-to-face communication;
• Providing opportunities for people to share information and knowledge;
• Establishing communities of practice to promote the exchange of knowledge;
• Making relevant information visible to all participants.

Skills and Professional Development

A skill is the learned capacity to carry out pre-determined results often with the minimum outlay of time, energy, or both - Wikipedia.

Professional development refers to skills and knowledge attained for both personal development and career advancement - Wikipedia.

This dimension of the model focuses on:

• Ensuring that participants have the skills required to successfully execute their tasks;
• Promoting training and development when the skills are not adequate.

Continuous improvement and organizational learning

Continuous Improvement Process is an ongoing effort to improve products, services or processes. These efforts can seek “incremental” improvement over time or “breakthrough” improvement all at once - Wikipedia.

Organizational learning is an area of knowledge within organizational theory that studies models and theories about the way an organization learns and adapts - Wikipedia.

This dimension of the model focuses on:

• Allowing the team to question frequently its good (and bad) actions in order to improve;
• Not systematically penalizing failures;
• Addressing recurrent problems;
• Documenting and make visible the organizational barriers;
• Reviewing the best practices to adapt to changing realities.

Processes and Tools

Process or processing typically describes the act of taking something through an established and usually routine set of procedures to convert it from one form to another, as a manufacturing or administrative procedure, such as processing milk into cheese, or processing paperwork to grant a mortgage loan, or converting computer data from one form to another - Wikipedia.

A tool is a device that is necessary to, or expedites, a task - Wikipedia.

This dimension of the model focuses on:

• Letting the best processes and tools emerging from the team members;
• Allowing the team to choose its tools and adapting its processes to maximize performance;
• Disseminating best practices to other groups;
• Ensuring that the team has set its own rules of operation.

I am building and using this framework to help dissect the key components of Agile Leadership in order to help explain it to people managers and team members. Based on your experience, are there any dimensions missing?

You might be interested in these related posts:

1. The 5 Dimensions of Leadership in an Agile Context
2. The 7 Dimensions of an Agile Project Team
3. Agile Leadership (Agile Management) – part II

If you work in an Agile environment or better yet, if you manage people who have embraced the Agile principles, you have certainly bought into the concept of self-organized teams. The underlying assumptions are that:

• 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.

Needless to say, management hasn’t changed much in a hundred years with its need to control and its chief tools remain extrinsic motivators.

Taylor believed that work consisted mainly of simple, not particularly interesting tasks and that the only way to get people to work on them was to incentivize them properly and monitor them carefully. Later on, Maslow developed the field of humanistic psychology in the 1960s (which questioned the idea that human behavior was purely ratlike seeking positive stimuli and avoiding negative stimuli) and McGregor challenged the assumption that humans are fundamentally inert (in the absence of external rewards and punishments, we wouldn’t do much).

In his most recent book (Drive: The Surprising Truth About What Motivates Us – audiobook format), Daniel Pink presents many factoids taken from scientific researches to demonstrate how people can (and can’t) be motivated. Although the author brings a scientific perspective to people motivation, the book is easy to read in addition to being entertaining.

Scientists then knew that two main drivers powered behavior. The first was the biological drive (comes from within) and the second comes from without – the rewards and punishments the environment delivered for behaving in certain ways [...] The third drive – performance of a task provides intrinsic reward. The joy of the task is its own reward.

Autonomy, Mastery, and Purpose

In his book, Pink states that human beings have an innate inner drive to be autonomous, self-determined, and connected to one another.

Autonomy

The opposite of autonomy is control. Control leads to compliance; autonomy leads to engagement.

Pink’s book provides valuable scientific explanations to the concept of self-organised teams. He presents the ROWE (Results-Only Work Environment) concept and the Self Determination Theory (SDT) to demonstrate the relationship between autonomy and well-being. He goes further to associate autonomy with higher productivity, less burnout, and greater level of psychological well-being. More closely related to software development, the author presents the level of authority given to employees at software giant Atlassian where people decide: what they do, when they do it, how they do it, and whom they do it with.

Mastery

The desire for intellectual challenge (the urge to master something new and engaging) was the best predictor of productivity.

Daniel Pink explains that people are motivated by self-development and learning of new skills or developing existing abilities. The actual challenge of mastering a discipline is often a better motivator than money can be (assuming a minimal level of income). Similar to children who easily get motivated with playing – which is a way for them to learn and master a skill – managers can leverage that ability to motivate individuals.

As such, human beings are said to have an inherent tendency to seek out novelty and challenges to extend and exercise their capacities to explore and learn – which are in themselves powerful motivators.

Purpose

The science shows that the secret to high performance isn’t our biological drive or our reward-and-punishment drive, but our third drive – our deep-seated desire to direct our own lives, to extend and expand our abilities, and to live a life of purpose.

The author points out that many psychologists and economists have found that the correlation between money and hapiness is weak – that is past a certain level, a larger pile of cash doesn’t bring people a higher level of satisfaction. As such, contrary to traditional motivational techniques, money does not increase happiness and performance – some research have actually demonstrated the opposite effect! It is possible to keep people highly motivated without constantly leveraging money as a motivator.

Human motivation seemed to operate by laws that run counter to what most scientists and citizens believe. When money is used as an external reward for some activity, the subjects lose intrinsic interest for that activity. Rewards can deliver a short term boost but the effect wears off and worse can reduce a person’s longer-term motivation to continue the project.

In direct contravention to the core of tenets of motivation 2.0, an incentive designed to clarify thinking and sharpen creativity ends up clouding thinking and dulling creativity. Why? Rewards, by their very nature narrow our focus. That’s helpful when there’s a clear path to a solution. They help us stare ahead and race faster but “if then” motivators are terrible for challenges. The rewards narrowed people’s focus and blinkered the wide view that might have allowed them to see new uses for old objects.

Carrots and Sticks – The Seven Deadly Flaws

1. They can extinguish intrinsic motivation
2. The can diminish performance
3. The can crush creativity
4. They can crowd out good behavior
5. They can encourage cheating, shortcuts, and unethical behavior
6. The can become addictive
7. The can foster short-term thinking.

The relation to software development

Algorithmic tasks are tasks in which an individual follows a set of established instructions down in a single pathway to one conclusion. That is, there’s an algorithm for solving it.

A heuristic task is the opposite precisely because no algorithm exists for it, individuals have to experiment with possibilities and devise a novel solution. Software development is a heuristic task.

During the twentieth century, most work was algorithmic but as McKinsey & Co. estimated that in the United States, only 30 percent of job growth now comes from algorithmic work, while 70 percent comes from heuristic work.

Researchers have found that external rewards and punishments – both carrots and sticks – can work nicely for algorithmic tasks but they can be devastating for heuristic ones.

Conclusion

If you need scientific explanation and useful examples to explain to people around you why a self-organized (autonomous) team with team members who are striving to develop their skills in an attempt to reach a common purpose is possibly the most impactful motivator, you may want to read this book.

Video

You might be interested in these related posts:

1. You don’t believe workers can self-organize. Think again. Even 8 year-old kids can do it!
2. Book Review: Lean Software Development
3. Sir, please step away from the team

In conversations with upper management, I often hear that they wish to start using an Agile approach to increase their return on investment (ROI) and the employee motivation – which is great! They have read or have been told that changing their approach should lead to:

• Delivering solutions that meet the business needs…
• …without exceeding time lines or costs and…
• …increase efficiency and productivity.

Many people manager (although not all) understand that people are more motivated when they are self organized and as such, take their commitments more seriously than if the commitments were made by others on their behalf (i.e. their manager).

What is news to many of these managers is the impact an Agile transition will have on them – and their management style. I like to point out that to them that:

• Teams and individuals are more productive when they are not interrupted;
• Team performance improves greatly when people settle their own issues;
• Changes in the composition of the team affect the team’s productivity.

As such, people manager need to learn to:

• Transfer the authority and the responsibility to the team members to allow them to do their job properly;
• Avoid interference and micromanagement;
• Promote collaboration and teamwork;
• Support learning without systematically penalizing failures;
• Establish a culture conducive to Agile projects;
• Adapt their management style to the context of team.

Overall, they must learn to change their management style from a command-and-control approach to a servant leadership style.

Easier said than done – that’s where the Agile Organizational Coach steps in.

You might be interested in these related posts:

1. Scrum Role: The Scrum Team
2. The 7 Dimensions of an Agile Project Team
3. Step one – having a plan

We are currently recruiting Agile Organizational Coaches.

Main duties and responsibilities

The Agile organizational coach works directly with the Information Technology and Business management teams to help leaders assimilate and apply the Agile principles to their day-to-day activities.

The organizational coach helps transform the traditional management style to a more Agile approach. Thus, the coach helps managers to properly assess the differences between the current situation and a set target. He then works with the managers to define a suitable plan and take concrete actions to address the obstacles encountered during the transition. More specifically, the organizational coach:

• Through appropriate training, educates managers to the application of  Agile to their management style;
• Creates groups (communities) of interest and exchange to assist managers in their development;
• Meets with various stakeholders to understand the fears, challenges, and resistance and provides the necessary support to help them;
• Participates in various management committees to train members of such committees and support them in their development.

Requirements

• Have held a management position within a large organization;
• A minimum of fifteen years of experience in managing software development teams;
• A minimum of two years experience in an Agile development environment;
• Significant experience in project management;
• Bachelor’s degree in business administration, commerce or management.

Assets

• Certified ScrumMaster;
• Bilingual (English and French);
• Experience in the financial sector (banking, insurance, investment);
• Certification from the International Coach Federation.

General Criteria

• Political acumen and diplomacy;
• Ability to find solutions win-win situations;
• Passionate and self-motivated;
• Team player;
• Talented facilitator;
• Understanding of business needs, business processes and organizational dynamics of a business.

You might be interested in these related posts:

1. What the heck does an Agile Organizational Coach do?
2. What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful
3. Currently recruiting Agile consultants

If 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.

You might be interested in these related posts:

1. Looking for a challenge? You may be interested in an Agile Organizational Coach Job
2. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers
3. What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful

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?

You might be interested in these related posts:

1. How do you react to bad news? Assess your management skills
2. Don't Sell Buzzwords to Business Leaders, Learn How to Describe Real Value
3. Agile Data Warehouse

One 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?

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.

You might be interested in these related posts:

1. What consultants don’t tell you before you begin an agile transition – Part 3: Impact on the functional and people managers
2. Hierarchies aren't evil… but people can be!
3. What Is Coaching? And Other Relevant Questions

In conversation with potential clients, I almost always ask them the following question: “Why do you want to move to Agile?” and in most circumstances their answer makes sense. I would get answers such as:

• We are hoping to improve productivity;
• We aim to decrease time to market;
• Turn over has been high and we wish to implement an approach that will increase employee morale;
• We need to reduce costs;
• Etc.

And then, I get what I would call “wrong answers”. Those answers address my question at face value but also show that the decision has not been evaluated for more than thirty seconds. Here are 7 “wrong reasons” to adopt Agile. Go ahead – share yours!

1. We recently attended a conference and Agile is becoming more popular. If others are doing it, so should we.

2. Because Gartner and Forrester say so.

3. Because employees asked us to do so.

4. Some of our people are available to experiment with a new approach.

5. Our competitor is gaining market share and they are using Agile. We need to use the same approach if we want to be able to compete.

6. We produce too much documentation.

7. Because our boss told us to do so.

Other interesting articles:

Destination: Agile Top Eight Reasons Why Organizations Are Making the Switch

3 Reasons Why I Would Not Do Agile Project Management

Introducing Agile Methods: Mistakes to Avoid

Why Agile doesn’t sell with Management ?

11 Ways Agile Adoptions Fail

You might be interested in these related posts:

1. 10 Reasons to Doubt Your Agile Transition Has Been Successful
2. The new employee has an opinion
3. Clueless – 7 hints you’re probably not on the Agile track

The results are in!

In the survey I recently posted, to the question How would you react to bad news? most people would “wonder if their management style had anything to do with the current situation”.

How would you react to bad news?

Rest assured, this survey didn’t pretend to be scientific and the statistical method could easily be challenged. Nonetheless, it is nice to see that people would display what I would think to be the right behavior.

I can’t quite understand why 21% of the people would curl up in a foetal position :-p

You might be interested in these related posts:

1. How do you react to bad news? Assess your management skills
2. Hierarchies aren't evil… but people can be!
3. We need better management – we need agile management

As an Agile coach and working for a consulting organization that specializes in Agile Software Development, I get to meet people who have decided to adopt or are thinking of adopting Agility within their organization.

I have to say, most people understand what an Agile transition means for them and their organization and are willing to make the changes required to make their transition a success.

And then, there are others who are most likely adopting Agile for the wrong reasons and as such, aren’t really interested or even aware of what it means for them.

I’ve put together a short list of 7 (real life!) conversations that made me wonder if common sense had left the building. Feel free to share your conversations…

Time estimates

• Client: I don’t understand. Since we’ve adopted Agile, our developers consistently exceed the time estimates for their tasks.
• Me: Interesting. Who provides the time estimates?
• Client: The project manager…

Change Management

• Client: We are really serious about implementing Agile within our organization.
• Me: Great! You realize Agile is not a silver bullet that will magically eliminate all your issues?
• Client: Of course, we are fully aware. We would like to start with a new project that is scheduled to start shortly.
• Me: Good. Following our earlier conversation, you realize you will have to make changes to the way your team is currently working and that might impact their productivity in the short term.
• Client: We can’t impact the team’s productivity. The project budget, scope and time lines have already been defined and the project is already 2 months behind schedule…

Trust

• Client: We have identified a list of issues that we need help with. Here’s the list. Can you help us?
• Me: Possibly. Let me look at your list. Who came up with the items on this list?
• Client: Me and my direct reports.
• Me: Has the team been involved in putting this list of issues together?
• Client: Absolutely not. We asked them to put together a list of issues they were facing and most of the items were related to lack of trust, micro-management, and bad communication so we threw out their list and put this one together for them…

Retrospection

• Client: We are just about to begin a new iteration but our last iteration was a disaster. We missed our time lines, the product owner is upset at the development team and morale is very low.
• Me: Have you done a retrospection at the end of your iteration?
• Client: No. We need to start development on the new project immediately.
• Me: Wouldn’t there we be value in evaluating what went wrong in order not the repeat the same mistakes?
• Client: We don’t have time for that and quite honestly, we don’t want the team’s morale to get worst once they realize how bad the situation is…

Management Support

• Client: This Agile thing is great! I’m going to impress the management team with our success.
• Me: How so?
• Client: The development team asked me if they could use Agile for their next project and from what I read, Agile can help them improve their performance and reduce the time to market.
• Me: Yes, if it’s done right you may get those benefits.
• Client: Wonderful! After I gave them the go ahead to start immediately, I told them I now expected to project to be delivered in 9 months (instead of 18 months) and cut their budget by half…

Collaboration

• Client: Agile has done good things for our development team but we keep facing issues with project members that don’t report into our department.
• Me: Who are those external contributors?
• Client: The architects and the DBAs.
• Me: Do you keep them informed of your project progress? Do they get involved in defining the stories? Do they estimate their work?
• Client: Hell, no. We simply assign them the work they need to do and complain to their boss if they fall behind…

Scrum Master

• Client: I don’t understand why things aren’t working well.
• Me: What is the issue?
• Client: We took the Certified Scrum Master training you offer, we read a few books, and we’ve started implementing Scrum but nothing seems to be working.
• Me: What do you mean?
• Client: The only thing we didn’t do is take a natural leader to be the Scrum Master. Robert was available so we asked him to be the Scrum Master.
• Me: Who is Robert?
• Client: Robert has been with the company for 22 years. He’s one of the few Mainframe project managers who preferred not to learn the new web technologies and since he didn’t have any assignments, we thought he could do the job…

Do you have any hints you would like to share?

You might be interested in these related posts:

1. You are not doing SCRUM if you don't have a ScrumMaster
2. What consultants don’t tell you before you begin an agile transition – Part 2: Impact on some of the traditional roles
3. I didn't have time to do this

Following my posts on delivering results in an agile context, the 7 dimensions of an agile project team and their agile work environment, this fifth and final post on Agile Leadership presents the “Leadership” level of the model. I’m hoping to help managers, leaders, and stakeholders better understand which behaviors to modify in order to obtain better performance and improve employee satisfaction within their organization. I came up with five dimensions associated with Leadership in an Agile context.

Before I begin, I want to make a distinction between management and leadership. Over the years, the terms “leadership” and “management” have often been used as synonyms. To distinguish the two words I would specify that leadership is “transformational” in nature while management is more “transactional”.

Leadership

Leadership has been described as the “process of social influence in which one person can enlist the aid and support of others in the accomplishment of a common task” (wikipedia)

Servant Leadership

Servant-leaders achieve results for their organizations by giving priority attention to the needs of their colleagues and those they serve. Servant-leaders are often seen as humble stewards of their organization’s resources (wikipedia)

Management

Management in all business areas and human organization activity is the act of getting people together to accomplish desired goals and objectives. 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 (wikipedia)

Goal Setting

Goal-setting ideally involves establishing specific, measurable, attainable, realistic and time-targeted objectives. Work on the goal-setting theory suggests that it can serve as an effective tool for making progress by ensuring that participants have a clear awareness of what they must do to achieve or help achieve an objective (wikipedia)

A few questions to assess the Goal Setting dimension of the Leadership model:

• Are the team members objectives aligned with one another?
• Are the suggestions coming from the retrospection of the team taken into consideration in the objective settings?

Performance Management

Performance management includes activities to ensure that goals are consistently being met in an effective and efficient manner (wikipedia)

A few questions to assess the Performance Management dimension of the Leadership model:

• Does the leader clearly define the objectives of his people?
• Does the organization measure its progress toward its goals?
• Is the performance measured at the team level in addition to the individual level?
• Does the company evaluate both the individual’s work behaviours and outcomes against the defined objectives?
• Do the team members receive timely and frequent feedback?

Remuneration

Remuneration is pay or salary, typically a monetary payment for services rendered, as in an employment (wikipedia)

A few questions to assess the Remuneration dimension of the Leadership model:

• Do managers mostly rely on intrinsic (rather than extrinsic) motivation?
• Does the remuneration model reflect the individual’s contribution to the team or is it based on seniority?
• Is the compensation model clearly understood by all team members?
• Is the leader rewarded for the development of his members?
• Do team members participate in the definition of the compensation of their colleagues?
• Is the compensation model strictly based on individual performance?

Coaching

Coaching refers to the activity of a coach in developing the abilities of coachees. Coaching tends to focus on the achievement by coachees of a goal or specific skill (wikipedia)

A few questions to assess the Coaching dimension of the Leadership model:

• Does the leader support its members in their skills and competences development?
• Does the leader take the time to teach his team members on how to increase their skills and better themselves?
• Is the leader selected by the team members?
• Is the leader evaluated by his team members?

Change Management

Change management is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state (wikipedia)

A few questions to assess the Change Management dimension of the Leadership model:

• Does the leader work with the team members to establish a clear change management strategy?
• Does the leader acknowledge that the pace of change is different for all team members?
• Does the leader deal constructively for team members’ resistance to change?

Leader’s Qualities

Finally, in order to assess if the leader has the right qualities to be successful in an agile environment, I have selected a handful of qualities the leader should clearly demonstrate.

Does the Leader display the following qualities?

• Making decision when necessary
• Enthusiasm / Optimism
• Humility
• Respect
• Trust
• Integrity
• Confidence

You might be interested in these related posts:

1. The 7 Dimensions of an Agile Project Team
2. Agile Leadership (Agile Management) – part II
3. What is Agile Leadership?

Have a few minutes? Want to quickly assess your ability to react to bad news? Try this short exercise.

Context

Working for a large multi-national organization, you are the head of a 40 people software development team. Your team’s ability to deliver on their commitment continues to decrease despite implementing new measures to help boost productivity.

During a recent lunch meeting, you were informed that things on the floor are really bad by one of your external partner. In an attempt to help you, the partner offers to present some key findings about your team – their processes, their tools, their skills, their environment, etc.

In order to share the suggestions of your external partner with your team, you invite your direct reports (managers) to the presentation. It’s a sunny day outside and despite some technical glitches, the consultants begin the presentation by stating the objective of the meeting and inform you they intend to be very candid. After a few introductory slides, the real content of the presentation begins…

Slide 6

Slide 7

Slide 8

How would you react?

Enter your answer below. I will publish the results shortly.

You might be interested in these related posts:

1. Using a 360-degree feedback form to assess your leadership
2. We need better management – we need agile management
3. Defining Agile Management – part 1

As a follow-up to my post on Agile Leadership, I have described the 7 dimensions of an Agile Project Team and what it means to deliver results in an Agile context. This forth (out of five) post briefly looks into the Agile Work Environment (or Agile Work Space) to successfully support the delivery of results by the project team.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done – Principles behind the Agile Manifesto.

As suggested by the Manifesto, providing the right environment will support a fast paced, entrepreneurial, flexible and autonomous culture allowing the project team to focus on their objective while enjoying their environment.

A few questions to assess the work space configuration of the project team:

• Are all team members co-located?
• Does the physical environment support effortless communication?
• Are team members within 10 meters (30 feet) of a white board?
• Are team members allowed to stick post-it notes to the walls around them?
• Does the project team have access to natural light?
• Are team members allowed to decorate their work space?
• Do the project team members have access to free good-coffee?
• When necessary, do team members have access to private rooms to concentrate on their activities?

Needless to say, the right work environment can have a significant impact on the project team’s performance. More specifically, the right work environment should support the team’s autonomy, ability to communicate and collaborate. It should support the use of the right processes and tools to be efficient while allowing them to enjoy their surroundings.

You might be interested in these related posts:

1. The “Best Agile Work Space” Contest (The BAWS Contest)
2. Day one in an Agile environment
3. What is Agile Leadership?

As mentioned in my guest post on Management 3.0, times are changing and many organizations are finding ways to lead people to deliver better results.

Having spent most of my professional career in the software development industry, either as a consultant or as an employee of large corporations, it is obvious that many of my inspirations for leadership came for the technology side of things. I quickly realized two things:

1. Working with technology opened my perspective to more innovations and allowed me to develop a willingness to continuously improve what was around me – not only the technology but the tools and the processes in order to derive better performance from people and later on to strive for a more balanced work-life,
2. I noticed that many people in organizations who could change the way people were managed were caught in their old paradigms:
   • Senior managers who had power refused to change and were counting the days until retirements,
   • Middle managers who had an open mind, had no time to implement innovations or had no power to do so,
   • Support departments were more interested in maintaining status quo after years of implementing policies and procedures and weren’t so inclined to look for better methods.

Once in a while, an external consultant would present some promising avenue to help improve performance and morale but their attempt would vanish once they closed the doors behind them.

Then came Agile. Although the Agile Manifesto was published in 2001, I discovered the underlying principles years later and it became obvious to me that what was recommended for software development organizations would certainly work, outside the technology departments. For almost two years, I have been analyzing the principles, reading books, and working with colleagues and clients to derive an improved method of working. From my “Rebel Leadership” concept came the “Agile Leadership” approach.

You might be interested in these related posts:

1. Agile Leadership (Agile Management) – part II
2. Agile Principles Applied to Management
3. Defining Agile Management – part 1

A few days ago, I broke down the key dimensions associated with an Agile Project team in an attempt to explain Agile to managers but I purposely excluded the concept of RESULTS in order to remain focus on the key dimensions. As such, the main reasons why an organization would choose to go Agile haven’t been specifically addressed in my previous post.

Working software over comprehensive documentation - Manifesto for Agile Software Development

Yes, working software is the goal of the project team but the ultimate goal of the organization remains to maximize return on investment (ROI). The next logical question should be “What does maximizing return on investment (ROI) mean in an Agile context?”

In my opinion, maximizing ROI in an agile context means:

• Paying the right price for the developed software while getting the most business value – the right price means the cost associated with the labor without significant overhead costs;
• Developing a competitive advantage by adapting to changes in the environment while quickly and incrementally developing the results in order to capture the market opportunities;
• Increasing customer satisfaction by giving them the product they need, when they need it;
• Allowing project team members to develop their skills while having fun.

Too many times, maximizing ROI simply means increasing throughput and/or decreasing cost – no matter what. Delivering results in an agile context should not limit its focus on the very short term but also take into consideration a longer term investment in the capabilities of the team members.

You might be interested in these related posts:

1. The 5 Dimensions of Leadership in an Agile Context
2. FAQ: Communities in the context of business
3. We have a huge budget and too much time to complete our business intelligence (BI) project