In Time Tracking and Agile Software Development we overviewed why teams should consider tracking their time. Primary reasons include:
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:
Table: Comparing options for tracking time.
This blog posting was motivated by a conversation that I had with Stacey Vetzal on Twitter.
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.
One of the fundamental principles underlying the Disciplined Agile (DA) toolkit 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.
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:
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:
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.
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).
The Disciplined Agile (DA) toolkit 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:
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:
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.
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 DA toolkit provides this guidance.