Honestly Agile

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.
• Estimating.
• Facilitating.
• Inspecting, reflecting and adapting.
• Trusting

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 to know the hard benefits and the motivators, but they need to truly understand and trust that they are achieved through all agile practices. That does not happen overnight.

The message can’t be purely by “let’s build more features in less time” without giving the teams a commitment to full agile. That includes that several traditional project management activities are being delegated to the team (e.g. estimating and planning).

If an enterprise is looking at agile processes purely for delivering more product features in less time, will leave the team without a choice than to exactly show that. Keep in mind, agile is much more than iterative development with a project manager, it is empirical. That means, that the emphasis is the increment of the project combined with the evolution of the process. Nothing is stagnant in this model. There is no installment script for agile project management and it is not a one-step process. It is a continuation.

Without trust, project teams play the game they are part of. Real progress can be massaged with every process that does not exclude agile processes. Teams know when they are being measured in velocity or user story completion. They can control the situation. In other words, they can beat the system by low-balling their predications and shine in the newly created agile system. They appear to management that they are more productive, but they might in fact delivering the same amount of features as they did before the introduction of agile. The root cause of this problem is a lack of trust between management and the teams. We can’t assume to erase years of command and control leadership in a waterfall model in a matter of few short iterations. It will take time and a clear commitment from all participants in this process.

For example, teams new to agile should strive for a better range of meeting sprint goals. For example, I have seen teams who constantly outperform their goals by 200% and receive a lot of attention and praise. They are in my opinion (from a planning perspective) as immature as teams underperforming by the same rate. The goal must be to have mature teams achieving a range from 90%-110% of their sprint goals. That is predictable and makes a huge difference for portfolio management because of dependencies with other projects and initiatives.

Predictability like in the example above also includes improved team efficiency through process improvement. To accomplish that, executives need to allow teams to challenge current practices and encourage change. In many case executives need to actively work with the teams through the change. Only that will lead to true agile projects, with real sustainable pace while fine-tuning the process. Improving the process over time, will also positively impact productivity which has directly linked to the project portfolio.

During the initial iterations, executives should be patient with teams finding their steady-state. It also helps if executives emphasize the importance of predicting and committing sprint goals. At the end of the day, are looking for ways to work smarter, not harder.

Executives should understand and respect the team boundary. For example it does not help the teams when team members are constantly replaced and the team size changed. The same is true for part-time team members who help out just to help with a peak during one iteration. Executives need to understand their actions in particular context switching penalties as well as penalties for working with distributed teams.

The true engine of agile process improvements are the daily stand-up’s and the retrospectives. They usually introduce change, improvement ideas, raise impediments and result in a better process. Agile teams have this forum to express their impediments, needs and ideas. Executives should be pay attention to these channels and work with the teams through the action items. Without articulating them however, teams can’t expect that others will know about them.

The current business climate does not allow for many a lot of experimenting with agile processes. Executives are looking for quick impact, new models and change. Introducing agile takes time, but once the teams get started immediate positive results is visible. Agile training and coaching can help organizations to expedite the adoption. The investment into agile transformation services is usually insignificant when compared to the impact agile processes have on the bottom line of the enterprise. The advantage is that external coaches are unbiased and more likely to express the need for change, especially if it affects supervisors of team members. They also see a variety of projects in the industry and chose from a large pool of solutions, which have worked in the past.

While agile teams expect trust and understanding for their actions, the teams must also understand the motivations of executives. In some sense, the pressure of the business world has a direct impact on the agile teams. Executives are aware of this but reach out to agile developers for ideas, solutions and the appropriate technical response.