MarkoPyhajarvi.Com -

Agile Project management is often connected with things such as

• daily stand-up meetings
• frequent communication
• self-organizing teams
• short iterations
• etc.

There are many ways to describe agile project management, but what it actually is? What agile project manager does in practice? Jim Highsmith (founder of Agile Alliance) has summarized nice principles for agile project manager.

1. Deliver something useful to the client
2. cultivate committed stakeholders
3. Employ a leadership-collaboration style
4. Build competent, collaborative teams
5. Enable team decision making
6. Use short timeboxed iterations to quickly deliver features
7. Encourage adaptability
8. Champion technical excellence
9. Focus on delivery activities, not process-compliance activities

Mr. Highsmith’s Nine principles for agile project manager pretty well describe what an agile project manager does in practice, but let’s take a closer look on each principle.

Deliver something useful to the client

As an agile project manager, your job is to provide value to customer. In order to do that, you need to understand what customer values. Some folks simplify this by stating “focus on coding, forget documentation”. Although in most cases customer values a functioning software, some customer actually value documentation. Focus on providing what customer values. If it is a functioning software, lead your team to create such instead of focusing on planning and documentation, for example.

Cultivate committed stakeholders

Are you frustrated with “lazy” stakeholders who only seem to focus on sending emails? If yes, cultivate them. Your job is to cultivate or activate stakeholders. Take them with you when planning your sprint, assign them tasks, require, ask and demand. Keep them alive and kicking! In most cases you just need to stand up, walk to the person, show what you need from him/her, set a deadline together, and follow up his/her progress.

Employ a leadership-collaboration style

Agile project managers don’t give orders. Instead they facilitate, coach, provide resources, maintain vision, promote agile principles, remove obstacles, keep skeptics away, etc. If you have never acted as an agile project manager, you might need some time and few projects to learn to your new role. Collaborative leadership differs much from traditional “leader-employee” style.

Build competent, collaborative teams

Agile project teams are self-organizing, and self-organizing teams require more from team members than a traditional “leader says what to do”-team. You need competent, active, adaptive and committed team members, and one of the best ways to get such a team is to continuously build the competence and collaboration of team members. There are many ways to do this. Anyhow, your goal is to have a team of very competent people who actively collaborate with each other and possible external stakeholders.

Enable team decision making

It might be surprising for many, but agile project managers don’t actually set rules and responsibilities and give orders. Instead the self-organizing team itself makes decisions within the boundaries set by the project manager. As a project manager your ob is to facilitate, coach, motivate and remove obstacles. Anyhow, I must say point out that this kind of set up does not usually exist, because of many reasons. One good reason is that many times project manager understands the agile world, but line management and team does not. In that kind of situation it is very difficult to create team based decision making, so some kind of “middle-level” solution could work better.

Use short timeboxed iterations to quickly deliver features

Scrum sprints are usually timeboxed to 2 weeks or 4 weeks, and in the end of a sprint product is delivered. Sprint length doesn’t always need to be the same, but the important point is to keep sprints or iterations truly timeboxed. This means no time schedule slippage. If team cannot get everything done, sprint or iteration scope can be changed, but time schedule not. Timeboxed approach forces to faster and more effective working, which again leads to shorter projects.

Encourage adaptability

Software development is always new product development (I’ll explain in later articles). Software development team sails in the sea of constant changes, while project manager stands behind the steering helm (or steering wheel). Software projects evolve, so don’t even try to fight against the nature of software projects. Instead encourage adaptability, which in practice means reactive planning, adapting to new and changing requirements, quick decision making, etc. Talk about the nature of software projects, and encourage people to adapt with changing environment.

Champion technical excellence

In most projects you need gurus who master certain technical skills, frameworks, tools, etc. Encourage people to use part of their time with learning, testing new techniques, collaborating and sharing their knowledge, planning their career as technical experts, etc. If you manage to create a positive and continues spiral of learning, you are sailing good waters.

Focus on delivery activities, not process-compliance activities

Have you seen MS Project charts that clearly follow company processes? If yes, have you ever seen MS Project charts that clearly follow company processes AND are always up to date? I have not. Therefore I strongly recommend focusing on delivery activities instead of maintaining your MS Project plan and trying to lead your team by giving tasks or work orders. Together with your team, sit down twice a week to brainstorm activities that are needed in order to deliver the product. Maintain those activities in your Scrum backlog and follow the progress daily. Ask your team, “is this all we need to do in order to deliver by the end of the sprint, or are there other activities that we haven’t recognized yet?“.