Project Management

Enterprise Awareness over Team Awareness

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


View Posts By:

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

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

One of the strengths of the Disciplined Agile (DA) toolkit is that it promotes the philosophy that teams must be enterprise aware.  But what does this really mean and why is it important?  Two very good questions that I address in this posting.

For the purpose of our discussion we will focus on five levels of awareness that people may exhibit:

  1. Individual awareness.  From this viewpoint it’s all about how someone can change themselves by gaining new skills, insights, experiences, and so on.
  2. Team Awareness.  Here the focus is on the team can learn and improve together.  This has been a primary philosophy of the agile community for quite some time, mostly to our benefit but also to our detriment.  Solutions are developed by teams, so by promoting a greater focus on the team agilists are able to improve their overall productivity a bit.  But, if the efforts of that team aren’t well aligned with the overall goals of the organization then dysfunctions will occur.  For example, agile delivery teams that are merely team  aware may end up introducing new technologies that their operations groups aren’t willing or able to support in production.  Or they may reinvent existing functionality.  Or they may create yet another data source even though the data already exists elsewhere.  Or they may develop to their own conventions that don’t reflect the way other teams work.  Or they may learn that a certain technique or strategy works well for them, but they don’t share this learning outside of the team.
  3. Departmental Awareness.  People consider the needs of their department, not just their team.  In this case developers are focused on improving the overall process, perhaps by adopting more of a DevOps mindset instead of simply a development mindset.
  4. Enterprise Awareness.  People are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team.  This is an example of the lean principle of optimizing the whole, in this case the organization, over local optimization at within just the team.
  5. Community Awareness.  People consider the needs of their community, doing what they can to give back by sharing knowledge, by striving to learn themselves, and by striving to help others who might not necessarily be in their organization or even known to them.  

Of course, a given individual is very likely operating from several viewpoints at once.

Agile has done a great job of helping the IT profession refocus from individual to team awareness.  But if we want to be effective as professionals we at least need to promote the philosophy of enterprise awareness, so that we’re optimizing the work that we do for our organization.  Agile teams that are enterprise aware will work closely with enterprise professionals, such as enterprise architects and operations staff, to ensure that they are leveraging and better yet enhancing the existing infrastructure.  Their architectures will their organization’s technical roadmap and similarly the scope of their effort will reflect their organization’s business roadmap.  They will follow existing development guidelines and enhance them where appropriate.

By working in an enterprise aware manner DA teams enjoy:

  • Higher levels of productivity because they are less likely to reinvent the wheel
  • Quicker times to deployment/market because they have less work to do
  • Higher return on investment (ROI) because they have less work to do
  • Higher levels of quality through following common conventions and reuse
Posted by Scott Ambler on: July 10, 2013 07:38 AM | Permalink

Comments (1)

Please login or join to subscribe to this item
Great insights . I really the continued web..

Please Login/Register to leave a comment.


I hate asking for change. They always make a face. It's like asking them to donate a kidney.

- George Costanza