Traditional Project Management Role on a Scrum Project

A “good read” article on Agile Journal, An Agile PM Isn’t What You Think Sub-Head: Where Does Traditional Project Management Fit in an Agile Project Using Scrum

There is always considerable discussion about the role of the Traditional Project Manager on an Agile Scrum Project and this article describes it very well.

In the end, Scrum does not prescribe where the individual currently serving as project manager should go in a Scrum project, only with whom the project management responsibilities lie and, as such, organizations should not assume that project managers always belong in a particular Scrum role.

[Edit 16 Nov 2009]

In another article 10 things a PM needs to know about Agile, the authors go as far as stating

There is no PM role in Agile

Whilst there is no single person performing the role of a PM, the elements and responsibilities of the traditional PM are performed by all the people on an Agile team.

I thought the following statement is quite true

“but who is going to chase them up if they don’t get their work done on time!?” In reality, this is more a fear than a real risk.

Ultimately, organisations and management need to trust individuals and teams to do their work – that’s why they hired them in the first place.

Agile Australia 2009 Conference Report

I had the pleasure to attend Australia’s inaugural Agile Conference in Sydney supported by the Agile Alliance.  It was a 2 day event on 15-16 October.  Being the first Agile Conference in Australia, the key theme centered around Agile Adoption and how companies have adopted Agile; Why companies have adopted agile; and Issues and Challenges faced by companies in their adoption of Agile.

It was a very good conference with the ability to network and share ideas with other people during the breaks who are also working on their Agile adoption in their own companies.  I have taken some key messages from the conference to help with the Agile adoption initiatives I am working on within HP Enterprise Services.  I am already looking forward to next year’s event.

One of the more inspiring session I attended was the keynote on the 2nd day, Increasing Business value through simplicity (Lean and Agile) by Jeff Smith, CIO of Suncorp.  Jeff provided the Executive sponsorship and the vision for “Living Agile” as a way to infuse organisational simplicty into the DNA of Suncorp through the introduction of Agile and Lean principles and methodologies.  Any organisation would benefit having an Executive like Jeff to help drive their Agile adoption.  I highly recommend you watching this inspiring video!!

The other sessions I attended with some key summaries:


  • Panel – The journey towards the Agile enterprise; discussion on the Agile adoption journey by the respective panalist’s organisation.
    • The journey needs active executive support which permeates through the enterprise.
    • “Agile is about teams doing extraordinary things with ordinary people”.
  • 12 Agile Adoption failure modes (Keynote Day 1) by Jean Tabaka, Rally Software; based on her experience it outlines that Agile does not fail.  It is the Agile adoption mode that fails.  Organisations need to stop the denial that waterfall is really deliverying value. Most of the 12 points are quite common when adopting Agile (yes, I have experienced some of it):
  1. Checkbook commitment doesn’t support organisational change management.  Executives provide checkbook commitment to Agile without actually supporting the Agile adoption (unengaged).  Same metrics are used and it continues the illiusion that software development is very deterministic.
  2. Culture doesn’t support change.  Governance is Conformance; Standard of work is static; detailed documentation; PMO are enforcers.
  3. Do not have retrospectives.  Or they are done, but actions that are identified are ignored or there is no action.
  4. Infrastructure to support the team is ignored or inadequate and architecture becomes unstable.
  5. Lack of full planning participation.  If the right people are not part of the planning you will not get the right commitment.
  6. No or too many product owners.
  7. Bad Scrum Masters.  Scrum Masters that are Command and Control.
  8. Not having an onsite evangelist/coach at remote teams.
  9. Team lacking authority.  Empowered teams amplify learning.
  10. Testing not pulled forward.
  11. Traditional performance appraisals that reward individual heroics.
  12. Revert to old ways of doing things.  Change is hard.
  • What’s it take to make an Agile transition? by Shane Hastie, Software Education; focuses on the premise that Agile is a culture, not a methodology.  The talk examines the organisational, cultural and individual changes needed for a business to successfully embrace Agile.
  • Panel – Waterfall is from Mars, Agile is from Venus; panel discussion centered around bridging understanding and communication between Waterfall organisations and Agile teams.  I didn’t get too much out of this session.
  • Taking the Leap of Faith by Mike Allen; this was a good presentation that described the Agile journey that was used to deliver a large application transformation program.  It starts with hiring the right people, providing the right office environment (the organisation spent money to reorganise the office to be more collaborative), provide the proper training and use the right tools.   The Program started off as waterfall, but being a large program there was a lot inertia to get the program moving so Agile was introduced – Agile gets you moving.  You may move in the wrong direction, but that is ok.  Agile gets you back on course quickly.
  • Better Software Faster! by Michael Milewski; another presentation on how started the Agile adoption journey. It all started with a pilot project.
  • Bringing IT back from the brink by Nigel Dalton; discussion on how Lonely Planet’s IT department was not delivering and how it used Agile to transform their organisation and brought the IT department back from the brink.  Nigel introduced “Watergile” – when you dangerously mix waterfall with Agile – “it’ll drive you mad”.  It was interesting to hear how Agile is used in a non-IT context in their new guidebook product development.
  • Panel – Distributed Agile;  Distributed agile has challenges.  Expect more travel and travel costs, but this is is offset by the long term benefits it brings.  Despite the challenges, distributed Agile is better than waterfall for projects with changing requirements & uncertainty.  Distributed Agile means you need to pay more attention to the challenges, but the Agile practices itself will help improve the challenges.  e.g. through retrospectives.  Going distributed, 3 of the 4 Agile Manifesto values are compromised.

Day 2

  • Lean and Agile in the large – principles and experiences for large scale software development by Dave Thomas; this was a good presentation by Dave Thomas who was one of the authors of the Agile Manifesto and founding member of the Agile AllianceThis presentation is worth watching. One metaphor I liked:

    Successful software development is about a winning culture

    • Software is a team sport, & like team sports, practice, constructive peer feedback & coaching are essential.
    • Winning teams need to implicitly know the moves of each player, as well as the movements of the team as a whole.
    • The ultimate expression of process is a culture where building software is more like playing Jazz!!  People just do it!!!
  • Understanding just-in-time requirements to support Lean software development by Martin Kearns; content of this presentation is self-explanatory from the tile.  I didn’t get too much out of this that I didn’t already know.
  • Lean thinking for Lean times by Alan Beacham and Jason Yip;  discussed how Kanban is used to manage workflow in Agile projects.
  • The inter-sprint break by Simon Bristow; this presentation discussed the introduction of the inter-sprint break – a period between the end of the Scrum sprint and the beginning of the next.  This concept was very similar to a previous project I have worked on and I would recommend introducing such a concept.
  • Being Agile at the Google scale by Dhanji Prasanna; this was a very technical presentation with much of it not about Agile.  It was interesting to note that Google do not follow a specific agile method (eg. Scrum, XP, DSDM, etc).  Instead Google base the way they approach work on the Agile Manifesto value “Individuals and interactions over processes and tools”.  Google also has a fundamental prinicple: “Maximising the amount of work…..NOT done.  a.k.a. Simplicity.”
  • Agile mistakes and how to avoid them by Rown Bunning; was very similar to Jean Tabaka’s keynote on Day 1 where Rowan outlined some of the common mistakes in adopting Agile.  He presented the Agile Metaphor:  “Agile development is like teenage sex.  Only 10% who say they are doing it, are actually doing it.  And those who are actually doing it, are doing it wrong.”

Customers Should Be Part Of The Team

Source: Dilbert 21-Sep-2009

Dilbert cartoons are great because they poke humour in everyday working situations, and they wouldn’t be funny if they weren’t true.  Too many times have I seen project teams in the situation above, including ones I have worked on.

Customers should be made part of the team.  A goal in Agile is to have the customer collaborate with the team and a key role is the Product Owner.  Together the team and customer work out what is needed in the user story (requirement), what is required to start the user story and what are the acceptance criteria to pass.

Communication between the customer and team occurs throughout the project and feedback is provided by the customer to the team often.  By having the customer part of the team it helps the team maintain a state of productivity by remaining available to answer questions and further clarify acceptance criteria.  Because the team and the customer work together to discuss the user story, there are no misunderstandings and situations in the above cartoon should rarely occur.

How Pixar uses Agile like practices to make their movies

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?

Management’s Role on Agile Projects

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. 

IT is never 100 percent at fault for any massive project

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 [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 –

  1. Incomplete Requirements
  2. Lack of User Involvement
  3. Lack of Resources
  4. Unrealistic Expectations
  5. Lack of Executive Support
  6. Changing Requirements & Specifications
  7. Lack of Planning
  8. Didn’t Need It Any Longer
  9. Lack of IT Management
  10. 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.

Executive Support For Agile Adoption

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.

%d bloggers like this: