Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Too often, we have read that people are an organization’s greatest asset. We have read that the success of the organization can be tied down directly to how motivated and focussed are the people working in it. It is repeated by the leaders in every organization every so often that it can now be considered a cliché. Despite the overuse, it is utterly true that people are indeed an organization’s biggest asset. It is therefore not surprising that the Agile Manifesto justifiably founds its philosophy on this assertion. Indeed, the success and failure of Agile in an organization can be tied to how well this particular principle is realized and implemented.
There are many angles to elaborate about this principle. I want to focus on how placing trust on people, instead of processes, is more helpful to the success of the organization.
Why is it said so?
.Practices, processes, and policies do not lead to success (as much as) people do.
Take any successful organization today, a big reason for its success are happy and committed employees. An employee who believes that the work he or she does on a daily basis makes a difference to consumers and also clearly knows what difference is made is much more likely to make a genuine contribution to the organization’s success than one who just “pushes the blocks from A to B” because that is his or her job.
Too often, companies believe that it is their streamlined processes, practices, protocols, strategies and policies that have contributed to its success. I would not dispute that but add that while they only contributed to the success, they definitely did not cause it. The primary cause was a bunch of people who were convinced of an opportunity, who were fired by the probability of a win, analyzed it and understood the risks, backed themselves up to deliver, worked as a team and delivered it – a.k.a committed employees.
.Tail wagging the dog does not make a happy dog
Continuing with the previous point, organizations that assert that it is the strength of their processes and policies that led it to success miss the point. Policies, processes, standards and other such procedural matters should be there to ease the work of the employees and not to control them. If such processes are not making the work more efficient they should be relooked at and adjusted. Otherwise, the dangerous result of such an environment would be demoralized employees.
I was once managing a project where we had to draw some international travel plans for the team. The process for arranging international travel was unknown since the entire team including me were new to this organization. It also was very complicated with checks and counter-checks, approvals and counter-approvals, and so on at every single step. If the intention of this process was to reduce international travel to absolutely needed cases then it was not working since most teams drew up plans for international travel anyway. For if the need for travel arose later in short notice it would be next to impossible to arrange for that in time. As a backup plan to this not-yet-fully-understood-travel-process I planned a series of video-conferences, the resources for which needed to be booked in advance. As suspected, the convoluted process was indeed eating into the travel plans and the eventual travel happened a month-and-a-half late. Thankfully, the backup plan worked. The video-conferences were so successful that all the objectives of travel were met in the conferences itself. Now when we tried to cancel the travel since its objectives were met it was quite difficult since the process for that was even more complicated. So the travel went along with new agendas in which we were able to cover new scope not part of the earlier plan. This was a case just with my project. A few other teams also did likewise in this program. So if one generalizes it a bit and takes a bigger picture it might be quite possible that the travel process actually added up costs rather than optimizing it to such an extent that some teams including mine marked the travel process itself as a risk!
Indeed, policies and processes add strength to an organization only when they enable it to adapt with changing realities swiftly. When they start becoming a tedious time-consuming bureaucracy it is the beginning of the organization’s convoluted journey to it’s end.
.Commitment is the present need, not compliance.
Contrast the above travel experience with another example where the process actually helped matters along.
The book Maverick, by Ricardo Semler, talks about how simplified processes in Semco actually made the organization more productive. Quoting from the book, the travel process was apparently simplified to this
Semco’s standard policy is no policy. Many companies have entire departments that generate mountains of paperwork trying to control their employees. Take travel. They have rules that govern how much a person can spend in every possible situation. At Semco, we want our people to spend whatever they think they should, as if they were taking the a trip on their own, with their own money. There’s no departments, no rules, no audits. If we’re afraid to let people decide in which section of the plane to sit, or how many stars their hotel shoud have, we shouldn’t be sending them abroad to do business in our name, should we?
We have absolute trust in our employees.
The book goes on to talk about how the processes and policies at Semco were radically simplified by trusting its employees more and more. On the question of how such radical policies impacted the business this is what Ricardo Semler has to say.
Semco has grown sixfold despite withering recession, staggering inflation and chaotic national economic policy. Productivity has increased nearly sevenfold. Profits have risen fivefold. And we have had periods of up to 14 months in which not one worker has left us.
Contrast this with another example of how mere compliance without commitment does no good. One of my friends was talking about his employer where there was a mandate from his managers that every piece of code written should be unit-tested. Clarifications on how to do it, why to do it and the priority of this in relation to other tasks were not specified but compliance was mandatory and a excel-based report template was provided in which test reports needed to be filled. Developers then proceeded to fill up justifications in the excel sheets how each method would be tested “in due course” of normal execution! And since the method would be covered during normal execution there was no need for a separate unit-test for that method! Apparently, no method-coverage or branch-coverage metrics were provided. A process made mandatory is of little use when the support structure to enable that process or validation structure to ensure its correctness is absent. If the need for unit testing, and the risk of not having it, was clearly explained to the team and their support was secured with relevant training, tools and support then a more committed team would have noticed the folly of excel-based unit testing and done it in a very different way.
Indeed, when one empowers one’s team and trusts it to deliver, complexity is better controlled and managed. A small team of committed individuals can do what an army of compliant individuals cannot.
.Management and leadership is still relevant, but not like earlier.
With all the talk on adopting Agile methods and delegating many execution responsibilities to the team there is a concern among the earlier managers as to what is the role of the manager now. A threat is perceived by the management when Agile adoption starts. However, it should be noted that the role of management and leadership is still relevant. Only not the same as earlier.
While the earlier management controlled what work was done and how the work was done an Agile management delegates almost all of the how part to the team. The challenge to the leadership and management is to set an exciting goal, motivate the team to reach the goal, get the team’s commitment, and help the team in every way to reach that goal. The team figures out how to reach the goal and gets to the goal.
How is this principle put in practice?
Scrum imbibes this principle right into every aspect of its framework. The Scrum Guide clearly states that the Scrum team should be “
self-organizing and cross-functional“. Almost every event in Scrum requires the participation of the whole Scrum team. Interactions with those outside the Scrum team is handled by the Product Owner and the Scrum Master leaving the Development Team undisturbed and focussed on reaching the goals set for that Sprint. Monitoring tools are also set in such a way that the Development team spends minimal time giving the relevant information for generating the monitoring dashboards and yet the management can get the information they need about progress of work.
XP makes the application of this principle quite explicit. First, it clearly mandates that the development team communicate directly and closely with the customer by preferably sitting at the customer location itself. Also, the rules, values, and practices also underline this principle by making one aware that a motivated team working on this self-reinforcing foundation has a good chance of creating high-quality useful software.
Lean software development has the principle “
Energise workers” which stresses on the importance of an energized and motivated team.
References used in this post
- 1. The Agile manifesto
- 2. The principles of Agile software development
- 3. A gentle introduction to extreme programming
- 4. Home of Poppendieck LLC, creators of Lean Software Development
- 5. Goodreads page of the book Maverick by Ricardo Semler