Agility and Project Leadership

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.

Change happens and is a fact of life for anyone involved in a project.  How a project manager deals with changes throughout a project determines whether a project succeeds or fails and this needs to be integrated throughout the lifecycle of the project.  According to the PMBOK 4th edition, integrated change control "is the process of reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents and the project management plan."

No doubt social media and all its technological manifestations is all the rage right now.  This "Facebook Effect" has now even permiated the project management field with its latest incarnation illustrated in the prominent Harvard Business Review blog titled "Better Project Staffing with Social Technology" which discusses a Facebook like system used internally at the consulting firm Booz Allen.  This application is called appropriately "Hello" and is used by consultants to know the availabilty of other consultants so as to have them work on projects.

The posting claims Hello's most important design feature: