Joe Krebs discusses in this article why soft skills factors, honesty and integrity are not only essential among team members, but also for entire enterprises including their portfolios.
Many organizations transition to agile processes with high hopes and wishes. The motivations for these hopes and wishes are often expressed by senior executives as:
- Increasing Productivity.
- Faster Return of Investment (ROI).
- Releasing products sooner and more frequent.
- Improved Innovation.
These “hard” business benefits, which are measurable, go very well with the agile message. The strength of agile processes is however that they root in “soft” skills for example:
- Communicating and collaborating.
- Consensus and agreement building.
- Inspecting, reflecting and adapting.
The result of a true agile transformation are self-organized and empowered teams, who have the skills and capabilities to deliver better products faster. That means, organizations need to create a playing field for the teams so that soft skills can thrive and the promised hard business benefits become reality. Transformations purely motivated and dominated by hard business drivers might deliver some short term results, but none of them will create a healthy sustainable pace in the long run.
In this article, I would like to discuss why it is so important for a successful agile portfolio management that these hard benefits and agile soft skills need each other.
Before we get started, project portfolio management is about making investment (project) decisions; strategically and tactically. To support better decision-making, executives rely on the project metrics they receive. For example, should we stop or halt projects in favor of better ideas. In traditional (waterfall) projects, these metrics are about comparing phase completion with project schedules. When we stop waterfall projects early, we usually end-up with little to zero working software.
With agile projects, executives receive a very different project status, because metrics present a different meaning (for example velocity) and of course the demo at the end of each iteration shows that working software exists. Both systems have something in common; they are based on trust. While traditional projects predict what will happen based on plans, agile projects predict based on the accomplishments of the previous iterations. Agile teams compare small goals with achievements, inspect and adapt. That gives the team confidence in its own capabilities. Many organizations exposed the first time to agile processes enjoy how real and measurable project progress is when agile is done right.
Based on my experience in numerous agile enablement programs with customers over the past 10 years, I noticed a few changes when these programs are set-up. Initially many of them were driven by individuals (including me), who worked inside an agile team surrounded by a non-agile organization. These early agile projects were often experiments or just teams who got a chance by PMO’s and executives who believed that the team was on to something. Then when project success started to kick-in, the broader application of the agile process was not uncommon. Today’s programs however have much less to do with convincing executives about the business benefits, because so many companies across many industries had been successful. Executive buy-in is much more common these days and the question about introducing agile has shifted from “if” and “why” to “when” and “how”. It seems that agile is very likely to be “sold” top-down.
The larger however the organizations, the further away are usually the executive sponsors (the ones with the checkbook) from the actual agile delivery teams. But even with this model, the change which goes along with the agile practices needs to be communicated into every angle of the teams. No question, teams need