Project Management

Why Do We Need Agile Programs?

From the Disciplined Agile Blog
by , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Tatsiana Balshakova
Mark Lines
Mike Griffiths
Scott Ambler
Bjorn Gustafsson
Curtis Hibbs
James Trott

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

linkedin twitter facebook Request to reuse this  


Why?

An IT program is a large IT delivery team composed of two or more sub-teams.  The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goal of producing a consumable solution for their stakeholders.  In this blog posting we examine some of the reasons why large IT delivery teams are formed and strategies to reduce or even eliminate the need for such teams.

There are several reasons why large IT delivery teams exist in the first place:

  1. Some endeavours are inherently big. Sometimes an organization will decide to take on a complex effort, such as developing an operating system, an air traffic control system, a financial transaction process system at a bank, and many other examples.
  2. Overly-specialized staff promote larger teams.  When IT staff are narrowly focused it requires many people to work, at least part time, on a team so that the team has sufficient skills to get the job done.  When people are generalizing specialists your teams become much smaller and collaborative.
  3. Overly bureaucratic processes promote larger teams.  Sometimes the systemic bureacracy in the organization requires large numbers of people to address that bureaucracy.  I once assessed a eighty-person project team who were doing work that only required between ten and fifteen people to do the “real work” and everyone else to conform to the overhead of their traditional CMMI-compliant process.  Sadly they didn’t rework the team and failed to produce anything after three years and many millions of dollars of investment.  As an aside, it is possible to effectively combine CMMI and disciplined agile approaches, but you need to overcome the cultural dissonance of the two paradigms.
  4. Working on large teams can lead to greater rewards.  Similarly, someone is “empire building” and purposefully creates a large team so that they will be rewarded for doing so.  We have worked in two organizations where before their agile transformation the pay grade of a manager was determined by the number of people the person managed.  Worse yet, in one organization the people on the larger teams tended to get better bonuses, and quicker promotions, than people on smaller teams regardless of the actual ability of the team to deliver value to the organization.

In our opinion only the first reason is a valid one for building a large agile team.  The other reasons reflect aspects of organizational cultures that need to be fixed in time.  Luckily, there are several strategies that you can employ to reduce the size of a team:

  1. Reorganize the problem into a collection of smaller problems.  Disaggregation of a large problem is performed through a combination of agile envisioning and agile business analysis. This is a key responsibility of your product management efforts: to feed reasonably-sized portions of work to IT delivery teams.
  2. Reduce the problem.  Sometimes a large problem can be shrunk down through pruning features out of the vision, or at least by deferring them until later.
  3. Address your organization’s culture. As we discussed earlier, most of the reasons that organizations build large IT delivery teams are the result of cultural challenges.  Fix the real problem by adopting agile and lean ways of thinking and working.
  4. Organize the large team into a collection of smaller teams.  In other words, create a program.

When you find yourself in a situation where you need a large IT delivery team, and those situations do exist in many organizations, and you can’t find a way to reduce the size of the team, then you will need to adopt strategies to coordinate that team.  The disciplined agile project management blade describes such strategies.

Related Postings

 

 


Posted by Scott Ambler on: July 10, 2015 10:08 AM | Permalink

Comments (0)

Please login or join to subscribe to this item


Please Login/Register to leave a comment.

ADVERTISEMENTS

"There is nothing more difficult than talking about music."

- Camille Saint-Saens

ADVERTISEMENT

Sponsors