Agility and Project Leadership

Having been involved with large infrastructure projects, both in IT and construction, it is almost always the goal to get vendors to settle on a fixed priced contracts.  The advantage of using this type of contract is the reduced level of work required by the buyer to manage the contract. The buyer will know the price being charged and the incentive lies with the seller to control costs. 

The two things to closely monitor is to ensure the work outlined in the SOW is actually being completed per the contract and the other is control change requests, which are typically negotiated away by the vendor to secure the contract but used to get back the profits lost due to it.  I have personally been involved with projects that had out of control change requests that resulted in projects being way over budget and delayed.  Though I don't have the statistics on hand, I'm certain many of the major project failures were due to the inability to manage changes in fixed price contracts, especially in the government sector.

Agile/Scrum does not have much literature on integrating procurement management with Agile/Scrum since most of these kinds of projects are done with co-located, in-house teams, though I did find this post from Jeff Sutherland that outlines a "money for nothing" approach, which is a hybrid fix price contract that includes time and materials for changes.  Here's a summary:

• Insert Money for Nothing clause in fixed price contract.
  • Only operational if customer follows Scrum rules
  • Mutually agreed estimates for all work items
  • Otherwise contract reverts to time and materials
• Customer determines ROI cutoff where implementation of the next feature costs more than the value of the feature
• Supplier allows termination of contract at any time for 20% of remaining contract value
• Supplier assumes risk of late delivery of mutually agreed deliverables

I've only previewed the presentation by Jeff Sutherland and plan to review it in depth, but some issues that come to mind for me immediately is to ensure the stakeholders understand that this is fixed in price, but not in price and scope and that changes can be added giving them flexibility, but to do so requires the removal of other features.  Another is the involvement of the Product Owner, since he/she is the one who works with the customer to obtain requirements that will add business value for the customer.  That person will have to buy off and fully understand the impacts of this approach to make it successful.

Have any of you out there adopted a similar approach?  I'd be very interested to know!

An article in the July 2011 issue of the Harvard Business Review, discuss the idea that we are embarking to an "Age of Hyperspecialization".  Here's a video interview with one of the authors Tom Malone:

In a nutshell, due to communication technologies and increasing reliance on knowledge based work, we are entering into an age where "much of the prosperity our world now enjoys comes from the productivity gains of dividing work into ever smaller tasks performed by ever more specialized workers... We are entering an era of hyperspecialization—a very different, and not yet widely understood, world of work".

You can read the article for the details, but the result of this article was highly polarized comments from readers on the HBR site as to the dehumanizing and repetitive drudgery of micro segmented tasks done by dispersed teams all around the world, with the added insult of having to complete with these individuals on price.

The authors do acknowledge the dangers of this trend and the abuses that could result.  I can't help but to mostly agree that this type of work will become more prevalent as the technologies that allow hyper-connectivity get better and better.  As the authors acknowledge, the best way to survive and thrive in this new work world will be to sell your hyperspeciaized skills as a portfolio of skills and to diversify your areas of expertise so that you are better equiped to adjust to market conditions.

The biggest impacts and implications of this movement would be the project managers who are tasked with tracking and putting together and delivering all these micro tasks into a workable, integrated solution.

This will force project managers to master a new set of skills (Some of these discussed in the article/video with additions and focus on PM): 

1. Rethink scope and requirements design
2. Divide work into assignable micro tasks (a WBS on steroids!)
3. Recruit and assign specialized workers to perform them
4. Have a hyper-connected, social media like communication plan
5. Control for acceptable quality
6. Integrating the many pieces into a whole solution

With our increasing need for adaptability and agility, this will require an agile mega-generalist project manager or Super-ScrumMaster.  This person will have to manage globally dispersed, self-organizing teams (they would have to be self organizing as it would be impossible to track and understand all those hyper-specialized tasks!), manage and maintain real-time, twitter like status updates and meetings throughout global time zones, then ensure all those micro pieces get put back together into a workable deliverable.  Iterations would have to be micro time boxed sprints (events and changes in this situation could be in the seconds).

If this scenario sounds unreal and maybe even comical, consider how much our world has changed in just the last decade in terms of the explosion of information and communication options brought about by technology and the accelerated changes that will take place in the coming years and the scenario is not all that unrealistic.

My feeling though is people who can truly be the agile mega-generalist project managers as outlined above, will be the leaders of this age. 

In a previous post, I wrote a brief book review of "The Software Project Manager's Bridge to Agility" by Michelle Slinger and Stacia Broderick, which I felt was an excellent guide for the traditional software PM who needs to get up to speed with Agile/Scrum.  Another book I am getting acquainted with is the book by Robert K. Wysocki titled "Adaptive Project Framework: Managing Complexity in the Face of Uncertainty", that is another excellent book that can be used to bridge traditional process oriented PM practices with Agile ones.

In this book, Wysocki uses an analogy that differentiates between the cook, whose skill lies in following a recipe accurately and consistently, with a chef, who has the experience and skills to create new recipes for each dish and to improvise within existing recipes based on the circumstances at hand.  This is to distinguish a traditional PM who follows a PMO driven process and obtain success if the project is well defined and the solution understood.  Adaptive PMs, according to Wysocki, would thrive in situations where the project goals are partially or not specified and typically evolve as the project progresses and where the solution is speculative.

I'll take the analogy further and assert that APF as outlined and described in the book is really for chief chefs, such as PMO directors/leads and or Agile coaches to adopt, customize and implement the framework for their department or organization.  This is especially for organizations who have a traditional waterfall like methodology in place, but have found a need to incorporate more Agile practices.

Wysocki has written some in depth articles on Gantthead to describe the APF framework before the book was published, which has not changed much since the publication of the book and I recommend checking them out.

Though Wysocki's book is dense and academic, it does provide a sound theoretical framework for those who are in charge of managing and leading a company's traditional, prescriptive PM process and/or methodology to integrate Agile practices into them.

In summary, for those whom this book and "The Software Project Manager's Bridge to Agility" by Slinger and Broderick are targeted, namely those who wish to adopt and integrate Agile practices into their traditional process oriented one, these two books will work as book ends:  The APF by Wysocki is for those who are tasked with implementing Agile in a top down, across the PMO fashion, whereas the Slinger and Broderick book is for the PM who desires to integrate Agile into their traditional process bottom up on an actual project they are managing.

I highly recommend these books!

I've come accross some items recently, that seem to indicate an adoption or recognition of Scrum beyond software development and to general business management practices.  Below is a webcast for a Scrum conference with Jeff Sutherland speaking about how he discovered Scrum:

He mentions the discovery though a paper written by Hirotaka Takeuchi and Ikujiro Nonaka that I wrote an article for on this site.  But more interestingly is the initiative he mentions by Harvard Business School to include a cirriculum to teach Scrum to MBA students.

This is not surprising given the ridiculously fast pace of the information technology industry for which Scrum is applied and had its origins in.  But given the heavy reliance on these technological innovations (think of recent trends such as mobile, social media, cloud computing, etc.) by organizations all over the globe, their pace of acquiring and losing marketshare, churing out new products and keeping up with customer expectations has been just as brisk.

So it is no surprise that I also found this Forbes article by a well know business author Steve Denning, who writes about his discovery of Scrum when asking the question of how to combine rapid innovation with disciplined execution:

At the time, I was working on a book focused on resolving an old management conundrum: how do you combine rapid innovation with disciplined execution? I was proceeding by asking people if they knew about any such workplaces where this was already happening.

I surprised to find that an unusually high proportion of the workplaces that I heard about were in software development. Initially I didn’t pay it any attention. After all, these were geeks, and they talked in a strange, barely comprehensible vocabulary. What could I possibly learn about management from people who had, I imagined, gone into computing because they preferred machines to people?

A colleague, Hans Samios, a manager at Intergraph Corporation in Alabama, contacted me and suggested that I check out what was happening in software development firms, under the names of Agile and in particular, the practices known as Scrum. I had never heard of Scrum, but I decided to check it out.

He gives a brief overview and talks about the well known failures of Scrum (which is typically due to not having a deep understanding of the organizational culture change needed and the very human oriented nature of this process) and mentions the turnaround and 41% sustained growth by SalesForce.com after adopting and implementing Scrum.

These developments are interesting and show that the techniques and best practices within IT project management are starting to get recognition with the wider business audience that it deserves.

The official Scrum guide has been updated this month, and as site's page states,  " represents the official Scrum Body Of Knowledge, (that) was written by Ken Schwaber and Jeff Sutherland, co-creators of Scrum".  In other words, this is Scrum's equivalent of the PMBOK of the PMI.

At 17 pages, it is 30 times smaller than the PMBOK, but no less richer in it's method of project delivery.  Here's some of the major changes to the guide as outlined the co-founders Jeff Sutherland and Ken Schwaber:

• The team working on an increment is the Development Team (All team members will be known as Developers regardless of their roles)
• The Development Team does not commit to completing the work planned during a Sprint planning meeting
• Scrum does not mandate a burndown chart to monitor progress, but these two progress metrics should be updated
  • Remaining work for a Sprint that is summed and updated on a daily basis
  • Trending toward completing the work of the Sprint is maintained throughout the Sprint
• Release planning is not a requirement of Scrum
• The Sprint Backlog is the Product Backlog items selected for a Sprint.
• The Product Backlog is "ordered", instead of "prioritized"

The core of Scrum did not seem to change at all, but rather some finer points were clarified.  But much like the PMBOK, it is a body of knowledge or best practices that is left up to the practitioner to implement.  For those doing Scrum it's a must to review in detail.