Category Archives: Enterprise Awareness

Strategies for Tracking Time on Agile Teams

Time Tracking

In Time Tracking and Agile Software Development we overviewed why teams should consider tracking their time.  Primary reasons include:

  • You’re billing your customer by the hour
  • Your organization wants to account for CapEx/OpEx
  • Your organization wants to take advantage of tax credits (typically for R&D work)

A secondary reason to track time is because the team wants to measure where they are spending time so as to target potential areas to improve.  This is more of a side benefit than anything else – if this was your only reason to track time you’d be better off simply discussing these sorts of issues in your retrospectives.  But if you were already tracking time then running a quick report to provide the team with intel likely makes sense for you.

So what are your options for recording time?  Potential strategies, which are compared in the following table, include:

  1. Automated report from an agile management tool. The basic idea is to extract data from an agile management tool (JIRA, TFS, LeanKit, …) and load it into your time tracking system.
  2. Manual input by team members. Each team member, typically once a week, inputs their time into the time tracking tool.
  3. Manual input by the Team Lead. The Team Lead (ScrumMaster) inputs the time for their team into the time tracking tool.
  4. Manual input by a Project Manager/Coordinator. A PM or Project Coordinator, often in a support role to the team, inputs the time of team.
  5. Don’t track time at all. ‘Nuff said.

Table: Comparing options for tracking time.

Strategy Advantages Disadvantages
Automated report from agile management tool
  • Very efficient because it doesn’t require ongoing data input
  • Sufficient for CapEx/OpEx purposes
  • Sufficient for customer billing when the billing units are by the day (or greater)
  • Requires a bit of development work to feed data from your agile management tool into your time tracking system
  • May motivate the team to start treating the agile management tool like a time tracking tool (which often negates the value of the management tool)
  • Often requires a bit of (programmatic) fudging of the data to calculate the time not captured in the tool (such as coordination meetings, demos, retrospectives, …)
  • May require a bit of negotiation with your organization’s auditors (if any)
  • Only an option for teams using agile management tools
  • Works well for teams that are working in a fairly consistent manner (i.e. mature teams that have gelled)
Manual input by team members
  • Potentially the most accurate approach
  • Sufficient for CapEx/OpEx, tax credits, and customer billing
  • Team members often perceive this as an overhead
  • People will be motivated to input what they believe management wants, particularly if any sort of rewards or punishments are thought to be connected
  • Potential for significant expense across the organization (a few minutes per person per week starts to add up) if this gets too detailed or complicated
  • For people working on multiple teams (a question idea anyway) time tracking often becomes onerous
Manual input by Team Lead
  • Shifts the data input burden away from the team
  • Sufficient for CapEx/OpEx and tax credits
  • Likely sufficient for customer billing
  • Not as accurate as other strategies
  • Takes the Team Lead away from leadership tasks
  • Requires the Team Lead to know what is going on within the team (which frankly should be a given)
Manual input by Project Manager/Coordinator
  • Same as manual input by Team Lead
  • Not as accurate as other strategies
  • Likely requires the PM to interview/badger team members to find out what they did during the week
  • Little better than “make work” for the PM
Don’t track time at all
  • No overhead for the team
  • Your organization may be losing out on tax credits

This blog posting was motivated by a conversation that I had with Stacey Vetzal on Twitter.

Related Reading

How “Whole” Are Agile Teams in Practice?

We are often told that agile teams should be whole, that they should have sufficient people, funding, and skills to fulfill their mission.  The idea is that this reduces the dependencies that your team has on others, enabling them to make decisions and to collaborate more effectively.  But, is this actually happening in practice?  Are agile teams truly whole, or do they still need to collaborate with other teams (hopefully productively) to get the job done?  Being strong believers in empiricism over rhetoric we decided to look into this issue.

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following infographic summarizes the findings from the question that explored whether agile delivery teams need to work with external teams or groups to get their work done – in other words, are agile teams truly whole or do they rely on others?  As you can see, 96% of respondents indicated that in practice their team had to work with one or more other teams, leading to the conclusion that very few agile teams appear to be truly whole.

Agile Teams Need to be Enterprise Aware

One of the fundamental principles underlying the Disciplined Agile framework is that disciplined agilists should be enterprise aware – they should recognize that they need to collaborate with others outside of their team, that they should work towards a common organizational vision, and that they should strive to do what is best for the organization and not just what is convenient for them.  Given that agile teams are collaborating with others in practice, it is clear that this philosophy of being enterprise aware is important.

The following diagram presents the results from the survey question in greater detail.  You can obtain the source data, a copy of the original questions, and a slide deck key diagrams at the 2016 Agility at Scale survey page.

Enterprise Awareness

Related Posts:

Time Tracking and Agile Software Development


One of the key aspects of a disciplined agile approach is to be enterprise aware.   The fundamental observation is that your team is only one of many in your organization, except in the case of very small organizations, and as a result should act accordingly.  This means that what your team does should reflect your organization’s overall business and technical roadmaps, that you should strive to leverage as much of the existing infrastructure as possible, that you should try to enhance the existing infrastructure, and that you should work with other teams appropriately so that your overall efforts are complimentary to one another.  This is a straightforward idea conceptually, but in practice acting in an enterprise aware manner can prove more difficult than one would initially think.

Over the years we’ve been asked by several customer organizations to help them to understand how to account for the expense of agile software development.   In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations.   The details of accounting rules vary between countries, but the fundamentals are common.  For public companies capital expenses (CapEx) are preferable because they can boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year).  On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization’s taxes for that year.   Furthermore, in some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature.  In order to get properly account for the expenses incurred by software development teams, and potentially to earn R&D tax credits, you need to keep track of the amount of work performed and the type of work performed to develop a given solution.  Time tracking doesn’t have to be complex: at one customer developers spend less than five minutes a week capturing such information.  The point is that the way that a software developer’s work is accounted for can have a non-trivial impact upon your organization’s financial position.  This in turn implies that the need for agile developers to their track time is a fairly simple example of acting in an enterprise aware manner.

So, I thought I’d run a simple test.  On LinkedIn’s Agile and Lean Software Development group I ran a simple poll to see what people thought about time tracking.  It provided five options to choose from:

  • Yes, this is a valuable activity (33% of responses)
  • Yes, this is a waste of time (39% of responses)
  • No, but we’re thinking about doing so (2% of responses)
  • No, we’ve never considered this (18% of responses)
  • I don’t understand what you’re asking  (5% of responses, one of which was mine so that I could test the poll)

The poll results reveal that we have a long way to go when it comes to working in an enterprise aware manner.  Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity.  When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars.  Looking at it from a dollar per minute point of view, it could be the highest value activity many developers perform that week.

The discussion that ensued regarding the poll was truly interesting.  Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking.  Some comments that stood out for me included:

  • It’s a colossal waste of time unless you’re billing a customer by the hour.
  • We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
  • I think the *most* pointless example was where the managers told us what we should be putting in.
  • One day we will move past the “just do it” mentality and have some meaningful conversations and the reasons for what we do.
  • In my experience time tracking is a massive waste of time. It’s a poor substitute for management.
  • Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
  • Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports.  And they do not believe that Management can resist the temptation to use task hours as a measure.

So what can we make of this?  First, it’s clear that delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they’re doing.  Second, it’s also clear that management needs to communicate more effectively regarding why they’re asking people to track their time.  To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they’re asking for.  Third, management needs to govern more effectively.  Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result).  Fourth, some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and coordination meetings may be preventing people from become enterprise aware because they believe that all of their management needs are being met by these practices.  Finally, many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.

In Summary

Disciplined agilists are enterprise aware.  This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization.  In the anecdote I provided it was clear that some agile developers believe that an activity such as time tracking is a waste, when that clearly doesn’t have to be the case.  Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization.  It makes me wonder if some of the agile rhetoric is getting in our way of being more effective as professionals (and, BTW, there are light-weight options for tracking time available to you).

Related Reading

DevOps Strategies: Enterprise Architecture

DevOps Practices - Enterprise Architecture

The Disciplined Agile Delivery (DAD) framework explicitly includes architecture-related activities, the role of Architecture Owner, and promotes the philosophy of enterprise awareness. Our experience is that agile enterprise architecture proves to be a key enabler for organizations in the process of adopting a Disciplined DevOps mindset.

In addition to general DevOps strategies , there are several enterprise architecture activities that support DevOps:

  • Reuse mindset. An important thing that your enterprise architecture efforts will accomplish is the promotion of a reuse mindset within IT, and throughout your organization in general. Delivery teams with a reuse mindset strive to leverage existing data sources, services, components, frameworks, templates, and many other assets.   This reuse mindset is enabled through education, coaching and mentoring by your enterprise architects (who are ideally active members of IT delivery teams in the role of Architecture Owner).   It is also enabled by technical roadmaps that indicate the technologies that IT delivery teams should, and shouldn’t, be working with. And of course, having high-quality assets that are easy to discover, to understand, and to apply in the course of providing real value to your stakeholders enables reuse.
  • Technical-debt mindset. Your enterprise architecture effort should promote strategies that motivate delivery teams to pay down technical debt when they find it and more important do what they can to avoid it in the first place. Many technical debt strategies are embedded right in the DAD framework, but without a technical-debt mindset this often comes to naught. Enterprise architects, often acting as Architecture Owners on delivery teams, should coach and mentor developers around the issues associated with technical debt. Similarly they should help to educate the senior managers and stakeholders whom they collaborate with in technical debt as well. It requires investment to avoid and remove technical debt, and IT investment decisions are typically in the hands of these people.
  • Development guidelines.  An important aspect of enterprise architecture is the development of guidelines for addressing common concerns across IT delivery teams. Your organization may develop security guidelines, connectivity guidelines, coding standards, and many others. By following common development guidelines your IT delivery teams produce more consistent solutions which in turn makes them easier to operate and support once in production, thereby supporting your DevOps strategy. A potential drawback of common development guidelines is that developers may feel constrained by them. To counteract this problem the guidelines should be developed and evolved in a collaborative manner with the delivery teams, not imposed from above.
  • Technical roadmaps. Your enterprise architecture efforts include the definition, support, and evolution of technical roadmaps that guide the efforts of the rest of the organization (business roadmaps, also important, are the purview of Product Management).  This in turn supports the creation of a common and consistent technical infrastructure within your production environments, enabling common DevOps practices such as continuous deployment, automated end-to-end regression testing, and operational monitoring that we discussed in previous blog postings.

An important aspect of your technical roadmap is to capture both the existing IT infrastructure and the future vision for that infrastructure. Your IT infrastructure potentially includes your network, software services, servers, middleware, and data sources to name a few elements. As you can see in the following diagram, when developing your technical infrastructure vision there are two issues to consider:

  1. Ownership. Does your organization own and operate its own infrastructure or does it outsource some or all of it to external experts?   Outsourcing options include traditional strategies such as having another organization (such as HP or IBM) run your data centers to using cloud-technologies hosted by external organizations (such as Amazon or Google). The advantage of owning your own infrastructure is the greater level of control that it provides you, something that is critical when you must guarantee the security and integrity of your IT solutions. Outsourcing potentially offers greater flexibility in managing your IT infrastructure and cost savings from economies of scale. However, outsourcing requires more sophisticated governance and in the case of traditional strategies is a potential bottleneck when the outsourcer cannot respond in a timely manner to your requests.
  2. Virtualization. Are the elements of your IT infrastructure built to meet the needs of specific solutions or are they softwarized to provide malleability and ease of evolution? With softwarization, also known as software-defined infrastructure (SDI), the elements of your IT infrastructure are fully virtualized. Softwarization includes IT infrastructure models such as a software defined data center (SDDC), software defined storage (SDS), and software defined network (SDN). Softwarization is typically implemented using cloud-based technologies on either side of your firewall. Greater virtualization offers to increase flexibility and programmability of your IT infrastructure, and thereby enabling you to optimize resources.  However, the greater flexibility of virtualization can increase the complexity of your testing efforts and make operational incident simulation more difficult.

IT Infrastructure Strategy Quadrant


Related Readings



There is more to Agile Transformations than Implementing Scrum

SuccessFailureWith some basic agile training and help from an agile coach it can be relatively straightforward to enable several teams to be able to produce increments of consumable software every two weeks.  Unfortunately many organizations stop there, believing that they are “now agile”.

For enterprise agile adoptions starting a few agile teams is the easy part and is just the beginning of your agile transformation.  Proving the benefits and sustaining the change is significantly more challenging.

For illustration purposes, let’s assume that over a six month period we have conducted a series of Disciplined Agile workshops and kickstarted twelve teams.  The teams have separate product owners with their own work item lists.  Some of the teams use the DAD basic Scrum-based lifecycle while others use the DAD Lean lifecycle.  The Scrum teams adapt their lifecycle for their context with the simpler projects having a one week Inception phase while the more complex projects use a two week Inception.  For the Construction phase novice Scrum teams use two week iterations while the more advanced teams chose one week iterations.  The teams vary in size from four to twelve team members.  By rolling out the teams in an incremental fashion, with some coaching the teams have learned the key DAD practices for being effective on both the Scrum and Lean teams.  Word is spreading that the teams are impressing stakeholders with regular demonstrations of new functionality.

However, after the honeymoon period is over, people start to ask some interesting questions such as:

  • What are the limits of self-organization?  I understand that teams are free to customize their own processes but isn’t some consistency good across teams?
  • What are the key milestones for each team?  What is the release schedule for each team?  Are the teams on track for delivering the solution consistent with their Inception vision?  How do I see this information?
  • How do I know which teams have the greatest risks outstanding?
  • What is our product roadmap strategy across teams?
  • How do we measure the effectiveness of one team vs. another?
  • How do we measure the effectiveness of individual team members?
  • What is the new career path for agile team members?
  • How to we adjust compensation plans to encourage effective team behavior and reward individual contributions?
  • Has our quality assurance group adapted for agile to have the appropriate mix of embedded vs independent testers?
  • Do we have less technical debt than before agile?  How do I know if our quality is improving?
  • How do I know that teams are effectively engaging with enterprise authorities such as architecture, data, and quality assurance?
  • How can management use agile and lean principles themselves?

These are all fair questions.  For your agile adoption to be effective and sustainable you need a strategy to address all of these issues.  The Disciplined Agile Manifesto adds a principle to the Agile Manifesto regarding the need to adapt your organizational ecosystem to be effective for enterprise agile adoptions:

The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams

The need for good governance doesn’t go away with agile.  Your stakeholders deserve the right to gauge the health of their investments in your agile initiatives just like any other project.  There are indeed answers and various strategies for all of the above questions which will vary depending on the context of your situation.  Like it or not, the reality is that effective and sustainable agile transformations can take several years in order to achieve the level of capability and maturity that you expect.  A transformation is a journey, not a destination.  Make sure that your agile coaches have answers to the questions above and know what to do after your Scrum honeymoon period is over.  We will outline some DAD strategies for the questions above in future posts.

For a more detailed discussion of how DAD extends Scrum, please read the whitepaper Going Beyond Scrum.

Coordinating activities on agile delivery teams

One of the key characteristics of Disciplined Agile Delivery (DAD) is that it is goal driven.   This simplifies process tailoring, simplifies identifying potential process improvements, reduces the prescription inherent in other software methods, and enables scaling.  One of the process goals identified by the DAD process framework is Coordinate Activities, one of the ongoing goals throughout the delivery effort.  The fundamental question that this goal addresses is what options do individuals on an agile team have to coordinate their work with other people that they are involved with?  Note that this work may not occur completely within the team, that team members may find that they need to coordinate with people external to their team.

The process goal diagram for Coordinate Activities is shown below.  The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues.  The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom.  The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now.  Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

Goal - General - Coordinate activities

An interesting thing about this process goal diagram is that it makes it very clear that there might be a bit more to coordination on an agile team than just holding a short meeting every day.  For example, people may share information within the team, and with people external to the team, via conversations, reviews, and non-solo development techniques such as pair programming or modeling with others.  Another interesting thing is that to avoid the problem of method branding (see The New Deal for Software Development) we use descriptive terms such as Coordination Meeting instead of Scrum Meeting or Daily Scrum.

Several of the issues are team focused, in particular Artifact Ownership and Coordinate Within Team.  Several reflect the fact that DAD teams are enterprise aware and thus describe strategies to coordinate with others external to the team.  For example, your team may need to coordinate with your organization’s enterprise architects and operations staff, potentially adopting some of the strategies captured by Coordinate Across IT (and you are also likely to do so via Share Information strategies).  If your organization has a release organization then your team may need to adopt one or more Coordinate Release Schedule strategies (or, if there’s no release team then your team will still need to coordinate releases with other delivery teams, and with your operations team, somehow).

Several issues address scaling factors.  For example, large teams (often called programmes) will find that they need to adopt strategies called out by Coordinate Within Program.  Teams that are geographically distributed or organizationally distributed will need to consider strategies from Coordinate Between Locations.  Naturally if you don’t face a scaling issue such as geographic distribution then the issue Coordinate Between Locations isn’t something you need to consider.

I wanted to share two important observations about this goal.  First, this goal, along with Explore Initial Scope, Identify Initial Technical Strategy, and Move Closer to a Deployable Release seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

I’m a firm believer that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DAD process decision framework provides this guidance.

Enterprise Awareness over Team Awareness

One of the strengths of the Disciplined Agile Delivery (DAD) framework 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 an IT professional may exhibit:

Enterprise Awareness

  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 IT 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.  While this is beyond the scope of the DAD framework it is a key aspect of the Disciplined Agile Black Belt and ostensibly the Disciplined Agile Green Belt certifications.

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 DAD 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

Disciplined Agilists are Enterprise Aware

Enterprise awareness is one of the key aspects of the Disciplined Agile Delivery (DAD) framework.  The observation is that DAD teams work within your organization’s enterprise ecosystem, as do all other teams.  There are often existing systems currently in production and minimally your solution shouldn’t impact them.  Better yet your solution will hopefully leverage existing functionality and data available in production.   You will often have other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa.  Your organization may be working towards business or technical visions which your team should contribute to.  A governance strategy exists which hopefully enhances what your team is doing.

What it Means to be Enterprise Aware

Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization.  Disciplined agile professionals will:

  • Work closely with enterprise professionals.  This includes working closely with enterprise technical architects and reuse engineers to leverage and enhance the existing and “to be” technical infrastructure; enterprise business architects and portfolio managers to fit into the overall business ecosystem; senior managers who should be governing the various teams appropriately; operations staff to support your organization’s overall development and operations (DevOps) efforts; data administrators to access and improve existing data sources; IT development support people to understand and follow enterprise IT guidance; and business experts who share their market insights, sales forecasts, service forecasts, and other important concerns.  In other words, DAD teams should adopt what Mark refers to as a “whole enterprise” mindset.
  • Adopt and follow enterprise guidance.  Your organization may have, or hopes to one day have, a range of standards and guidelines (guidance) that it wants delivery teams to adopt and follow.  This may include guidance for coding, user interface development, security, and data conventions to name a few.  Following common guidance increases the consistency and maintainability of your solutions, and thus your overall quality.
  • Leverage enterprise assets. There may be many enterprise assets, or at least there should be, which you can use and evolve.  DAD teams strive to work to a common infrastructure; for example, they use the enterprise-approved technologies and data sources whenever possible, and better yet they work to the “to be” vision for your infrastructure.  If your organization uses a disciplined architecture-centric approach to building enterprise software, there will be a growing library of service-based components to reuse and improve upon for the benefit of all current and future solutions.  To do this DAD teams will collaborate with enterprise professionals throughout the lifecycle and particularly during Inception during envisioning efforts.   Figure 1 summarizes the Inception phase goal Align with Enterprise Direction which summarizes the strategies you may choose to follow.  Read Disciplined Agilists Take a Goal-Driven Approach for more information on DAD’s goal-driven strategy.

Figure 1. Inception Goal: Align with Enterprise Direction.
Goal - Inception - Align With Enterprise Direction

  • Enhance your organizational ecosystem. The solution being delivered by a DAD team should minimally fit into the existing organizational ecosystem – the business processes and systems supporting them – it should better yet enhance that ecosystem.  To do this, the first step is to leverage existing enterprise assets wherever possible as described above, often working with enterprise architects to do so. In addition to the enterprise architects DAD teams will also work with operations and support staff closely throughout the lifecycle to ensure that they understand the current state and direction of the organizational ecosystem.  DAD teams will often be supported by an additional independent test team that will perform production integration testing (amongst other things) to ensure that your solution works within the target production environment which it will face at deployment time.  Furthermore, experienced DAD teams will even fix problems that they run into via proven refactoring techniques.  Figure 2 summarizes the general goal Leverage and Enhance Existing Infrastructure which summarizes strategies for how DAD teams may accomplish this.

Figure 2. General Goal: Leverage and Enhance Existing Infrastructure.
Goal - General - Leverage and Enhance Existing Infrastructure

  • Adopt a DevOps Culture. DAD teams will work with operations and support staff closely throughout the lifecycle, particularly the closer you get to releasing into production.  DevOps culture and strategies are baked right into DAD, a topic for a future blog posting.
  • Share learnings.  DAD teams are learning oriented, and one way to learn is to hear about the experiences of others.  The implication is that DAD teams must also be prepared to share their own learnings with other teams.  To do this organizations might choose to support agile discussion forums, informal presentations, training sessions delivered by senior team members, and internal conferences to name a few strategies.
  • Adopt appropriate governance strategies.  Effective governance strategies should enhance that which is being governed. An appropriate approach to governing agile delivery projects, and we suspect other types of efforts, is based on motivating and then enabling people to do what is right for your organization. What is right will of course vary, but this typically includes motivating teams to take advantage of, and to evolve, existing corporate assets following common guidelines to increase consistency, and working towards a shared vision for your organization. Appropriate governance is based on trust and collaboration. Appropriate governance strategies should enhance the ability of DAD teams to deliver business value to their stakeholders in a cost effective and timely manner.  Unfortunately many existing IT governance strategies are based on a command-and-control, bureaucratic approach which often proves ineffective in practice. The DAD book explores appropriate governance, the impact of traditional governance strategies, and how to adopt an appropriate governance strategy in detail.  The article Adopting Agile Governance Requires Discipline also provides greater insight.
  • Open and honest monitoring. Although agile approaches are based on trust, smart governance strategies are based on a “trust but verify and then guide” mindset.  An important aspect of appropriate governance is the monitoring of project teams through various means.  One strategy is for anyone interested in the current status of a DAD project team to attend their daily coordination meeting and listen in, a strategy promoted by the Scrum community.  Although it’s a great strategy we highly recommend, it unfortunately doesn’t scale very well because the senior managers responsible for governance are often busy people with many efforts to govern, not just your team.  Hence the need for more sophisticated strategies such as an “development intelligence” approach supported via automated dashboards.  More on this in a future blog posting too.

Why is Enterprise Awareness Important?

Enterprise awareness is important for several reasons.  First, you can reduce overall delivery time and cost by leveraging existing assets.  In other words, DAD teams can spent less time reinventing the wheel and more time producing real value for their stakeholders.  Second, by working closely with enterprise professionals DAD teams can get going in the right direction easily.  Third, it increases the chance that your delivery team will help to optimize the organizational whole, and not just the “solution part” that it is tasked to work on.  As the lean software development movement aptly shows this increases team effectiveness by reducing time to market.

Challenges to Enterprise Awareness

Unfortunately there are two main challenges to supporting enterprise awareness on agile teams.  First is the cultural challenge within the agile community that some “agile purists” perceive this as unecessary overhead.  Reasons for this misunderstanding include a lack of understanding of the overall enterprise picture or some agilists who have previous experiences with enterprise professionals who struggle to work in an agile manner.  This points to the second challenge that enterprise professionals often don’t understand how to work effectively with agile teams.  Sometimes this is because the agile teams they’ve been working with until now haven’t been sufficiently disciplined to work with them effectively, but more often than not it’s because they still choose to follow older, more traditional approaches to their craft (they may find my articles about Agile Enterprise Architecture, Agile Enterprise Administration, and even The Enterprise Unified Process to be illuminating).

These challenges are cultural in nature, and thus difficult to overcome.  Agilists and enterprise professionals need to respect one another and strive to learn more about what the other group is trying to accomplish.  They must strive to work with one another and thus learn from each other.  Furthermore, they must build a culture of shared commitment and responsibility to the organization.  Not only is this possible it is highly desirable.

In summary, DAD teams and more importantly DAD practitioners are enterprise aware.  They recognize that enterprise aware strategies improve their ability to provide value to their stakeholders both within the scope of a solution as well as at the organizational level.  To coin an environmental cliché: Disciplined agilists act locally and think globally.

Material for this blog posting was modified from Discplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise by Scott W. Ambler and Mark Lines (IBM Press, 2012)

Adopting Agile Governance Requires Discipline

Governance establishes chains of responsibil­ity, authority and communication in support of the overall enterprise’s goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles that people play with and within the department.

Governance and management are two different things. Governance looks at a team from the outside, treating it as a system that needs to have the appropriate structure and processes in place to provide a stream of value. Management, on the other hand, occurs inside the team and ensures that the structure and processes are implemented effectively.  The Disciplined Agile Delivery (DAD) process framework characterizes governance as an element of enterprise awareness from the team’s point of view because governance looks at the team from the outside.

It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams.  As we described in the book every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives.  It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.

Our experience is that the most effective way to govern agile teams is to focus on collaborative strategies that strive to enable and motivate team members implicitly. For example, the traditional approach to motivating a team to provide good ROI would be to force them to develop and commit to an “accurate” project budget, and then periodically review their spending to ensure they’re on track. An agile approach would be to ask the team to provide a ranged estimate of what they believe the cost will be so as to set expectations about future funding requirements.  Then the team works in priority order as defined by their stakeholders, visibly providing real business value through the incremental delivery of a potentially consumable solution.  Costs are tracked via the team’s burn rate (the fully burdened cost of the people on the team plus any capital outlays for equipment or facilities) and value is tracked by the stakeholders’ continuing satisfaction (hopefully) with what the team is delivering for that cost.  In short, a traditional approach often measures financial progress against a budget whereas an agile approach seeks to maximize stakeholder value for their investment by always working on the most valuable functionality at the time.

The DAD framework includes several important agile governance strategies:

  • Adopting a risk-value driven lifecycle
  • Explicit, light-weight milestone reviews
  • Agile enterprise teams that work closely with agile teams
  • Regular coordination meetings (daily standups in Scrum)
  • Iteration/sprint demos
  • All-hands demos
  • Follow enterprise guidelines (coding standards, UI standards, data conventions, …)
  • Retrospectives, and better yet measured improvement
  • Increased stakeholder visibility
  • Development intelligences (BI for IT)
  • Aligning agile team governance with other governance (operations, security, data, …) strategies
  • Agile measurement/metrics programs
  • Active risk mitigation
  • Named phases
  • Robust role definitions

Many of the strategies described above are “standard” agile governance strategies, and a few are unique to DAD.  It requires discipline to adopt and then execute on effective governance strategies, particularly in organizations where you already have a strong traditional governance program in place.

Enterprise Awareness Requires Discipline

Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly.  It takes discipline to work with enterprise professionals such as enterprise architects, data administrators, portfolio managers, or IT governance people who may not be completely agile yet, and have the patience to help them.  It takes discipline to work with your operations and support staff in a DevOps manner throughout the lifecycle, particularly when they may not be motivated to do so.

Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DAD adoption, these authorities serve important functions in any large enterprise.  Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.

Although it takes discipline to work in an enterprise aware manner, the payoff can be dramatic.  Enterprise architects can help guide your team early in the lifecycle to adopt a viable architecture strategy.  Portfolio managers can help to govern your team to ensure that you truly are spending the stakeholder’s investment wisely.  Enterprise administators, including data management professionals and operations professionals, can help you to leverage existing legacy assets.  These are just a few examples of the potential ways that enterprise professionals can help a DAD team work more effectively.