While face-to-face (F2F) collaborative work is often preferred, many of us now find ourselves in a situation where that may not be an option for the foreseeable future. Recently many organizations have asked their staff to work from home whenever possible. For those of us who have been working remotely for years this is business as usual, but for many of our colleagues this is a new situation. We all need to get better at working remotely, and an important aspect of that is making teleconferencing calls effective. So I thought I would share some tips that I've found to work well.
I've organized these tips into four sections:
The best calls are the ones that start well, and an important aspect of this is people joining the call well. Here's what you can do:
It's the responsibility of everyone on a call, not just the person facilitating, to ensure that the call runs smoothly. Here are a few ways you can do that:
Think about the last time you were on a call, and you were looking at other people over the video feed. You were probably assessing how they were groomed, how they were dressed, and what the state was of their work area is.
Nobody likes wasting their time on a call where nothing is accomplished. Effective planning and good facilitation can go a long way to making a videoconferencing call successful.
One last bonus tip: You are welcome to copy the image at the top of this article and use it as a quick reminder list of the key tips in this article. Print it and tape it to the side of your monitor if you like!
Please feel free to share this article with others or print it out so that you can keep it handy. We’ve also put together a short tip sheet that you can tape to your monitor.
I would love to hear about any other tips you would have so that I can update this blog and share them with others. Thanks in advance!
Since Disciplined Agile (DA) joined the PMI family in August 2019 we've gotten a collection of questions from people along the lines of "Why is there a difference between the advice in DA and PMI's advice?" So I thought I would write a few blogs examining why that is. This is the first.
There are several reasons why there are differences between existing DA and existing (non-DA) PMI materials:
My point is that there are very good reasons for the differences between what is in DA and what PMI has traditionally focused on. These differences are an important aspect of the value proposition of DA for PMI, and more importantly for our membership, because we can learn from these differences and then improve and grow based on those learnings. We're currently evolving DA based on the great material encompassed by the existing PMI standards and practice guides and our hope is that the existing PMI offerings will evolve to reflect Disciplined Agile ways of working (WoW) too.
In the next blog in this series I will do a deep dive into the differences between DA's take on Program Management and the PMI Program Management Standard. I suspect this will help to make some of the ideas in this blog more concrete and it will certainly make the opportunity before us a bit more explicit.
By Jeev Chugh, CDAP | CDAI and Joshua Barnes CDAC | CDAI
Enterprise agile transformation roadmaps using Lean Change are often fueled by the desire to deliver value faster with increased flexibility. They start with replacing traditional (waterfall) delivery methods with an Agile way of working, using pilot teams to validate early decisions on how to experiment with aspects such as team formation, lifecycle (agile, lean, continuous delivery, etc.) practices and techniques, and so on. What team members and business and technology leaders alike quickly glean is that the mind shift to collective ownership of the work, decentralized decision making, and all the energy to shift to self-organizing teams is just the first step. A big step, but one in a long journey.
To truly achieve the sizable outcomes from these enterprise transformations, many aspects beyond that of individual agile teams achieving a good level of maturity in “their” agile ways of working are needed. One of the shifts that enables such outcomes is adopting a Product Portfolio operating model. In this model, we transition from assembling a team to deliver a fixed scope via a project and then disband as the project ends to a long-lasting stable team delivering business outcomes via continual improvement of a product.
Along with this change comes the realization that traditional waterfall methods of budgeting and project cost accounting that requires upfront plans and budgets, is in inherent conflict with Agile ways of working; especially so when the agile approach uses a Lean Kanban-based lifecycle (very small batches) or Lean Continuous Delivery (no batches) lifecycle. Thus, to successfully scale Agile, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, dynamic resource allocation, and accelerated delivery. Moving from funding project scope to funding teams is a seminal part of product centric funding.
However, a clear understanding and alignment on “Product” and “Product Portfolio” terminology is imperative before delving into the product-based funding model and financial governance. It is often surprising to agile team members through all levels of leadership how hard it can be to all agree on what a “product” is. We often start by getting an agreement on what a product isn’t, such as a platform or other part of the technology stack or a corporate function such as marketing.
What is a Product?
A product is designed to continuously create business value for the customer by solving their problem or providing a benefit. Products have more permanence, and are living entities that we continuously iterate to meet market needs and finally are retired when the demand for it diminishes.
On the other hand, a project is a temporary endeavor, with a clear definition of the work that needs to be delivered, within a defined budget and by a specified date in time.
Key characteristics of a Product and a Project are elaborated below:
So, what are the benefits of pivoting to a product mode?
High Performing Teams
Standing Projects up and down is Inefficient and runs the risk of disbanding teams just as they enter the norming or performing phase. Organizations often underestimate the staff onboarding costs and ramp up time. Most product-centric organizations try to keep the same people working on a product through the lifespan of the product. Overtime, these teams build the stakeholder relationships and business domain knowledge, being stable and long-lived can benefit from a long performing phase.
Maintain Strategic Focus
Projects are funded independently and investments tend to be quite scattered and fragmented. Often, this leads to executives not having enough confidence that much of their investments are committed to top strategic priorities. Moreover, it really slows the organization’s response to change in business priorities.
Product Roadmaps are aligned with business capabilities and deliver measurable business outcomes. Further, funding is continuous with frequent checkpoints, allowing to dynamically reposition investments should the business priorities change
Ability to Truly Iterate
Projects are funded in one go, the entire agreed upon scope is funded to deliver the projected benefits. These un-validated hypotheses of benefits in the business case are based on a lot of assumptions, and it is often not feasible to clarify the entire scope upfront, despite the significant investment routinely made with traditional approaches. The reality is that many projects regularly miss the mark in terms of delivering benefits, and organizations often don’t have an effective process in place to validate actual benefits post every release.
On the other hand, product funding is continuous and flow based on validated learning of short timelines. This is a truly iterative approach that allows to pivot or preserve strategy to maximize the value delivery.
Project teams measure success as the delivery of agreed up-front scope, on time and in budget. This often means that they get too solution focused and lose sight of whether appropriate value is being delivered to the stakeholders. There is no point in delivering the entire upfront agreed scope if it doesn’t cater to the stakeholder needs anymore.
We all work to create value for our stakeholders as well as the organization. Business outcomes allow us to define value in a measurable way, thus focusing on what matters most from the customer perspective. For product teams, success equals improvement directly related to a business outcome. Hence, rather than seeing their job as delivering a task, product teams focus on delighting and adding value for their customers (internal or external).
Project teams ramp up quickly to build a solution over one or more releases, hand it over to an operations team in the “run” organization and are then disbanded, and the members move on to other project teams. With project teams being continually dragged onto new things, it gets very difficult to retain knowledge in legacy systems and often results in unmaintainable code, making it much harder to support such systems.
On the other hand, knowledge grows in product teams that allows team members to focus on a given business area for much longer. Overtime, these teams build strong stakeholder relationships and business domain knowledge, and can better understand the stakeholder problems and serve to their needs.
System Integrity and Continuous Improvement
Project teams are in constant pressure to deliver the agreed scope in defined timelines. This often leads to cutting corners and applying tactical fixes, increasing technical debt and neglecting long term architectural integrity in favor of short-term feature delivery. As the project team doesn’t face the long-term consequences of these tradeoffs, they are more likely to take such decisions for short-term gain. Over a period, this phenomenon compromises stability of systems, lowering quality and worsens the seed of value delivery.
On the other hand, Product teams have complete and collective ownership of the code and systems. There are no handovers, BAU or Operations team. The same team builds, runs and fixes any defects over the lifespan of the product, allowing them to evolve the system continuously and in a more sustainable manner. This also fosters a mindset that promotes taking responsibility for their product and the decisions they are empowered to make.
Making the shift to a Product Centric Organization Model
According to a recent Gartner survey, 85% of the organizations have adopted or plans to adopt a product-centric organization model.
To enable accelerated value delivery, adaptive planning, and flexibility required to achieve the digital priorities, many organizations are shifting towards a product centric model. In a product centric model, organizations align funding & resources to product portfolios that support their key business capabilities.
A business capability is the ability of an organization to do things effectively to achieve desired business outcomes and measurable benefits. Each business capability is independent from other business capabilities and realized by combining different functions of an organization to fulfil one functionality. Example, for an FMCG, key business capabilities are often: Direct to Consumer, Wholesale and Retail.
The key primary constructs of translating Enterprise Strategy into traceable User Stories, via Features and Business Outcomes are:
Adaptive Funding of Products and Product Portfolios: From Annual to Quarterly Cycle
Organizing work by Products and Product Portfolios is a good starting point to accelerate the delivery of value to one’s customers. However, that enough won’t suffice if the work is still funded through projects on an annual basis.
An annual investment process simply can’t keep up with the pace of change. Under an annual planning approach, entire funding is allocated at the start of the fiscal year. Significant effort is spent upfront to create a detailed business case required to win the funding approval. Changes in stakeholder priorities or market demand often render a lot of early requirements captured in the business case as obsolete, creating a lot of waste and requiring significant rework.
Thus, to achieve their digital ambitions, enterprises must work with business and Finance partners to move beyond traditional project-centric funding models and adopt a product-centric funding model that enables rolling-wave planning, accelerated delivery of value, and validated learning to make much more informed decisions. Moving from funding project scope to funding teams is a seminal part of product centric funding.
(Re)allocation of Funds across Product Portfolios
Initial annual funding allocations to individual product portfolios are based on un-validated hypothesis of benefits, which must be tested over the course of the year against changing priorities and proven value. The Portfolio Management Board meets on a recurring basis (Quarterly plus any market triggered event) to assess the allocation at the product-line level and reallocating funds as necessary to reflect changes to strategic enterprise priorities.
(Re)allocation of Funds within a Product Portfolio
The Product Line Council has the autonomy and the empowerment to reprioritize and reallocate funds across all products within the product line. Each product team within a product line are allocated funds on a quarterly basis based on proven value (unless it’s the first quarter where funding is based on projected benefits). The business value is measured by hitting a set of KPIs tied to the business outcomes such as increasing revenues, reducing costs, and improving customer satisfaction. This level of decentralization in decision making is possible when an organization implements a consistent, standardized and predictable cadence to support governance, offering frequent opportunities for key stakeholders to provide input on the roadmap.
Impediments to adopt Product-based Funding Model
The shift from a project-based funding model to a product-based funding model requires a major cultural and mindset change, as different stakeholders will have different reservations about the new approach. Some of the challenges to adopt a product-based funding model include:
Business & Finance partners reluctant to cede control of budgets
Some CFOs and business leaders are reluctant to cede control of budgets. In response, they must be made to understand that the reality is that they are gaining a lot more control by not allocating the entire funding based on the un-validated hypothesis of projected benefits and with no benefits tracking in place most cases. Also, by offering them visibility into product portfolio performance on quarterly basis with the option to pivot or preserve funding strategy based on proven value and/or change in priorities, we can significantly reduce the risk of financial loss.
Product Managers lacking finance expertise to manage product budgets
Identifying Product Managers with sufficient expertise to manage large budgets is often challenging and requires significant effort and commitment from the organization to build the financial competencies.
Resistance to funding not” fully detailed” requirements or outcomes
Business partners feel a comfort factor with a detailed business case based on projected benefits, even if it is based on a lot of assumptions and uncertainty upfront. To get business partners fully on board, product leaders need to craft a pitch that provides tangible examples of how adaptive funding model leads to better business outcomes.
Requires structural changes to support product-centric organization
Most companies we work with are organized around functions. Organizational structure change is required to adopt a product-centric operation model. Organizations are reluctant to Org design changes as it can be very difficult and expensive to implement.
We have endeavored to shed some light on a very complex topic, balancing the amount of context we can provide in a blog entry. If you have any questions please do use the comments section below.
Joshua Barnes, CDAC | CDAI
Jeev Chugh, CDAP | CDAI
To achieve organizational efficiency and success, consider improving the flow of value delivery in your organization. What are some considerations for your next leadership or team retrospective in order to optimize the flow of work?
In the context of this write-up, the flow of work being referring to is from Idea to Implementation of a consumable product increment. In order to visualize the flow, consider using process mapping or value stream mapping to identify all the steps from when an idea is brought up, through to approval of the idea. Steps to capture may include things like securing funding, identifying the team(s), prioritization, construction phase steps and releasing the increment of value.
Three areas to consider include Alignment, Dependencies and Prioritization. There are other considerations which impact the flow of work in your organization, but these are the three I often look at first. Here are some considerations/questions to ask your team and/or leaders when looking to improve flow.
How might alignment help flow? Alignment is the secret sauce to achieving better business performance. Alignment will help increase the speed to decision making and decrease wasted resources waiting for decisions, re-hashing discussions, churn and effort working on lower value work. The Disciplined Agile principle of Enterprise Awareness helps leaders understand and work from the same playbook, the same strategy and desired outcomes for the organization. Alignment to overall objectives will help to drive the right values, practices and behaviors to achieve organizational success. Team alignment to the stakeholder vision and iteration goals will help the team remove work not related to the goal or lower value items not which does not help achieve the stakeholder vision.
There are several considerations for dependencies. Are there inter-team dependencies present in the delivery of a consumable increment? Where do items span multiple teams? Can these dependencies be measured in wait time or other impacts? How are the teams structured (business silos, technology focus vs cross-functional whole team focused on a product)? Do your team members have the necessary permissions in the systems in order to complete the construction and release of the product increment? Can team members just do the work without waiting for decisions or approvals?
How does priority impact flow to your team? What or who prioritizes the work? Is it a lengthy process with multiple people or a quick decision with an authorized person? How many steps are in the re-prioritization process? Is it nimble enough to quickly and efficiently respond to change? Are stakeholders going to the product owner or directly to team members? If they are going directly to team members, why? How are the team members responding? Are they honoring the team’s definition of ready before bringing work into an iteration? If you have a product owner, are they negotiating with the stakeholders to place their item in a future iteration, or is it being added to an in-flight iteration? Does your product owner have a consistent method of assessing value/risk? Is this a transparent process to the stakeholders? Do the stakeholders understand the stakeholder vision and why their item is higher or lower in priority at any given time?
For more information on any of these three considerations, please refer to the Disciplined Agile toolkit for insights and choices to help guide an improvement to flow. As it relates specifically to prioritization, check out the Address Changing Stakeholder Needs process goal and consider what to prioritize, who will prioritize and how to prioritize. There may be many inputs from customer feedback, technical debt, stakeholder vision of the product etc. to consider. How we prioritize may first start with looking at the scope and intent of the present phase of delivery. Are you looking at mitigating risk? Building a strong yet flexible foundation? Delivering a high valuable consumable product to delight your customer? Understanding and aligning on this intent, perhaps using a stakeholder vision canvas can help to establish a prioritization process. Empower the product owner, architecture owner and team members to use the vision and process transparently in discussion with the stakeholders so they can provide input and negotiate how their item fits/or doesn’t with the current phase of delivery. Lastly, use backlog refinement sessions (also known as look-ahead modeling) as a conduit to get the stakeholders together in a room to discuss the next highest priority items.
What might your team use to measure flow? A few measures to start with:
Hopefully, this summary has given you some things to consider in order to Optimize Flow. What are key areas you look at to optimize flow? What measures does your team use? Please add them in the comments section below.
Lisa Lueck, CDAC
Kurt Cagle recently wrote an article for Forbes, entitled The End of Agile. Although Forbes’ regular Steve Denning responded effectively a few days later with Why Agile’s Future is Bright, I’d like to chime in with several thoughts beyond what Steve has offered. Here they are:
Let’s hope this is the end of undisciplined agile. But as Steve Denning points out, it certainly isn’t the end of agile. I suggest this could be an important beginning for Disciplined Agile approaches.