The Harvard Business Review has published an article on How Pixar Fosters Collective Creativity in making their movies. The link is only a summary to the full article (which is paid), but it does provide some insights on how Pixar approach their film making.
Building complex software systems is very different to making a blockbuster film, but one thing in common is the people behind it. The way Pixar approach their film making is very similar to Agile practices.
Pixar have cross functional teams – Pixar assembles cross-company teams and find people who’ll work effectively together.
Pixar incrementally build out the movie – Though it is incomplete, Pixar demonstrate the animation work daily to enable the team to communicate important points to the entire crew at once and get candid feedback.
Pixar has self-organising teams – They help the teams to solve issues and the teams are trusted to solve complex problems themselves. People are encourged to help each other produce their best work. Managers are not afraid to hear bad news and they do not micro-manage the team. It is interesting to note that the managers are
okay to walk into a meeting and be surprised.
Pixar is constantly learning and improving they way they work through retrospectives (they called it post-mortems).
Pixar asks post-mortem participants to list the top five things they’d do again and the top five things they wouldn’t do.
This way they can extract the most valuable lessons and constantly inspect and adapt the way they work.
Can you produce a blockbuster software system?
Mark Levison has written an excellent post on How Can Management Contribute to an Agile Project?
His post nicely complements my previous posts on a similar topic.
If you read my previous blog post on Executive Support For Agile Adoption, I described how management support is important.
This topic is tocuhed on in Thomas Wailgum’s recent article in the CIO.com [5 Aug 2009], After a Massive Tech Project Failure: What IT Can Expect. In his article he states –
IT is never 100 percent at fault for any massive project
Thomas’ statement is supported by the Chaos Report by The Standish Group whereby the top 10 reasons for project failures have nothing to do with Technology but more to do with business governance –
- Incomplete Requirements
- Lack of User Involvement
- Lack of Resources
- Unrealistic Expectations
- Lack of Executive Support
- Changing Requirements & Specifications
- Lack of Planning
- Didn’t Need It Any Longer
- Lack of IT Management
- Technology Illiteracy
Furthermore, the Chaos Report indicates that the three major reasons that a project will succeed are user involvement, executive management support, and a clear statement of requirements. There are other success criteria, but with these three elements in place, the chances of success are much greater.
Thomas’ article is not advocating agile (the word is only mentioned once). What is mentioned is a common theme – be pragmatic, provide common sense and be practical. Agile is pragmatic, common sense and practical. And the first step to adopting agile is to have an open mind to it. You can be skeptical about Agile, but remain open-minded.
CIOs who resist against changing implementation methods—holding firmly to the waterfall when agile is the best option—and killing projects and their careers
The advice for such massive undertakings, which CIOs and analysts talk up but many don’t follow, is practical: Think bite-sized project chunks and set proper expectations.
“For some reason,” he adds, “we haven’t learned as an IT industry about driving incremental planning and change, which, in my mind, would help to mitigate the high rises and high falls of project failures.”
Agile is about incremental planning and change. For example, Scrum is an Empirical Process Control whereby you exercise control through frequent inspection and adaptation. The idea is that you do some planning and then do what you planned, inspect what you did and then adapt your behaviour to improve on what you did. You are constantly going through cycles of learning and improving the way you work.
As part of this learning, we need to encourage our managers to –
embrace change and transparency—even if it hurts at first. “The corporate culture—the status quo—tends to be: ‘Everything’s good. We don’t talk about problems until they are near unrecoverable, because we know people don’t like bad news,'” ….. But there are always going to be problems—vendor issues, or architecture, compliance or performance problems.
Agile provides the framework to detect bad news early. However, as mentioned in my last blog entry “managers need the ability to hear unwelcome news and should it occur deal with this effectively” as IT is never 100 percent at fault.
Like any illness, the earlier the detection the better as a cure can be found and applied sooner. Leave it too late and the illness can be fatal and you inevitably end up doing the Death March.
One of the biggest failure to adopt Agile is not having the right mindshift change. This mindshift change can be quite signficant for some. Agile methodologies are a paradigm shift from tranditional “monumental” waterfall methodologies.
Managers and organisational leaders have a key role in helping adopting and transitioning to agile and this starts with the right mindshift change. Esther Derby’s article, The Three Pillars of Executive Support for Agile Adoption outlines what is needed to succeed from managers. What underpins the management support for agile adoption is managers having the right agile mindset.
It can be very difficult for managers to let go of Gantt charts, specific milestones and commitment dates they are accustomed to. No matter that few projects actually meet those targets, managers fear how much worse it would be if the targets and schedule (no matter how unrealistic) did not exist at all.
Ultimately, it will take time to change the mindset and opinion of managers who have dug into their positions over years of working with projects that miss deadlines, deliver low quality, systems that don’t meet customer’s needs, and throw up change control walls.
The 3 points in Ester’s article are not that uncommon.
1. The Power of “No”
How many times do we hear “we have always done it this way”? Manager’s need to demonstrate, subscribe to and commit to the agile practices, values and pinciples and this means not allowing people to fall back into old habits. This includes removing organisational impediments.
It’s predictable that when there’s a new method, process, or policy, people will request exceptions so they can continue to do things the old way.
There will be challenges in adopting any new methodology that you are not experienced with. Adopting agile is no different and will take some time. This is where an experienced agile coach may come in handy to guide the project along to successfully apply agile principles, values and practices.
2. Address Systemic Issues
Ester describes 3 systemic issues.
Three common patterns that I see driving exceptions are technical debt, overstuffing the pipe, and misaligned reward structures.
No methodology can fix these issues. These are management problems, and it takes management to fix them. Without management attention to systemic issues, you will achieve incremental improvements, at best.
Not fixing these systemic issues, Ester rightly points out that this “will sow cynicism in the organization”.
Consequently, agile will be seen as a failure when in fact the cause is nothing to do with the process or methodology used but the lack of management’s ability to address systemic issues.
3. The Ability to Hear Unwelcome News
In the agile community we believe in transparency and visibility. Within HP (and EDS), there is training which educates us to operate ethically and with integrity. To do this teams should be transparent with their management. Likewise, management will need to be transparent with the customer. And this helps build trust with the customer.
Status reports where it goes from green, green, green, green, and then suddenly red should not happen. With focus on working software in small releases, agile methods provide transparency of progress. However, managers will need to have “the ability to hear unwelcome news” should it occur and deal with this effectively.
The four value statments in the Agile Manifesto, shows perferences we should take. Managers have a key role to play when it comes to “Customer collaboration over contract negotiation”. Managers need to set realistic expecations with the customer. Unrealistic expectations lead to shortcuts, continuous fire fighting, accumulation of technical debt, and ultimately delaying the project more.
Management often resort to adding more resources to an already late project thinking more people-power will solve the problem. Ironically as Fred Brooke coined in the book The Mythical Man Month the term Brooke’s Law – “adding manpower to a late software project makes it later”. Instead, Ester encourages managers to —
Take management action. Have the difficult conversations and make the difficult choices to reduce scope or extend the date.
Agile methods don’t provide a silver bullet that guarantees success and requires a lot of management support.
Managment support for agile adoption is not just applying lip service and saying “we will adopt agile”, but demonstration of on-going support. Skills are important, but having the right agile mindset is more important.
A lot of agile is common sense but without the right mindset adoption can be difficult and fraught with danger.