Monthly Archive for: ‘July, 2010’

Secret Revealed! Guaranteed Success for your Agile Transition 2

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.

Posted on: 07-26-2010
Posted in: Agile, People Management, Perception, Work environment and organizational culture

Self motivation – Alessia’s story 5

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 ;)

Posted on: 07-22-2010
Posted in: Autonomy and accountability, Skills and Professional Development

Ken Schwaber and the asphalt truck 1

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.

Posted on: 07-19-2010
Posted in: Management and leadership style, Scrum

Attending Agile Conference 2010 – Want to talk about Agile Organizational Coaching? 3

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.

Posted on: 07-16-2010
Posted in: Agile 2010, Conferences

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

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

Posted on: 07-12-2010
Posted in: Agile, Leadership, Management, Organizational Structure, Project Team, Transition to Agile

Silence is worth $600,000 per hour 7

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!

Posted on: 07-7-2010
Posted in: Learning, People Management, Strategy

Asking Powerful Questions – Agile Coaching 3

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.

    Posted on: 07-5-2010
    Posted in: Agile, Learning, Management and leadership style