Agile Project and Portfolio Management for Business Projects

Traditionally Agile is recognized as a software development-specific set of methodologies. The Agile Manifesto, the document that defines the pillars of the Agile movement, seems to inexorably link it to software teams. But is Agile so specific to software? Can those principles be applied to a wider range of initiatives? What if the “working software” wording is rephrased as “tangible value”?

1. Some problems Agile promises to solve:

• Things don’t seem to finish as there are too many threads in parallel. Lack of visibility, streams of emails to ask for basic questions and a general feeling of insecurity and lack of progress.

• “Business as usual” – process work, role based, without a clear understanding of the final objectives. Not much motivation. Fixed roles, "not my job".

• Hard to squeeze in change initiatives due to pre-approved budgets and plans.

2. Paradigm shift:

Everything we do is a due to a change we want to see in the system.  Thus a clear, time-bound and resource-bound, measurable result is desirable.  Ideally, everything should be transparent and people commit in group to the goals. It is OK to change roles, as people that learn new skills and extend their responsibilities are more motivated, reliable and happy. Thus we can approximate that everything we do is either a project or part of a project which we plan and we allocate resources to. All these initiatives form a portfolio that needs to be managed. As objectives shift in time, everything becomes subject to challenge, discussion, and prioritization and, of course, cancellation.

Hierarchical backlog in which we link all projects to strategic objectives and areas of responsibility.

(Suggested first step: write down business goals as a hierarchical structure, with areas and owners. Each project is then linked to a specific goal. By default, the area owner becomes either the default project manager or the portfolio manager for his group of projects. In the picture above, we used Jira with the Structure plugin to organize the information.)

3. Crossing the bridges:

Agile distilled:

A set of principles on how to respond to change and maximize value creation.

Agile manifesto for non-software related projects: 

"We are uncovering better ways of developing software delivering value by doing it and helping others do it. Through this work we have come to value:

o Individuals and interactions over processes and tools

o Working software  Maximizing value over comprehensive documentation

o Customer collaboration over contract negotiation

o Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."

Agile Methodologies Distilled: 

Practices to support the values. If values make sense and you implement practices that support them, you are already Agile. Is there anything inherently contradictory to managing in an Agile way any type of activity or task? 

What Agile is not:

• A software-development only methodology that is completely opposite to the traditional way of managing projects. 
• For kids, youngsters and pet projects.
• For unconventional start-ups only.
• Something new that has not passed the trial of time.

And, of course, the set of associated myths: 

• Agile practitioners do not plan. 
• Agile does not offer any guarantee nor commitment to results.
• Agile can only be done with a physical board, post-its, endless meetings and a significant dose of nonconformist.  
• To be Agile requires for everything to be changed.

All in one paragraph:

Agile is a philosophy, a set of lenses through which we see the world. The supporting practices feel natural and safe in most of the environments, but they do require a certain dose of sustained caring for people and discipline to implement them.

3. Agile Simple Portfolio Management for non-software teams.  

Scrap the “sprint, Agile, scrum, epics, feature, and retrospectives” terminology.  They might scare people away. Use the common human language, explain as if for a friend. Then just do it: call the meetings, follow the process, plan, ask the questions.

Jira Agile Project Board

(Suggested second step: together with the owner, define and agree on a backlog of projects that would help fulfill the business goals. There's no need to plan everything upfront. Rough estimations are enough, just to understand the business value, align on vision and on cost. Minimize the amount of project in progress. Re-discuss value and re-prioritize every iteration.)

Ok for planning, monitor and control, but why the continuous improvement? 

There is a common misunderstanding with S.M.A.R.T - The Achievable. How do I know that if I receive a business goal of "increasing the business value by 15%", the 15% is: a) realistic goal and b) the best that can be done. 

Let’s introduce continuous objectives and continuous improvement. It is OK to start with the worst process in the whole world. It is not OK not to improve everyday. When '"New Balance" built their first sport shoe in US to compete with the Chinese-made Adidas and Nike, they first built the most expensive sport shoe in the world. Then they improved. Now they are competitive. The question is: how can we improve, no matter how good we perceive ourselves to be. Compete with ourselves, not with the objective. 

For continuous improvement, we need data: track performance with charts, flows, timing. Get numbers. Agile metrics are there to follow and spark continuous improvement and retrospectives. Everything that is done goes through the process, otherwise you cannot get the full picture.

Jira Personal Taskboard

(Suggested third step: once a project is set to WIP, work with its team to break it down into tasks. Check that the tasks indeed conform to the vision and that the vision was properly understood by the team members. Follow-up. Build up on their vision as well. )

4. But how do I get control and confidence?

• I want my Gantt chart - yes, here it is: the road-map
• I want my project status reports - yes, here they are, the project metrics
• I want my change requests - of course, let's prioritize for the next iteration.

Jira-provided burn-up chart

(Suggested fourth step: Follow-up the metrics and hold retrospectives. Present the metrics to the team (hold the mirror) and check how people are satisfied with the results of their own work. Brainstorm for how results can be improved - there are specific Agile practices for this).

5. Additional notes:

Jira is a great tool for several reasons:

• With the help of the Agile plugin, it is very easy to understand how Agile works. 

• As it is a flexible workflow-based tool, it can be extended much beyond the task / defect / project tracking. We have defined custom workflows and use the same plugins for repetitive business processes, like travel, recruitment and purchases. It comes very handy as it is a one-stop point for almost everything we do, decreasing email communication and providing visibility and tracking for almost every activity.

• Although slightly difficult to customize for a fist time user, there is a lot of documentation out there, forums and people whom can be asked for support.

HAPPY MANAGING! :)