Agility and Project Leadership

Wikipedia defines a cult as "a new religious movement or other group whose beliefs or practices are considered abnormal or bizarre".  Images of Charles Manson or Jim Jones comes to mind with brainwashed individuals engaged in bizarre rituals and following their crazed leaders without question to murder or commit mass suicide.  So it may seem harsh for me to title this post as the "cult of Agile", but when I see blog post such as this one titled "Project Management: A Malady" or "Are Project Managers Living a Lie?" where in their over zealous efforts to promote Agile, they blast traditional project management, I can't help but to feel as though they are speaking as if from a cult.  As Tobian Mayer of Agile Anarchy posts:

This very interesting article from the NY Times talks about how and why the US lost out to China for the manufacturing of the iPhone.  Though most would think it is cost that drives companies like Apple to transfer their manufacturing overseas, the article points out that it was only one of several major factors:

It isn’t just that workers are cheaper abroad. Rather, Apple’s executives believe the vast scale of overseas factories as well as the flexibility, diligence and industrial skills of foreign workers have so outpaced their American counterparts that “Made in the U.S.A.” is no longer a viable option for most Apple products.

The article goes on to talk about the incredible Agility of Chinese companies like Foxconn in China, where "Apple’s executives had estimated that about 8,700 industrial engineers were needed to oversee and guide the 200,000 assembly-line workers eventually involved in manufacturing iPhones. The company’s analysts had forecast it would take as long as nine months to find that many qualified engineers in the United States... In China, it took 15 days".

Furthermore, companies in China have many skilled workers who have highly specialized technical skills that are above most manufacturing level labor, but not necessarily at the level of a formal engineering degree at the university that just cannot be matched in the US.  They are also able to mobilize them very quickly with no issue both for the employer and employee, for the most part, to work 12 hour shifts, 6 days a week.

We can dispute in this country whether that work level will be sustanable and if it's worth the loss of personal life with family and friends that will take its eventual toll, but in my opinion I have no doubt much of this comes down to people in countries like China who are just more hungrier for financial success than we are in the US and Europe.  Whether this is good or bad in itself is missing the point that China other countries are and will continue to outpace us in manufacturing which is a catalyst for creating middle class jobs.

What this entails for those of us in the project management field, is that as we all know, the world is getting flatter, faster and more projectized for as the article points out,

The pace of innovation, say executives from a variety of industries, has been quickened by businessmen like Mr. Jobs. G.M. went as long as half a decade between major automobile redesigns. Apple, by comparison, has released five iPhones in four years, doubling the devices’ speed and memory while dropping the price that some consumers pay.

Your now going to have to deal with whole industries in other countries that are more agile, flexible and speedier with respect to how they dispatch and deploy their workforce, engineer their business processes, and manage their portfolio of projects.

We are in for some interesting times indeed.

As part of my holiday ritual, I put aside a few books to read just for pleasure that I don't often get a chance to do when bombarded with my usual busy schedule of work and other commitments.  These books can be of any variety and often are not directly pertinent to project management or other business related topics.  But one book I did read was actually one of the most pertinent books on managing projects I've come across and was completely captivating and engaging to boot.  The book was titled "Endurance: Shackleton's Incredible Voyage" by Alfred Lansing:

One of this site's very esteemed blogger, Ty Kiisel,  wrote about it last year and very pertinently focused on the team collaboration and cooperation that pulled those men though such a treturous and perilous situation of survivial, that has to be one of the greatest, if not the greatest real life stories of survival ever told.

In August 1914, Shackleton and his crew set sail on the Endurance for the South Atlantic. In October 1915, still half a continent away from their objective, the ship was trapped, then crushed in the ice. Twelve hundred miles away from land, drifting on ice packs, Shackleton and his men survived the next five months on a diet of dogs, penguins and seals. When the ship eventually sank they were forced to escape by lifeboat. Shackleton then travelled another 850 miles in an open boat across the stormiest ocean in the world to reach help. Every single man got home safely. 

Though the story is known, Lansing's book grips you at every moment and just when you think Shackleton and his crew cleared one life ending disaster, another one crops up as they are constantly battling for their lives with decreasing odds of their survival.  The wind, the dampness, the bitter cold and the long months of darkness in the winter seem like more than any man should be able to stand. They slept in wet sleeping bags in sub-freezing temperature; ate unappetizing foods; and still managed to keep their hopes alive.

While reading the book, I had to constantly remind myself that this was not fiction but events that actually happned even when the situation and the ability of Shackleton and his crew to overcome them seemed even beyond what any fiction could come up with.

I leave it up to you to read this fantastic book for the rest of the harrowing, yet optimistic tale, but as I mentioned I came out of reading this book with some rather enlightening project management lessons in leadership, being agile, adaptive and flexible when faced with life critical situations, and knowing how to manage your teams and trust in them.

• Protecting your team - Schackleton exemplied the kind of leader who understand putting his team first. When he found his men wavering and surcoming to the elements, starving and near death, he pushed extremely hard when he had to, but also knew when to trust his team.  He also had the kind of emotional intelligence we talk about these days in that when he choose his crew, he looked deep into their pschology and charactersitics and situated them to ensure they would succeed with each other to survive. When one crew member responded best to flattery, for example, Shackleton flattered him. Another responded best when reminded of the legal agreement he had signed when becoming a crew member, and Shackleton underscored this agreement to him whenever necessary.
• Agile and adaptive tactics for maximum flexibility - Though we like to expouse how change is the new norm these days, in Shackleton's situation, unpredictable change was the absolute rule, not the exception and being agile and adaptive was a matter of life or death.  Once Shackleton realized that the Endurance was trapped in the ice, he resolved – and, despite his bitter disappointment, communicated matter-of-factly to his men – that their goal had changed from crossing Antarctica to wintering over on the ice.  Twice, he tries to trek toward the sea, his men dragging a supply-laden lifeboat across soft ice and snow. Twice, he abandons the effort after their progress falls far short of his estimates. Again and again, he sets a course that must be altered based on the change in situation - just as good leaders must do.
• Equality and cross-functionality of teams - Shackleton established a loose hierarchy among his men, which allowed them to draw strength not just from him but from one another. All of the men -- including the scientists who were part of the crew -- were expected to perform mundane chores as well as take over each other's tasks when the other was too weak or ill to do it.  Shackleton shared hardships with his men, even when his position might have allowed him not to do so.  For example, after telling his men that they needed to leave behind personal articles to lighten their load, he took out the Bible personally given to him by Queen Alexandra and placed it on the snow. Then he walked away.

And though Shackleton is not labeled a project manager, he exihibited all the characteristics of a modern project manager in that he had to secure, manage and track the funding and budget for the project to reach Antartica, secure and manage his team, define the scope and requirements needed to achive the project goals, we as well as execute and control his project.

Of course his project failed, but to get his men home safely, he led them across ice, sea and land with all the tools he could muster. This combination of a commitment to a larger purpose while utilizing flexible and imaginative methods to achieve a goal is increasingly important in our tumultuous times and is a skill us project managers and leaders could all learn from and use to ensure success in our project goals.

For anyone involved with Scrum and who got their ScrumMaster certification from Scrum Alliance may have noticed that the founders of Scrum, namely Ken Schwaber and Jeff Sutherland, no longer sit on the board of that organization.  Ken Schwaber has in fact gone off and created another organization and site at Scrum.org.  On that site, he goes on to elaborate on why he branched off:

An organization can either be mission driven or money driven. Not both. When I started the Scrum Alliance, our mission was to improve the profession of software development. That later became “to transform the world of work.” By 2007, I believe that the quest for money had made the mission secondary at Scrum Alliance. I failed to see the effects that my initiatives would have on the money-making of the Scrum Alliance and its members. If I had mapped the money-making activities of the Scrum Alliance to these initiatives, it would have been obvious to me that the community would resist them...

As I mentioned in a previous post on the adoption of Scrum outside software development and into general business practices, I ran into this article from the IEEE about a venture capital firm called OpenView Venture Partners, which is a division of OpenView labs that incubates and funds startup software companies.

According to the article, adopting Scrum throughout their business processes allowed the group to double their productivity, while working fewer hours.  Scrum is used as a best practice framework for their project consulting services, sales, marketing, finance and customer support for their portfolio of companies.

As illustrated in the Maxwell Curve, coined by Scott Maxwell who is a principal founder, assuming a team member can take on approximately 20 perfect hours a sprint, the starting velocity for a full work week starts at 80, with the equivalent focus factor of 50% utilization for a 40 hour work week.  Unplanned stories are tracked seprately.

Due to this, the team at OpenView realized that using perfect hours instead of story points implied that the measured velocity can only increase if:

1. The team removes impediments that increase the focus factor on the stories (spend less on overhead and more on value add tasks)
2. The team works more hours

Additionally, continuous improvements and impediment removal can decrease the amount of time spent on individual stories by shrinking the story size while simultaneously increasing the output of work with no increase in the Sprint's velocity.  As time goes on and more iterations are completed, productivity increases which creates a culture of working less hours and no weekends.

For venture capital firms, investors will typically drive startup companies to work harder and longer to get a quicker ROI on their investments which leads most companies to work well beyond the 40 hour work week.  Scott found that due to Scrum's intensity, the peak of production waned after 50 hours, so he insisted the teams to work at a sustainable pace and avoid night and weekend work.  But from his analysis, he did expect that the production of work would double.

According to the article, this focus on higher velocity in perfect hours with less actual hours worked, compelled the teams to remove obstacles, overhead and communication gaps and to increase story clarity so as to increase the number of perfect hours completed.  This allowed them to acheive double productivity of work while working less hours.

This is not to say that they did not experience challenges.  Some of the most notable where:

• Aggresively removing impediments without doing root cause analysis lead to extra work
• Some critical impendiments required reorganizing the company to resolve them
• Estimating in hours made it impossible to know actual velocity and to access process improvements
• Scrum just did not work for some individuals, as some people were so individualistic that Scrum killed their productivity causing the productivity of the team to diminish in tandem

Though I can't verify the truth of their claims to Scrum's productivity increases, I have witnessed similar increases in Scrum projects (or projects using Scrum/Agile-like techniques) I've lead or been involved with and this was when I had the kind of organizational and upper management support that OpenView had articulated in the article.  It is interesting to see that Scrum is being adopted outside software development and getting the kinds of productivity gains it is famous for.