Disciplined Agile Reuse: Funding Strategies
From the Disciplined Agile Blog
by Tatsiana Balshakova,
Mark Lines, Mike Griffiths, James Trott, Bjorn Gustafsson, Curtis Hibbs, Scott Ambler
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.
View Posts By:
Tatsiana Balshakova
Mark Lines
Mike Griffiths
James Trott
Bjorn Gustafsson
Curtis Hibbs
Scott Ambler
Past Contributors:
Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker
Recent Posts
DA 5.6 is released
Disciplined Agile 5.5 Released
Choose Your WoW! Second Edition Is Now Available
Requisite Agility applied in Project Management
Disciplined Agile and PMBoK Guide 7th Edition
Categories
#ChoiceIsGood,
#ChooseYourWoW,
#ConsumableSolution,
#ContinuousImprovement,
#CoreAgilePractices,
#experiment,
#Experimentation,
#GuidedContinuousImprovement,
#Kaizen,
#LifeCycles,
#ProcessImprovement,
#TealOrganizations,
Adoption,
agile,
agile adoption,
Agile Alliance,
Agile Business Analyst,
Agile certification,
agile data,
agile governance,
agile lifecycle,
agile metrics,
agile principles,
agile transformation,
Agile2018,
Agile2019,
Agile20Reflect,
AgileData,
Analogy,
announcement,
Architecture,
architecture,
architecture owner,
Articles and publications,
Asset Management,
Atari,
Backlog,
Barclays,
being agile,
benefits,
bi,
blades,
book,
Branching strategies,
Browser,
Business Agility,
business intelligence,
business operations,
capex,
Case Study,
Certification,
certification,
charity,
Choose your WoW,
CMMI,
cmmi,
Coaching,
Collaboration,
Communications Management,
Compliance,
Compliancy,
Conference,
Construction,
Construction phase,
Context,
Continuous Improvement,
coordination,
COVID-19,
Culture,
culture,
Cutter,
DA,
DAD,
DAD Book,
DAD discussions,
DAD press,
DAD roles,
DAD supporters,
DAD webcast,
DADay2019,
Data Management,
database,
dependencies,
Deployment,
Development Strategies,
DevOps,
disaster,
Discipline,
discipline,
Disciplined Agile,
disciplined agile delivery,
disciplined agile delivery blog,
Disciplined Agile Enterprise,
disciplined devops,
Documentation,
Domain complexity,
dw,
DW/BI,
Energy Healing,
Enterprise Agile,
Enterprise Architecture,
Enterprise Awareness,
enterprise awareness,
Essence,
estimation,
Evolving DA,
Executive,
Experiment,
facilitation,
FailureBow,
feedback-cycle,
finance,
Financial,
FLEX,
Flow,
foundation layer,
Funding,
GCI,
GDD,
Geographic Distribution,
gladwell,
global development,
Goal-Driven,
goal-driven,
goals,
Governance,
GQM,
Guideline,
Hybrid,
Improvement,
inception,
Inception phase,
India,
information technology,
infosec,
Introduction,
iterations,
Kanban,
large teams,
layer,
lean,
Lean Startup,
learning,
Legal Project Management,
LeSS,
Lifecycle,
lifecycle,
Manifesto,
mark lines,
marketing,
MBI,
Metaphor,
Metrics,
metrics,
mindset,
Miscellaneous,
MVP,
News,
News and events,
Non-Functional Requirements,
non-functional requirements,
Non-solo development,
offshoring,
Operations,
opex,
Organization,
Outsourcing,
outsourcing,
paired programming,
pairing,
paper,
People,
People Management,
phases,
Philosophies,
Planning,
PMBoK,
PMI,
PMI and DA,
PMI Chapter,
Portfolio Management,
post-format-quote,
Practices,
practices,
Principle,
Process,
process improvement,
process tailoring,
Product Management,
product owner,
Product Owners,
productivity,
Program Management,
Project Management,
project-initiation,
Promise,
Quality,
quality,
rational unified process,
Refactoring,
Reiki,
Release Management,
release management,
Remote Training,
Remote Work,
repeatability,
requirements,
Requirements Management,
research&development,
responsibilities,
retrospectives,
Reuse,
Reuse Engineering,
ride for heart,
rights,
Risk Management,
Risk Management,
Risk management,
Roles,
RUP,
SAFe,
sales,
Scaling,
scaling,
scaling agile,
Scheduled Workshops,
SCM,
scorecard,
Scrum,
ScrumMaster,
SDLC,
Security,
security,
self-organization,
SEMAT,
serial,
skill,
solutions software consumable shippable,
Stakeholder Management,
strategy,
Support,
Surveys,
Teal organizations,
team development,
Team Lead,
team lead,
Teams,
Technical Debt,
Teleconferencing,
Terminology,
terraforming,
test strategy,
testing,
time tracking,
Tool kit,
Toolkit,
tools,
traditional,
Transformation,
Transition iteration,
transition phase,
Uncategorized,
Upmentors,
Using PMI Standards,
value stream,
velocity,
vendor management,
Virtual Training,
Workflow,
workflow,
workspaces
Date
Reuse isn’t free. Without funding, either implicit or explicit, meaningful reuse simply doesn’t happen. In short, your approach to funding is a critical success factor for your reuse engineering strategy.
In this blog posting we explore several strategies for funding reuse within your organization. The funding strategies, from most to least desirable, are:
- Funded reuse-engineering team. A team of one or more people in the role of reuse engineer is provided explicit funding to support and enhance the reuse efforts within your IT department.
- Asset-level funding. Funding for a specific reusable asset, such as a security framework or collection of micro services, is explicitly budgeted for. This funding should cover the development, enhancement, and long-term support of the asset.
- Development team-based funding. Funding for the use, development, and enhancement of reusable assets is included in the budget for development teams. Such funding is often accompanied by mandates along the lines of “The team will achieve X% levels of reuse” (although teams are rarely measured against these mandates in practice).
- No explicit funding. With this approach reuse occurs on an ad-hoc basis within delivery teams, often driven by tactical decisions at the team level as opposed to strategic decisions at the organizational level.
- Chargeback funding. Delivery teams are charged for usage of an asset. In some extreme cases development teams are charged to download an asset from the reuse repository, typically because that’s easier to charge them at this point in time over charging for actual usage.
Table 1 compares and contrasts these funding strategies.
Table 1. Comparing the reuse funding strategies.
| Strategy |
Advantages |
Disadvantages |
Considerations |
| Funded reuse engineering team |
- Reuse is actively supported across all IT
- Long-term support activities, such as evolution of assets and reuse repository, are directly funded
- Cost of reuse engineering is easily measured
|
- Value provided by reuse engineering team must be measured to justify continued, year-over-year funding
- Reuse engineering team becomes a target for financial cuts because the cost is easily measured but the value provided is difficult to measure
|
- Supports a robust, organization-wide, reuse engineering strategy
- Significant discipline required: IT executives must understand and be prepared to execute an explicit reuse engineering team strategy
|
| Asset-level funding |
- Development of potentially reusable assets are funded in a targeted manner
- Cost of individual assets easily measured
|
- Typically used for initial development of an asset, but long-term support and enhancement is often neglected
- Can result in development of similar assets by disparate teams
|
- Useful first-step towards the funding of a reuse-engineering team
- Can be made to work in organizations with a project-based IT funding, although long-term support and enhancement of the asset can be a struggle in such situations
|
| Development team based funding |
- Development of potentially reusable assets are funded
|
- Difficult to fund ongoing enhancement and support of your reusable assets with this strategy, unless the team is stable over the long term and willing to support the assets that they create
- Funds earmarked for reuse often diverted for development of non-reuable functionality
- Many “potentially reusable assets” are created yet few are reused by other teams due to lack of infrastructure to support wide-scale reuse
|
- This strategy may be your only option in IT departments with strict project-based IT funding
|
| No explicit funding |
- Some delivery teams, particularly very disciplined ones, will still choose to have high levels of reuse even when no organizational support is provided
|
- Reuse will be inconsistent at the organization level
|
- The only way reuse will happen in this situation is through the maturity and enterprise awareness of the delivery teams
|
| Chargeback funding |
- Potential exists to fund ongoing support and enhancement of reusable assets
|
- Development teams are punished for reusing assets, motivating them to create their own versions
- Complexity of chargeback added to overall organizational bureaucracy, effectively adding waste to your IT processes
|
- Chargeback strategies will undermine if not destroy your reuse engineering endeavour
- There is no situation where we would recommend this strategy
|
Combinations of these strategies can of course be implemented.
Related Reading
Posted
by
Scott Ambler
on: August 23, 2015 08:23 AM |
Permalink
Comments (0)
Please login or join to subscribe to this item
Please Login/Register to leave a comment.
|
I was going to have cosmetic surgery until I noticed that the doctor's office was full of portraits by Picasso.
- Rita Rudner
|
