Imagine my surprise when a candidate for an agile organizational coach role within our organization shared with me his perspective on this topic.
“Can you share with me your reasoning?”, I asked him intrigued.
The candidate went on to explain that people need direction and that people cannot self-organized without clear objectives and direction.
Indeed, I thought to myself. Who said people and teams shouldn’t be given clear objectives. On the contrary, in my opinion, clear goals are necessary for teams to organize otherwise you end up with a bunch of people who will try to find a reason, a purpose why they are all together – and their self-created goal may very well be different from what you had in mind in the first place.
Where I have a problem is that people associate self-organized teams with “abandoned teams” meaning you simply let the team figure it out – whatever “it” is.
In order to reach the level of autonomy they need to demonstrate extra-ordinary performance, teams need to reach the right level of maturity. Consequently, the manager’s leadership style is critical to achieve that objective. Within Pyxis, we often rely on the combination of the situational leadership and the group development stages to determine the proper level of involvement from the manager.
One of the way to achieve the right level of maturity is for agile managers to determine WHAT must be accomplished and let the team determine HOW it will be done – I already shared my opinion on this topic. Granted, things are more complex that I make them sound in this post but self-organization is indeed possible when the right environment is created for the team – including clear objectives – and it is then given the latitude to operate and determine how best to achieve the given goal.
If only managers would be willing to let go some of their (need to) control and trust the teams, a higher level of performance can be attained.
As you may have guessed, the candidate wasn’t called back for a second interview…
I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time.
In agreement with his teams, Steven initiated an Agile transition a few months ago. I was part of the team who presented to Steven the benefits of a transition and the impact on the team members and their managers. I saw Steven again in a group training I was giving a few weeks after the beginning of the transition to managers and executives. That time again, Steven was very excited and motivated about what he was hearing, except that during the training I could see the light bulbs over his head and in the questions Steven was asking – how is this going to impact my role as a manager? Steven saw the obvious benefits and understood some of the changes he would need to make to his leadership style but I could tell, it hadn’t fully sinked in.
So here we were, less than 3 months in the transition and Steven wasn’t as chipper as he used to be…
Me: “Hey, Steven. You look tired. How are you doing?”
Steven: “I’m OK… I’m tired… [silence] The transition is killing me!”
Me: “How so?” [I asked anticipating what he would tell me next]
Steven: “The team is having a blast and I can see their performance has increased compared to the past but I don’t think I can cope with this new approach”
Me: “You seemed so excited about the transition when we started. What changed?”
Steven: “I now realize what you meant when you talked about changing my leadership style and my role. I’m still up to the challenge but my boss is totally clueless about all of this”
Me: “What do you mean? Haven’t you brought him in the loop from the beginning?”
Steven: “Yes. Yes, I have but that’s not the problem. The team’s performance increase is directly linked to the new approach they have been using and the fact that I leave them a lot of autonomy but my boss still asks me to behave like I used to – like he manages his team today. That’s where it hurts the most. I can pretty much deal with everything else but I feel like I’m stuck between a rock and a hard place”
Unfortunately, we (as consultants) do not do such a good job at highlighting this fact before we begin a transition. We work closely with the teams to help them adopt better methods and practices, to increase their overall performance by allowing them to be self-organized. We work on getting the teams to a highly performing level. Then we go get executive sponsorship to secure the initiative (and the budget) and make sure we get support to handle difficult issues but what about the people in the middle?
We develop training programs for Agile managers and we support them with organizational coaching but we don’t do such a good job at telling them upfront how much pressure they will be under once the transition begins. How much their role is likely to change and their leadership style needs to be adapted to the new reality.
For those who haven’t yet have felt the pressure, here are some examples of what to expect:
You may be willing to trust your team and let them self-organize but is your boss in agreement with this new approach? Will he be as involved (micro-managing) in your activities as he used to be? And more importantly, will he be expecting you to be as involved with your team as you used to be?
You may be willing to tolerate mistakes in order to increase your team’s learning and with a strategic perspective to increase long term performance but will you hear about your inabilities to control your team during your next performance review?
You already produce status reports, dashboards, emails and others information to keep everyone (including your boss) informed of what is going on in your unit. Will you need to translate everything that the Agile team is producing to fit the traditional reporting mechanisms? Can you challenge what information is currently being produced to ensure it does bring value to people?
You expect your team members to handle the details of their activities and you believe in actually seeing (touching, feeling) the end results while your management team expects you to assess progress using Gantt charts. Do you need to educate your entire organization to the new approach? Does the fact that you are adopting Agile make you the evangelist for the entire organization?
Obviously, I don’t mean to scare anyone – especially the managers – with regards to adopting Agile. The approach has a lot of merit and value for many organizations but in order to help with adoption, coaches and consultants need to pay attention to the people in the middle and help them find their new place, otherwise we are very likely to find serious resistance and potential failure of such initiatives – nobody likes to be stuck between a rock and a hard place…
My colleague François Perron launched a very interesting discussion on our private wiki – “As a coach, what to do when executives and upper management force the project team to do over time in order to meet deadlines?”.
As you can probably guess, this initiated very interesting discussions and an obvious reaction to such an approach.
Everyone agreed that due to the project visibility and the position of the organization within its market, the project launch date was critical. Everyone also understood that the organization had very few options so nobody debated the need to achieve results. The discussion was strictly around which measures to use in an Agile context.
I’ll admit up front that I am biased toward intrinsic motivation (I really loved Drive by Dan Pink) and the fact that it is well suited for an agile environment.
As such, my first impression to the conversation that was going on were:
Does the organization wish that employees spend more hours at the office (attendance) or would they prefer more engagement (commitment)?
If their choice is to increase the hours of attendance, imposing overtime will achieve this goal while giving them a false sense of increased performance. People will show they are working longer hours but the real throughput is unlikely to be much higher. In addition, software development is a brain intensive activity and reducing the amount of rest people get is likely to increase the number of mistakes they make.
On the contrary, if the organization wanted more involvement, the inclusion of team members in determining the best way to achieve the results would probably come to a better decision – even possibly leading the willingness to do over time
It appears to me that by forcing overtime, the executives and senior managers will probably collect their bonus and congratulate each others in the short term only to realize in the longer term that they have simply pushed the problem forward for others to deal with – and possibly request more over time in the long run.
At the Agile 2010 Conference this week, out of the two hundred or so sessions presented, a number of them talked about the role of the manager in an Agile team. A few people believe managers are no longer necessary once the team has self-organized while others say people managers are still required. Either group failed to provide compelling arguments for their position.
The notion of self-organized teams keeps gaining visibility and acceptance. Those who have adopted the approach can’t stop talking about the benefits. At the same time, people realize that managers are unlikely to disappear from the organizational landscape anytime soon. In this context, it is with a mixed-feeling that Agilists talk about the role of the people manager in an agile organization – mostly as something not so useful but that the team needs to keep around in order to maintain their autonomy – something similar to the appendix.
The most common explanation for the appendix’s existence in humans is that it’s a vestigial structure which has lost its original function – source wikipedia
Then a few things happened.
First, I got to attend Michael Spayd‘s session called “Blueprint for an Agile Enterprise: Plans, Tools & Tech to Build a Human Enterprise”.
Want your whole organization to be more like an Agile team? Starting teams is well understood; expanding Agile to the organization is definitely not. Using 8 years experience applying organization development to Agile, we’ll unfold a 7 layer organizational architecture for building a human enterprise. Each level has an overall perspective, specific tools and key practices. Part tutorial, part demo, we’ll create a change plan for one participant’s organization, exploring culture, leadership, change, team performance, and management’s role. You’ll leave with a plan template and many ideas – source Agile 2010 Program
Then, I went to Damon Poole’s session called “Getting Managers and Agile Teams Out of Each Other’s Hair”.
One of the most talked about and least well understood concepts in Agile is the “self-managing” team. This session will provide a new perspective on self-management by examining the external roots of the practice and by taking a bottom-up look at what it is, the benefits, and how it works. We’ll see how twelve widely adopted Agile practices contribute to self-management by reducing and/or redistributing traditional management activities. These practices provide a framework for delegation, communication and coordination; and encourage team ownership, commitment and accountability – source Agile 2010 Program
Finally, I also attended Jim Highsmith session called “What do Agile Executives and Leaders Do?”
In some circles agile executives and leaders are admonished to buy pizza and get out of the way. In others they are asked to be supportive of self-organizing teams. But leading agile organizations requires more. There are specific activities that help build agile organizations that can weather business turbulence. This session will explore those activities that an agile leader or executive must “do,” including: revising performance measurements; facilitating self-organizing teams; developing strategies for operational, portfolio, and strategic agility; and assessing how agile to be source Agile 2010 Program
After the sessions, I sat in the lobby of the conference and read some of the blog feeds I subscribe to and came across these…
In many organizations and depending on their level, people managers are expected to plan, direct, organize and control (Deming‘s Plan-Do-Check-Act) – more specifically, the role of the manager is to:
Define the individual objectives
Assign work to team members
Determine priorities of the tasks
Monitor progress of the activities
Make decisions for the team
Get visibility into the work of the team
Mentor and train employees
Protect the team’s financial and human resources
Provide career development opportunities
Build relationships with other departments and teams
Motivate the team members
Communicate information
What self-organization removes from the equation
Once the concept of self-organized team is implemented, there are a few things that were traditionally the responsibility of the people manager that now fall on the team. The activities are:
Assigning work – team members now select their tasks instead of the manager
Determine priorities – team members now determine the order in which they should to complete their work
Monitor progress – team members track their own progress and make it visible and accessible to those who need to know
Make decision for the team – within the team, team members get to make their decisions
Get visibility into the work – team members track their own progress and make it visible and accessible to those who need to know
Mentor and train employees – when possible, team members may decide to implement a mentoring program within the team
Motivate – self-organized individuals are known to be more motivated than traditional teams, hence the reduced need for the people manager to retain this activity
So what is left for the people manager?
In order for the people managers to transform into Agile leaders and feel as part of the team, we already stated they need to modify their role. The agile manager will achieve higher level of performance and possibly increased personal job satisfaction by macro-managing – working with an increased perspective as opposed to getting into the details. As such, the activities the agile managers need to retain are to:
Define high level objectives for their team and department instead of focusing on the tasks
Determine priorities in the objectives of the team and department instead of the activities
Build relationships with other departments and teams
I realize that this type of transition is easier said than done but with the willingness to recapture an important role as part of the team and with some external help, the traditional managers don’t have to became extinct professionals.
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.
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.
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.
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”
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?)
Perhaps, but not necessarily. Pilot projects are commonly done for two reasons: To see if something will work or to learn how to make it work. By now, enough other companies—very likely including some of your competitors—are using agile approaches like Scrum that there is no longer any question of if it works. The real question most organizations face is how to make agile or Scrum work for them. One or more pilot projects can be very helpful in providing those answers. (Transitioning to Agile)
Organizational Impact of an Agile Transition
When development teams adopt agile practices, product management is often caught off guard by the amount of work added to their already overflowing plate. Agile calls for new product management skills and traditional staffing models do not typically accommodate the new product owner role. Given that most product managers are already overworked, how can they manage these new activities to derive more value from software projects and products? (InfoQ: How Product Management Must Change to Enable the Agile Enterprise)
Agile methodologies are helping software organizations stay competitive by delivering products more frequently and with significantly higher quality. Making the switch to agile development also challenges traditional notions of project management, introducing new ways of managing time, cost and scope. Learn how to successfully manage agile projects with the resources below. (Agile White Paper: The Agile Project Manager | VersionOne)
When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of “manager” seems to be missing entirely. “Well I guess we’ll have to just get rid of ‘em all!” wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats. (Scrum Alliance -Manager 2.0: The Role of the Manager in Scrum)
About Agile Coaching
Agile methodologies introduce a newer role, typically called the “Agile Coach” that traditional methodologies will not focus on, or even mention. For those who have been working in an agile way for some time, it may seem like a natural complement, yet for those newer to this way of working it raises many questions like, “What’s so important about an Agile Coach: What’s wrong with a Line Manager, or a Team or Technical Lead: Why does Monster.com list 54 positions with this title:” (InfoQ: The Agile Coach, from A to Z)
Market Trends
Gartner’s analysts (Thomas Murphy and David Norton) predict that by 2012 “agile development methods will be utilized in 80% of all software development projects”. The authors explain that although Scrum will continue gaining in popularity over the coming years, organizations will not be successful in their transition unless they move toward a team-focused culture (Gartner Predicts 2010: Agile and Cloud Impact Application Development Directions | Analytical-Mind)
In their recently released study “Agile Development: Mainstream Adoption Has Changed Agility“, Forrester reports that “35% of respondents stated that Agile most closely reflects their development process”. The report is based on Forrester’s/Dr. Dobbs Global Developer Technographics Survey, Q3, 2009, which surveyed 1298 application development professionals. (Forrester Reports “Agile Development: Mainstream Adoption Has Changed Agility” | Analytical-Mind)
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
They can extinguish intrinsic motivation
The can diminish performance
The can crush creativity
They can crowd out good behavior
They can encourage cheating, shortcuts, and unethical behavior
The can become addictive
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.
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.
This blog discusses new leadership paradigms and innovative organizational structures with the intend of improving teams' performance and people's quality of life at the office.
In September 2009, I decided that for the next year, I would concentrate on three goals: Reading (12 books) Blogging (40 posts) Coding (4 projects) What did I learn about setting objectives? What do I need to improve? These questions will be answered in a few moments… and if you care you might even hear […]
There’s a misunderstanding I’ve noticed in quite a few Scrum projects. Teams use Scrum and at the end of their sprint they do what they call a “sprint demo”. It works out like this: They demonstrate their increment of the prod... […]
Imagine my surprise when a candidate for an agile organizational coach role within our organization shared with me his perspective on this topic. “Can you share with me your reasoning?”, I asked him intrigued. The candidate went on to explain that people need direction and that people cannot self-organized without clear objectives and direction. Indeed, [... […]
Scrum n’imposant rien sur le plan technique, une dérive couramment constatée est un manque de rigueur par rapport aux pratiques d’ingénieries utilisées par les équipes de développement. Par exemple, l’omission de tests automatisés lors de l’évolution de projets informatiques rend généralement de plus en plus difficile l’atteinte de l’objectif de […]
Written in collaboration with Carl Létourneau What’s the problem? Creating software without bugs is hard. Many developers are used to unit test their models. Controllers are also relatively simple to test in many frameworks. Tests often hurt when it comes to Views – many frameworks make it hard, or developers might think it is. Sometimes we just […]
This week, the first dry-run of the Professional Scrum Developer for Java course was given at Pyxis. For this occasion, 6 Pyxissians were on-site for 5 training days. Here is a sample of the many things we have learned. One of the fundamental aspects that was covered was producing a proper “definition of done”(D.O.D). For most of […]
Since I discovered Haml for my HTML templates in Rails, I stopped using ERB. Haml is more intuitive and readable to me. I am rediscovering ERB though for something else completely – Java code generation. There is a lot of boilerplate code in most Java projects. A good IDE can help you alleviate some of […]
I bumped into Steven last week. Steven is director of application development in a large organization and like most manager in his early forty’s, he looked tired and although he is usually a happy individual, his smile wasn’t radiant this time. In agreement with his teams, Steven initiated an Agile transition a few months ago. I [...] You might be interested […]
Now that the vacations are over and that the 2010 Agile conference has come and gone, Team Urban Turtle is back to work, cooking up another promising release 3.4. With the release of the Scrum template from Microsoft came a Removed state, making it necessary to propose a recycle bin feature to our […]
