Agile

Study Reveals Agility and Collaboration Drive Strategy Execution

cross-functional-team-collaboration.jpg

Ongoing planning, active engagement, empowered teams, and heavy collaboration are not only key components of an agile mindset; they're paramount to achieving good strategy execution.

This an indelible truth that I was glad to see validated in a recent global executive study conducted by Harvard Business Review Analytic Services in association with the Brightline Initiative, as detailed in the resulting report, "Testing Organizational Boundaries to Improve Strategy Execution."

According to the study, only one-fifth of the 1,636 organizations in the study were able to achieve 80% or more of their strategic targets, and they were able to do it by breaking through organizational silos and encouraging more agile ways of working. Moreover, they were better able to adapt to market changes and new demands.

According to Brightline, the common habits among the top performers were as follows:

  • Decision-making is decentralized and occurs via cross-functional teams

  • Collaboration is encouraged and rewarded, with teams empowered to put strategic initiatives into action.

  • Executives are engaged and act as coaches, not just leaders

  • Development and delivery of strategic initiatives is a dynamic and continuous process, not something just visited annually or less often

One thing I've noticed over the years, and it seems evident in these findings as well: The best organizations operationalize these traits. It's ingrained in their culture, their training, and in their reward systems.

You can read and download the full report in the article hyperlink above.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.


PDWare is a pioneer in resource planning software, offering intuitive resource planning tools to drive your work portfolio based on your people's capacity. PDWare believes that good strategy execution, portfolio management, and project delivery begins with a solid foundation of resource planning. PDWare is a proud sponsor of the Resource Planning Summit, the premier resource planning conference.

How Resource Planning Tools Drive More Effective Agile Funding

fundng2.jpg

A recent CIO article from Hakan Altinepe, titled "Product Funding and the Burden of Agility" explores the differences between traditional project-based funding and Agile "product-based" funding, and illustrates why priority and resource capacity are central to the properly funding Agile projects.

As the article points out, traditional funding involves the annual planning cycle that explores opportunities backed by a business case and with fixed scope and an estimated schedule and budget. In Agile, product-based funding is distributed across ongoing and self-managed teams, often organized around product areas. Cost and schedule are fixed, and teams tackle the highest priority, most valuable work to continuously deliver value.

According to Altinepe, Agile operating environments offer three management levers to influence the outcome, scope, and schedule of agile initiatives:

  • Work priority

  • Team size

  • Portfolio workload

This is also consistent with what I’ve been saying and what PDWare has been saying., so it’s refreshing to see it acknowledged. The principle is that, with these levers set correctly and adjusted frequently, work can be accelerated or decelerated, and team resources can be reallocated accordingly. However, when these variables aren't maintained correctly, people start working on the wrong things and value is diminished.

As Altenepe states, "the burden of continuously maintaining these levers at an optimum is called the burden of agility, and the aggregate economic loss caused by the improper settings of these levers is called the cost of agility."

And here comes the punchline. The burden and cost of agility increases at scale.

Altinepe notes that this is where Agile-friendly resource planning tools can help, provided they have the requisite maturity with balancing supply, demand, and priority.

The article rightfully concludes that the three-lever product-funding method is necessary for all agile organizations with considerable scale, and cautions that this does not come without a cost. With that said, agile organizations can mitigate this cost with tools and methods that help balance the three levers of work priority, team size, and portfolio workload.

I highly recommend perusing the article.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.


PDWare is a pioneer in resource planning software, offering intuitive resource planning tools to drive your work portfolio based on your people's capacity. PDWare believes that good strategy execution, portfolio management, and project delivery begins with a solid foundation of resource planning. PDWare is a proud sponsor of the Resource Planning Summit, the premier resource planning conference.

How Resource Planning Complements Agile

agile3.png

Some people wonder if and how resource planning applies in an Agile world. There should be no question. The chassis may change from traditional to iterative, but the drivetrain always remains resource planning. In essence, the question is, regardless of delivery approach: How do we make sure we have the capacity to deliver on our strategies at the right time? 

In fact, resource planning not only applies to Agile; it turbo-charges it.

Aakash Gupta puts it succinctly in his article on Project-Management.com titled "Resource Capacity Planning for Agile Teams":

Given how agile is built as a meticulous process driven by a stringent workflow, planning capacity becomes integral to agile’s success... Agile projects make room for innovation, velocity and unparalleled levels of productivity. Tie it in with resource management and you will find yourself with a dream team!"

Indeed, Agile brings a lean, adaptive mindset and a continuous flow of value. Planning adds alignment with strategy, funding, and resources. These are not mutually exclusive concepts and, in fact, complement one another.

There's an old Arabian story about two men on a long trek across the dessert. They wake up one morning and one asks in a panic, "Where are the camels!?" The other man says, "You told me to trust in Allah so I didn't tie them up." The first man replies, "Let me correct my advice. Trust in Allah, but tether your camels!" There've been many variations of this advice since, but the same concept applies to Agile and planning. Allow the empowerment and freedom that Agile brings, but also plan in order to ensure alignment and feasibility.

Back to Gupta's article, which is well worth reading. In it, he introduces the concept of the "focus factor." In other words, when assigning people to teams, it's important to understand how much they are, in fact, available to focus on the actual Agile activity. It's rare when a person can focus 100% on any given activity. There are disruptions, administration, company meetings, emergencies, and so on, and that's not including planned downtime like vacations. The focus factor accounts for this by offsetting their allocation to the team by the desired FTE amount (e.g., Jim can focus 70 percent of his time to the team).

As an aside, PDWare addresses this in their software by allowing people to be allocated to teams by percentage, and then assigning teams to projects. Both numbers are considered in the individual's allocation forecast, along with any other work activities they're assigned to. This allows the automatic creation of a combined resource forecast across Agile and non-Agile work.

Scaled Agile Framework (SAFe), created by Dean Leffingwell, bridges planning and Agile on an enterprise scale, aligning portfolio, program, and team activities, and is rapidly gaining popularity. A quote cited on the Scaled Agile website puts it perfectly:

"The more alignment you have, the more autonomy you can grant. The one enables the other."

 —Stephen Bungay, Author and Strategy Consultant


Stay tuned for a future post where I'll talk more about resource planning as it relates to SAFe.

If you’re new to Agile, or even if you're experienced but are finding it difficult to make it work in your organization, I'll be presenting a free webinar Wednesday, March 27 at 11am EST titled "Agile 101 for Resource Managers." It'll offer a complete overview of the basics of Agile, as well as an explanation of how resource planning can boost Agile performance. Click here to register.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

The Advantages of Product-Based Execution

Product Focused team3.jpg

With all the well-publicized challenges inherent with project-based work, could there be greater benefit to operating in "product mode" by organizing ongoing business capability-focused teams around products and product lines? This is the subject of a fascinating article on MartinFowler.com by author and consultant Sriram Narayam (Agile IT Org Design) titled Products Over Projects.

For quite some time I've been suggesting to clients to consider organizing by product, so I'm delighted to see the concept so well articulated and thought out.

Problems with Managing by Project

As Narayam points out, with projects, an initiative is funded, a team is formed, and the outcome is delivered. Then a new project is assigned, and in all probability a new mix of players that have to go through the whole "forming/storming/norming/performing/adjourning" cycle all over again. And forget about ideation, that's a whole separate process done by "other folks." Prioritization also generally happens external to the project. Lastly, the rest of the product lifecycle, including benefits realization, is disconnected.

With a narrow focus on the scope of the project, you run the risk of getting exactly what you asked for (if you’re lucky) but not what you need.

What is Product-Mode and What Kind of Environments is it Applicable To?

In an organization that operates in "product mode," the flow from ideation to build to run is much more holistic. A team is funded based on the needs of the product category, product line, or strategy that they're meant to foster and nurture. The team generates ideas and prioritizes work. The team leads the delivery. The team owns the benefits realization, and is measured by meaningful KPIs, not just whether they delivered to a set of requirements. 

Equally important, the team sticks together beyond the lifecycle of a single project or initiative. They build knowledge and gain rapport, remaining at peak performance throughout. While the article focuses on this approach in the IT sector and the digital realm (beyond just software development), I would add that this concept is broadly applicable and increasingly employed in R&D, Professional Services, NPD organizations, and more. 

Why not create programs around your product categories, products, or product lines and have the teams responsible for the prioritization, development, and nurturing of their area? It's a much more integrated approach.

Narayam uses a case study about the development of a Retirement Calculator as an example. A financial services company needed the calculator in order to steer prospects toward buying retirement products or improving their plan contributions. A project team was assigned to develop the calculator and then… well, that was it for their role. A product-based team would have instead been focused on solving the problem of increasing sales and plan contributions, of which a calculator may have been part of. 

Impact on Resource Planning

Most articles that talk about agile and product-based approaches ignore the ever crucial resource planning aspect. Fortunately, this article doesn't, and specifically cites the staffing utilization challenges, which differ somewhat from that of project-based environments.

For instance, team sizes need to be periodically reviewed to adapt to changing business needs. Areas with light roadmaps may need to be combined with others.  As for prioritization, a central component of resource planning, cross-team "initiative" priorities must still be set centrally, with team-specific "roadmap" priorities managed by the team.

From a cross-team utilization perspective, the article notes that some team members may take on multiple roles if they have bandwidth. However, Narayam wisely cautions against optimizing solely for utilization, implying that optimizing for speed of delivery and value is more beneficial in the long run. He also offers suggestions for employing different types of teams, and even having hybrid core/flex teams, augmenting core teams where appropriate with additional resources.

All in all, Narayam makes sound points in illustrating a refreshing approach to work that is built to foster an increased value focus, reduced time to market, and greater benefits realization. I think the article is an absolute must-read for anyone pursuing greater business agility and value-focused work methods.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

When is Agile Not Agile? Common Mistakes to Avoid

Simpsons-sweatshop.jpg

As organizations strive to gain greater business agility, many are adopting Agile methodologies, not realizing that their implementation of it is anything but agile. In fact, it's often quite the opposite, turning the original set of guiding Agile principles on its head.

Bestselling authors Lindsay McGregor and Neel Doshi wrote an insightful article in HBR titled "Why Agile Goes Awry---And How To Fix It" that makes this very claim.

"In the spirit of becoming more adaptive," they say, "organizations have rushed to implement Agile software development. But many have done so in a way that actually makes them less agile." Not only that, it makes them less motivating.

The article goes on to contrast the original four guiding principles of Agile with the common practices that seem in direct opposition.

Regarding the principle of "Individuals and interactions over processes and tools," many organizations have let their Agile process become so rigid that people feel handcuffed by it and aren't allowed to question it. According to the article, developers and engineers have reporting feeling like “short order cooks.” Not surprisingly, I’ve heard this very term used myself in some Agile organizations.

And despite the mantra of "Working software over comprehensive documentation," some teams spend significant time documenting detailed user stories to the detriment of the true Agile mission of getting small experiments done in a collaborative manner.

Speaking of collaboration, the core Agile philosophy of "Customer collaboration over contract negotiation" goes out the window when the process involves work being passed like a baton from product managers to designers to engineers, with the customer nowhere in sight until release time.

Lastly, the principle of "Responding to change over following a plan" has become confused with "winging it" or "picking features that look interesting" as opposed to high value, strategically-important features that have been prioritized with the customer.

None of this is theoretical speculation. On the contrary, it’s sadly become common practice in many companies. Indeed, the authors based their findings on their study of engineering practices in 500 organizations, along with anecdotal evidence. 

The most striking finding of all was that these practices not only ignore core Agile principles, but they bring about the opposite result that Agile was intended to deliver. They demotivate people. As the authors put it, "Because they’re not allowed to experiment, manage their own work, and connect with customers, they feel little sense of play, potential, and purpose." 

It’s a sad, all-too-predictable, Dilbert-like situation. But all is not lost. The authors propose six changes to consider to better balance tactical and adaptive performance:

1. Software development should be a no-handoff, collaborative process.

2. The team’s unit of delivery should be minimally viable experiments. 

3. The team’s approach should be customer-centric.

4. Use timeboxes to focus experimentation and avoid waste.

5. The team should be organized to emphasize collaboration.

6. The team should constantly question their process.

For projects that benefit from an Agile approach (and not every project does), I couldn’t agree more. The authors expand on each in the article, so it's well worth a read.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

Strategic Planning in an Agile World

Business Agility3.png

I've often written about the importance of continuous planning at multiple levels, while also emphasizing the urgency of fostering business agility to meet dynamically changing needs.

I came across an HBR article by Alessandro Di Fiore, founder and CEO of the European Centre for Strategic Innovation (ECSI), titled "Planning Doesn't Have to Be the Enemy of Agile" that, to me, captures the essence of the tension between strategic planning and team-based agility. More importantly, it offers examples of how to make the two seemingly opposite concepts work well together.

As Di Fiore says, "The logic of centralized long-term strategic planning (done once a year at a fixed time) is the antithesis of an organization redesigned around teams who define their own priorities and resources allocation on a weekly basis."

To resolve this tension, he proposes that a new form of "Agile Planning" is needed that aligns top down strategic planning, bottom-up team-based decision-making, prioritization, and execution, and a mid-level process that helps bridge the two.

In effect, this blends the best of both worlds -- where agile teams leverage qualitative data and judgement to aid in prioritization and resource allocation, while big data continues to flow in through the strategic planning process and Information Technology. The sweet spot is the right combination of human judgement and hard data.

Put another way, I think it's safe to say that team judgment without data is blind, and relying on data alone is deaf. The corporate graveyards are full of companies that have done either or both.

When Corporate Strategy Meets Team Execution

The idea of blending top-down and bottom-up planning is consistent with other successful examples I've seen. The great author and cultural expert, Fons Trompenaars (Did the Pedestrian Die, 21 Leaders for the 21st Century, and others), once shared how Heineken learned this lesson the hard way.

As Trompenaars explains, Heineken released a TV ad where a woman was frantically rooting through her closet trying to find something to wear for a date. Then the doorbell rings. It's her date, who throws her a leather jacket. The next scene shows them in a bar drinking Heineken with the slogan: "Beer as beer is meant to be."

Well, in some countries, sales went down, not up. Upon research, Heineken learned why. Apparently, in those particular cultures, the message received was: "Only slobs drink Heineken."

Oops!

After than, Heineken changed their approach. The provided a top-down theme and general priorities (e.g., In the European region, portray Heineken as a casual, relaxing beer) and left it up to the local advertising departments within that region to come up with an ad that would work in their country. It worked like a charm.

They chose another theme for the Caribbean region (Portray Heineken as a metropolitan beer), with each island creating their own ads. Again, it work so well, that Heineken began winning all sorts of advertising awards. To this day, they continue to win advertising awards, with what I might call a hub-and-spoke planning model. 

It's a similar concept to Agile Planning: Remain agile in terms of priorities, methods, and execution while providing corporate themes and strategies from the top. What Di Fiore details is the bridge between corporate planning and individual teams. I highly recommend reading his article.

Bottom line: When it comes to strategy execution, resource planning, and business agility, you CAN have your cake and eat it too.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn.

How Your PMO Can Support Agile AND Waterfall: Tips for Adaptive PMOs

Agile and Waterfall.jpg

So much has been written on the Agile PMO, the Adaptive PMO, and how the PMO needs to evolve from being the methodology police to an enabler of business agility and a leader of change.

Related to this is the ability to support the ever-growing need to incorporate Agile, Waterfall, and Hybrid approaches in their mix as PMOs become more adaptive. As such, I found this article by Susanne Madsen, Agile or Waterfall: 8 Tips to Help You Decide, very fair-minded and informative. 

While iterative approaches can still be used to provide rapid feedback even on projects with the most stringent of requirements, a pure Agile approach can be challenging for a huge projects with distributed teams and little access to customers. Deciding on the best approach is more an art than a science. Fortunately, the article offers a good set of considerations to help the project manager and/or team decide, ranging from project size and team distribution to user access and solution clarity. 

Keep in mind, the PMO's role shouldn't be to dictate methodology; it should be to offer guidance (such as the above) around approaches and execution, fostering good practices while keeping its focus on more strategic things. After all, the PMO has a crucial role to play in helping the organization bridge strategy and execution, drive portfolio and program benefits, and maximize its resources toward the most valuable work. 

This 2011 article from PMI on Reinventing the PMO hits the nail on the head, and is still relevant and fresh today. Fortunately, PMO leaders are finally starting to catch on. Better late than never, as they say!


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn

Agile and Waterfall: Dispelling the Myths about Bimodal IT

Dilbert_Agile_Programming_Speed.png

In today's world of digital transformation and the Internet of Things, among other advances in technology and logistics, business agility is not just an advantage, it's a necessity.

Several years ago, Garter introduced the Bimodal IT framework to address this. The idea was to allow for two modes of operations: one for areas that are more understood, and another for areas that require rapid iterations of discovery. 

Misinterpretations also ran rampant, leading to debates, especially among the Agile community, who felt Agile was being misunderstood to be about sacrificing quality and stability for speed.

This 2016 article from Gartner, Busting Bimodal Myths, served to clarify many of the key misconceptions, though to this day, people are misinterpreting the intent. 

From the article, it's clear that Bimodal is:

NOT the slow lane vs. fast lane. 

NOT the quality lane vs. speed lane.  

NOT the planning lane vs. wing-it lane. 

NOT the stability lane vs. innovation lane. 

NOT the sustaining lane vs. the development lane. 

NOT the old lane vs. the new lane.

Nor is it necessarily about Agile vs. Waterfall. 

Both modes can have quality and speed. Both involve planning and accuracy. Both can be stable and innovative. Both can be used for development or change. And both are very much relevant today.

In a nutshell, Bimodal IT is about increasing enterprise agility, enabling a variety of tools in meeting two kinds of needs: initiatives that benefit from heavier up-front planning and phased approval gates, and those that benefit from rapid iterations of product. Agile approaches can be applied to either, but a Waterfall approach is not conducive to the latter.

The principles of Agile lend themselves to rapid iterations with the customer, where change is expected. The principles of Waterfall lend themselves to longer efforts that must be well defined, and where change is to be avoided unless carefully vetted. Waterfall does tend to move slower by design.

So yes, this is where the general interpretation comes in that Mode 1 is for Waterfall and Mode 2 is for Agile, and it isn't entirely wrong. Like any framework, there needs to be flexibility and common sense in using the right tool for the right job.

Stay tuned for an upcoming article on resource planning in a bimodal world.


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn 

Focus Matters on Agile Projects, Too: Oscillation versus Iteration

Oscillation.jpg

In my last post, I talked about the importance of focus. Nowhere is focus more needed than on Agile projects, where change is king. I particularly recall an excellent article by one of the Agile founders, Jim Highsmith, where he talked about Oscillation vs. Iteration

As Highsmith pointed out, with short iterations and close customer interaction, it can be tempting to switch gears more than once. In fact, in some Agile projects, the gears are switching constantly. The customer keeps changing their mind. Multiple customers chime in with different needs. An emerging business imperative forces a change in tactics. Or worst of all, you didn't quite understand the need to begin with (or it wasn't articulated well enough).

Genchi Genbutsu.jpg

This is where I always point out the need to be an "anthropologist." Using the Toyota's lean manufacturing principle of Genchi Genbutsu (go and see for yourself) or Honda's Sangen Shugi ("three actuals," representing the actual place, actual product, and actual situation), you shouldn't just assume that what a customer asks for is what they need or want. Go and see for yourself what the situation is. At the very least, you'll have a better understanding of what they're asking for.

Likewise, just because you have an iterative, Agile project doesn't mean you shouldn't have design guidelines or requirements, or even an understanding of scope. Agile doesn't mean no planning or scope. It simply fixes the time and cost, and estimates the features and scope (as opposed to Waterfall, which does the opposite, estimating time and cost to deliver a fixed scope of work). With Agile, you're estimating what can and should be delivered to meet a certain objective, both in terms of defined iterations and for the ultimate project (typically a targeted release).

But back to our oscillation discussion, Highsmith cautions that it's not always easy to tell when you're oscillating vs. iterating. For instance, if government regulations keep changing or there are legitimate learnings that dictate a new course, then it's a normal part of Agile iteration.

In any case, the point is to be aware of when you may be oscillating, and if so, take corrective action before it gets out of hand.  And to avoid unnecessary oscillation to begin with, be sure to gain an understanding of the goals and objectives of your initiative (seeing the situation for yourself where possible).


JB Manas - website photo.jpg

Jerry Manas is the bestselling author of The Resource Management and Capacity Planning Handbook, Napoleon on Project Management, and more. At PDWare, Jerry helps clients improve strategy execution through tools and processes that align people and work with organizational priorities. Connect with Jerry on Twitter and LinkedIn