Models of a Project Manager role in an agile project

The roles a project manager can play in an agile project are endless and a lot depends on where one’s interest lies and also the type of project one is working on. Again not all of these roles are applicable to all agile projects.

Here are a few possible options

The Iteration Manager

This is the most hands on delivery role one can do as a project manager on a team. The work largely involves planning iterations, resolving blockers from the daily stand-up, ensuring a smooth passage of stories across the story wall.

It requires working closely with all roles within the team and understanding the core practices of writing a user story to the essence of continuous integration

Program/Project Manager working with Iteration Manager(s)

If a project demands a larger team, with multiple parallel work streams, one might need an Iteration Manager for every decent sized (3-4 developer pairs) work stream and an overall project manager looking at work across teams. Depending on how large the project is the role is often termed as a “program” manager.

The work involves managing functional and technical dependencies across work streams during upfront release planning also during regular iterations . It also means providing an overall program status to senior stakeholders with the necessary abstraction of details.

Release Manager 

If it is a large enough project which is making multiple releases into production, there could be a need for a full time release manager role. Work here would involve planning upcoming releases and tracking stories and defect fixes are merged across different branches. It also requires a decent understanding of the techniques and tools such as continuous integration, version control systems, branching strategies etc.… to engage in an effective dialogue with senior developers on the team.

Project Manager working with a vendor PM counter part

If a lot of work is done by vendors either outsourced or co-sourced, there could be a need for a client project manager who can work across with all the vendor PM counterparts. Typical work of a client project manager involves resolving issues in the project dependent on decisions from stakeholders within the client organization. This could mean things as trivial as getting environments setup by the client IT team, to as complex as escalating critical issues about the product delivery to senior stakeholders from the business

The vendor PM(s) here acts as a project/iteration manager working closely with the client project manager every iteration.

Client Account Manager

A client account manager can become a full time role for a vendor executing a big project for a client. Major part of the work involves managing the ongoing client relationship by being part of key conversations with the senior client stakeholders, project sponsors etc.…  Work also includes billing and invoicing the client for the services offered.

A client account manager with a strong de livery background can assist a lot in having difficult conversations with a client when there are delivery issues within the project.

The challenging setup of an offshore project

After managing a few agile projects from India and learning the tricks of the trade, I have been wondering why life is much easier when you are working closely with the client as compared to working offshore. What worried me more was that I had to learn and use a lot more of project management techniques (making trade offs , managing risks etc..) from offshore, but what mattered while at a local client was building relationships and managing client expectations.

The answer to that is partly the challenging setup of an offshore project. Here are some of the odds one needs to battle with up front while delivering from offshore.

Budget is a critical constraint

There are no 2 ways about this. Clients try offshore when they are constrained by the cost of the project. And with that, among all the variables a project manager can play with, cost becomes a constant.

This means that if you made a release plan with certain velocity assumptions initially which do not come good in the first few iterations, you cannot increase your team size easily (given enough work could be done in parallel) as the client will not be happy with the increase in cost.

A burning business backlog to be delivered

It is quite natural for client to have their own IT teams build the necessary software required to run their business. The in house IT team guarantees close collaboration with the business. All is well until the in house team cannot deliver which is when the business backlog of features starts growing, and the business slowly starts losing trust of their IT team. This is typically when an offshore vendor is called for to help the IT team climb the mountain of business backlog they have built up by not delivering consistently.

When you look at this from offshore, you are looking at a scope full of must have features which if not delivered in the next few months, will almost kill the business. Negotiating on such a backlog is never an easy conversation with the business people.

Negotiating is difficult from miles away

What makes negotiation worse is the fact that the offshore team is sitting thousands of miles away from where the actual business is. Building rapport with senior client stakeholders can no more be done via hall way conversations or over a water cooler. If you even needed 5 minutes from a client to talk about the priority of a single defect, you cannot just walk over to his desk. All these become formal conference calls over phone or video conference.

Client IT teams end up micromanaging offshore vendors

There is nothing worse for a project than a backlog full of must haves, very minimal budget, lack of trust from the business and an IT vendor half way down the globe trying to deliver. Given such a scenario, it is natural for a client IT team to be more risk averse and to micro manage their IT vendors.

A slip in velocity is treated as a red alert with the need for a full time vendor project manager to provide explanations to their client IT counterpart.

Dev Box testing is a mindset shift for QAs

I never thought that this needed a blog entry of its own since this has been a common practice in all the Agile projects I have done in TW. But apparently it isn't so easy in other organizations.

A “Dev Box” is basically a developer machine on which active development happens. The idea of “Dev Box” testing is to get the QA on the team to do a quick sanity test of the story on a developer machine before the final checkin of the story is done and the developer moves the card to Development Complete or Ready for Test.

It is as informal as a developer pair shouting out to a QA on the team “Hey, we think we are done with the story, can you do a quick round of Dev Box testing before we call it dev complete ? “ and the QA coming over to the dev pair station and doing a quick test. This usually takes no more than 15 mins.

Even though this sounds very basic, it has the following advantages

* Reduces the wait time to find defects as the QA need not wait for a build to be churned out and deployed on an environment, hence providing quick feedback to the developers.

* It provides more insight for the developers to look at how a QA is testing the application and vice versa.

* It also aligns developers and QAs towards building a much better quality product by having quality discussions much earlier in the cycle with a tangible story at hand. Sometimes the QA might have useful inputs in how a widget plays on the web page and it might be just a quick fix enhancement which the developers can jump on to during the testing session itself.

Apparently this is not quite easy as it sounds in organizations where cross functional teams are not a common practice. I have worked for clients who have a separate quality assurance department they report to and the QAs refuse to test on a developer machine as the policies do not allow them to do so, even though personally they agree with the benefits of cutting down the feedback loop.

Another client I was talking to remarked that QAs in their organization were actually driven by wanting to log a huge number of defects in their defect tracking system and not by actually wanting to deliver a quality product. This was to an extent that their yearly appraisals were affected party by what was logged in the defect tracking system as their managers will only look at those reports.

By having a QA as an integral part of the development team and adopting practices like Dev Box testing , the team goes through a mindset shift after which everyone is focussed on one goal, which is to deliver business value by building a quality product.

Release plan checklist

When I build release plans, or even look at release plans of other projects, I end up running through a checklist of things in my mind, to determine if it is good enough. If you are an Agile PM trying to build a plan, this could be useful for you.

Iterations	Is the length of the iteration enough to be able to complete a medium size story within it ? Do the number of iterations fit well within the acceptable timeline ? Can we assume a production quality build after every iteration ?
Estimation	Are the stories sized relatively ? Does the team understand the estimation unit across all roles ?
Velocity	Is the planned velocity, the average velocity of last 3 iterations ? If its a new project, are we planning based on a raw velocity exercise ? Are team members across roles in planning the velocity ?
Resource ramp up	Is there time  factored in  for new people to ramp up on the team ?
Ordering of stories	Are the stories ordered around the critical path functionality ? (Always remember the critical path determines the schedule) Are the higher priority stories slotted for earlier iterations ? Are the stories ordered so that they meet any functional or technical dependencies?
Negotiable Scope	Are there some “nice to have” stories in the plan which can be later negotiated if need be to bring the project on track ?
Spikes / Proof of Concepts	For technical unknowns, are there spike stories which allow the team to explore technical solutions ?
Non functional requirements	Is there clarity on requirements for Performance, Security, Scalability and how they are going to be addressed ?
Functional Automation	Will developers do functional automation as a part of a story or this will be done as a part of QA ?
Regression/Stabilization	Is there a need for a separate regression/stabilization iteration once the development is complete ?
User Acceptance Testing	How much time is required to UAT the set of stories the team will deliver ?
Risks	Does the team understand how much risk is there in the plan ? Are these risks shared with the customer ?

Track all development work as story cards

Managers new to agile teams are often in a dilemma about what work should be written on a Story Card and what should be tracked in your favourite project management tool. Since the smallest unit of work is widely known as a User Story, people often are confused how to track all other work that the team has to do.

In short, all development work done by the team should be written on Story Cards (as above). Majority of these will be User Stories but there can also be several other categories such as

• Infrastructure/Technical Stories – Tasks such as setting up continuous integration environments, developer machines etc…
• Spikes – Proof of concepts / Prototypes
• Performance Stories – Stories involving performance testing / tuning etc…
• Technical Debt – project’s technical debt.

If you are using an Agile project management tool (Eg: Mingle, Greenhopper etc…) it should allow you to create different card types and set workflows based on them.

The important aspect is that every bit of work which is done by a development team should be part of a card which is tracked.

All above story types should be estimated, prioritized, planned and tracked in the same way as one does with user stories. The technical stories however need not be signed off by business stakeholders. It would be of more interest to a technical stakeholder within the project team to sign off such stories.