Agility@Scale: Strategies for Scaling Agile Software Development

I was recently involved in an online discussion about how to calculate the benefits realized by software development teams.   As with most online discussions it quickly devolved into camps and the conversation didn’t progress much after that.  In this case there was what I would characterize as a traditional project camp and a much smaller agile/lean product camp.  Although each camp had interesting points, the important thing for me in the conversation was the wide cultural and experience gap between the people involved in the conversation.

The following diagram summarizes the main viewpoints and the differences between them.  The traditional project camp promoted a strategy where the potential return on investment (ROI) for a project would be calculated, a decision would be made to finance the project based (partly) on that ROI, the project would run, the solution delivered into production, and then at some point in the future the actual ROI would be calculated.  Everyone was a bit vague on how the actual ROI would be calculated, but they agreed that it could be done although would be driven by the context of the situation.  Of course several people pointed out that it rarely works that way.  Even if the potential ROI was initially calculated it would likely be based on wishful thinking and it would be incredibly unlikely that the actual ROI would be calculated once the solution was in production.  This is because few organizations are actually interested in investing the time to do so and some would even be afraid to do so.  Hence the planned and actual versions of the traditional strategy in the diagram.

The agile/lean camp had a very different vision.  Instead of investing in upfront ROI calculation, which would have required a fair bit of upfront requirements modelling and architectural modelling to get the information, the idea was that we should instead focus on a single feature or small change.  If this change made sense to the stakeholders then it would be implemented, typically on the order of days or weeks instead of months, and put quickly into production.  If your application is properly instrumented, which is becoming more and more common given the growing adoption of DevOps strategies, you can easily determine whether the addition of the new feature/change adds real value.

Cultural differences get in your way  

The traditional project camp certainly believed in their process.  In theory it sounded good, and I’m sure you could make it work, but in practice it was very fragile.  The long feedback cycle, potentially months if not years, pretty much doomed the traditional approach to measuring benefits of software development to failure. The initial ROI guesstimate was often a work of fiction and rarely would it be compared to actuals.  The cultural belief in bureaucracy motivated the traditional project camp to ignore the obvious challenges with their chosen approach.

The agile/lean camp also believed in their strategy.  In theory it works very well, and more and more organizations are clearly pulling this off in practice, but it does require great discipline and investment in your environment.  In particular, you need investment in modern development practices such as continuous integration (CI), continuous deployment (CD), and instrumented solutions (all important aspects of a disciplined agile DevOps strategy).  These are very good things to do anyway, it just so happens that they have an interesting side effect of making it easy (and inexpensive) to measure the actual benefits of changes to your software-based solutions.  The cultural belief in short feedback cycles, in taking a series of smaller steps instead of one large one, and in their ability to automate some potentially complex processes motivated the agile/lean camp to see the traditional camp as hopeless and part of the problem.  

Several people in the traditional project camp struggled to understand the agile/lean approach, which is certainly understandable given how different that vision is compared with traditional software development environments.  Sadly a few of the traditionalists chose to malign the agile/lean strategy instead of respectfully considering it.  They missed an excellent opportunity to learn and potentially improve their game.  Similarly the agilists started to tune out, dropping out of the conversation and forgoing the opportunity to help others see their point of view.  In short, each camp suffered from cultural challenges that prevented them from coherently discussing how to measure the benefits of software development efforts.

How Should You Measure the Effectiveness of Software Development?

Your measurement strategy should meet the following criteria:

1. Measurements should be actioned.  Both the traditional and agile/lean strategies described above meet this criteria in theory.  However, because few organizations appear willing to calculate ROI after deployment as the traditional approach recommends, in practice the traditional strategy rarely meets this criteria.  It is important to note that I used the word actioned, not actionable.  Key difference.
2. There must be positive value.  The total cost of taking a measure must be less than the total value of the improvement in decision making you gain.  I think that the traditional strategy falls down dramatically here, which is likely why most organizations don’t actually follow it in practice.  The agile/lean strategy can also fall down WRT this criterion but is much less likely to because the feedback cycle between creating the feature and measuring it is so short (and thus it is easier to identify the change in results to the actual change itself).
3. The measures must reflect the situation you face.  There are many things you can measure that can give you insight into the ROI of your software development efforts.  Changes in sales levels, how often given screen or function is invoked, savings incurred from a new way of working, improved timeliness of information (and thereby potentially better decision making), customer retention, customer return rate, and many others.  What questions are important to you right now?  What measures can help provide insight into those questions?  It depends on the situation that you face, there are no hard and fast rules.  For a better understanding of complexity factors faced by teams, see The Software Development Context Framework.
4. The measures should be difficult to game.  Once again, traditional falls down here.  ROI estimates are notoriously flakey because they require people to make guesses about costs, revenues, time frames, and other issues.  The measurements coming out of your instrumented applications are very difficult to game because they’re being generated as the result of doing your day-to-day business.  
5. The strategy must be compatible with your organization.  Once again, this is a “it depends” type of situation.  Can you imagine trying to convince an agile team to adopt the traditional strategy, or vice versa?  Yes, you can choose to improve over time.  

Not surprisingly, I put a lot more faith in the agile/lean approach to measuring value.  Having said that, I do respect the traditional strategy as there are some situations where it may in fact work. Just not as many as traditional protagonists may believe.

1. Be crystal clear about what "not-for-profit" actually means.  This is a wonderfully deceptive term from the US tax system which can make organizations appear far more virtuous than they actually are, which is particularly easy in situations where the audience doesn't have a sophisticated knowledge of finance.  Not that I'm implying anything.  Although we have taken some steps to explain the implications of what being a "not-for-profit" organization means, we could do a lot more by being less self-serving.  Yes, the SA isn't a for-profit organization.  The implication of this being that we need to spend the money we rake in, but it doesn't imply that as individuals we can't make a lot of money via our SA work.  I'm not taking on the position of Managing Director for free after all, and I'm sure that previous MDs have found the position lucrative.
   
2. Publish our salaries.  To live the high standards which we espouse through our rhetoric, we're going to be very clear about the way that we operate.  This includes publishing the salaries of the employees of the SA and the revenue derived from Scrum training of all of our certified trainers. Part of being respectful to our membership is to be clear about how we spend their hard-earned money.
3. Publish how we spend the rest of the money.  After we pay ourselves, how much do we really spend on supporting user groups, education, and research as we claim?  Don't you think you deserve to know?  I certainly do, which is why we're going to ensure our finances are no longer opaque.  With tens of thousands of members and/or "certified masters" running around out there, it's pretty clear that we making a lot of money.  To guarantee that money is being spent appropriately we're going to share with our membership where it's coming from and going to.
4. Publish our meeting minutes.  This will be both in written form, e.g. traditional meeting minutes, as well as recorded form (ideally video but at least audio).  The only way that our membership can be assured that we're working in an ethical and integral manner is through complete visibility into our operations.

The fundamental idea here is that the Scrum Alliance should have nothing to hide from our membership. We've preached open and honest communication for years, now we're going to start actually living by those words.  Yes, it may be a bit painful to work to this level of clarity, but we feel that you deserve this.

1. Increase investment in research.  Although we've big claims about support Scrum research over the years, very little has actually come of this due to lack of funding (see discussion of salaries above) which can be seen in the serious lack of research results posted at the SA site.  Of the six publications at the site tagged as research results, three were performed by Carnigie Mellon University, the home of the Software Engineering Institute, producers of the CMMI.  Although I personally respect the work surrounding the CMMI, not that I agree with all of it, I'm concerned about relying on CMU for half of our Scrum research results.  We can and should do a lot better, and the first step is to divert some funds away from our own pockets into research.  Having actual empirical results, as opposed to espousing rhetoric about empiricism, will go a long way towards more respectful behavior via actual fact-based discussions.  Until then, you may find my IT Survey Results page to be a valuable resource. 
2. Deprecate the Certified ScrumMaster (CSM) certification.  Although I would prefer to end this embarrassment immediately, we need to be respectful of the fact that CSM courses have been scheduled several months in advance and some people have already paid for seats in them.  So, as of June 30th 2011 the CSM certification will be deprecated.  This should give our Certified Scrum Trainers time to rework their business models and focus on more respectable activities.
3. Existing CSMs must clarify the certification.  People who have previously "earned" the CSM designation will be grandfathered in until December 21st, 2012 in accordance with the Mayan Calendar.  However, until that time all CSMs who choose to indicate their designation publicly (many CSMs choose not to) in email signatures, business cards and so on must now use the following wording - "Certified ScrumMaster (earned by staying awake during a two/three day training course)".  This wording reflects our new desire for clear and open communication as well as for being respectful.  Far too many people are fooled by the terms "certified" and "master" and we're going to do our best to reduce this problem through greater clarity.

I'm happy to announce that A Practical Guide to Distributed Scrum by Elizabeth Woodward, Steffan Surdek, and Matthew Ganis is now in print.  I've been talking this book up in presentations and with customers the past few months and promised that I would let everyone know once it was available.  I was one of several people who wrote forewords for the book, Ken Schwaber, Roman Pichler, and Matthew Wang also did so, and I've modified my foreword below to help you to understand a bit better what the book is about.

If you’re thinking about buying this book, you’re probably trying to answer one or more of the following questions: “What will I learn?”, “Should I spend my hard earned money on this book?”, “Will it be worth my valuable time to read it?”, and “Is this a book that I’ll refer to again and again?” To help you answer these questions, I thought I’d list a few user stories which I believe this book clearly fulfills:
As a reader I want:

• a book that is well-written and understandable real-world examples that I can relate to
• quotes from actual people doing this in the field
• to understand the challenges that I’ll face with distributed agile development

As someone new to agile I want to:

• learn the fundamentals of Scrum
• understand the fundamentals of agile delivery
• learn about what actually works in practice
• discover how extend Scrum into an agile delivery process

As an experienced agile practitioner I want to learn:

• how to scale agile approaches for distributed teams
• how to overcome the challenges faced by distributed teams
• how to tailor existing agile practices to reflect the realities of distribution
• bout “new” agile practices which we might need to adopt
• techniques so that distributed team members can communicate effectively
• how to extend Scrum with proven techniques from Extreme Programming, Agile Modeling, and other agile methods
• how to address architectural issues on a distributed agile team
• how agile teams address documentation
• how agile teams can interact effectively with non-agile teams

As a Scrum Master I want to learn how to:

• lead a distributed agile team
• facilitate a distributed “Scrum of Scrums”
• facilitate the successful initiation of a distributed agile project
• facilitate communication and collaboration between distributed team members

As a Product Owner I want to learn:

• how to manage a product backlog on a distributed team
• about different categories of stakeholders whom I will need to represent
• about techniques to understand and capture the goals of those stakeholders
• how to manage requirements with other product owners on other sub-teams
• what to do during an end-of-sprint review
• how I can streamline things for the delivery team that I’m working with

As an agile skeptic I want to:

• see examples of how agile works in practice
• hear about the challenges faced by agile teams
• hear about where agile strategies don’t work well and what to do about it

I work with organizations around the world helping them to scale agile strategies to meet their real-world needs. Although this book is focused on providing strategies for dealing with geographical distribution, it also covers many of the issues that you’ll run into with large teams, complex problem domains and complex technical domains. An important aspect of scaling agile techniques is to first recognize that’s there’s more to scalability than dealing with large teams, something which this book clearly demonstrates.

At the risk of sounding a bit corny, I’ve eagerly awaited the publication of this book for some time. I’ve known two of the authors, Elizabeth and Matt, for several years and have had the pleasure of working with them and learning from them as a result. Along with hundreds of other IBMers I watched this book get written and provided input where I could.  The reason why I’m so excited about it is that I’ve wanted something that I could refer the customers to that I work with and honestly say, “yes, we know that this works because this is what we do in practice”.

IBM is doing some very interesting work when it comes to scaling agile. We haven’t published enough externally, in my opinion, due to a preference for actively sharing our experiences internally. This book collects many of our experiences into a coherent whole and more importantly shares them outside the IBM process ecosystem. Bottom line is that I think that you’ll get a lot out of this book.

Related Reading:

• Software Development Context Framework
• Geographically Distributed Agile Teams

 

At IBM Rational we define disciplined agile delivery as:

Disciplined agile delivery is an evolutionary (iterative and incremental) approach which regularly produces high quality solutions in a cost effective and timely manner via a risk and value driven life cycle. It is performed in a highly collaborative, disciplined, and self-organizing manner within an appropriate governance framework, with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders to maximize business value provided. Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.

Let’s explore the key points in this definition:

1. Full delivery life cycle.  Disciplined agile delivery processes have life cycles which are serial in the large and iterative in the small.  Minimally they have a release rhythm which recognizes the need for start up/inception activities, construction activities, and deployment/transition activities.  Better yet, they include explicit phases as well. It is very important to note that these are not the traditional waterfall phases – requirements, analysis, design, and so on – but instead different “seasons” of a project. The point is that we need to look beyond agile software development and consider the full complexities of solution delivery.  Adopting a full delivery life cycle, not just a construction life cycle, is arguably the “zeroth” agile scaling factor. 
2. Evolutionary.  Agile strategies are both iterative and incremental in nature.  Iterative means that you are working in a non-serial manner, on any given day you may do some requirements analysis, some testing, some programming, some design, some more testing, and so on.  Incremental means that you add new functionality and working code to the most recent build, until such time as the stakeholder determines there is enough value to release the product.
3. Regularly produces high quality solutions. Agilists are said to be quality focused.  They prefer to test often and early, and the more disciplined ones even take a test-first approach where they will write a single test and the just enough production code to fulfill that test (then they iterate). Many agile developers have adopted the practice of refactoring, which is a technique where you make simple changes to your code or schema which improves its quality without changing its semantics.  Adoption of these sorts of quality techniques seems to work – it appears that agile teams are more likely to deliver high quality systems than traditional teams (according to the DDJ 2008 Project Success survey). Within IBM we take it one step further and focus on consumability, which encompasses quality and other features such as ease of deployment and system performance.  Furthermore, although some agile methods promote the concept of producing “potentially shippable software” on a regular basis, disciplined agile delivery teams produce solutions: a portion of which may be software, a portion of which may be hardware, and a portion of which will be the manner in which the system is used.
4. Cost effective and timely manner.  Agile teams prefer to implement functionality in priority order [http://www.agilemodeling.com/essays/prioritizedRequirements.htm], with the priority being defined by their stakeholders (or a representative thereof).  Working in priority order enables agile teams to maximize the return on investment (ROI) because they are working on the high-value functionality as defined by their stakeholders, thereby increasing cost effectiveness. Agile teams also prefer to produce potentially shippable solutions each iteration (an iteration is a time-box, typically 2-4 weeks in length), enabling their stakeholders to determine when they wish to have a release delivered to them and thereby improving timeliness.  Short iterations reduce the feedback cycle, improving the chance that agile teams will discover problems early (they “fail fast”) and thereby enable them to address the problems when they’re still reasonably inexpensive to do so.  The DDJ 2008 Project Success survey found that agile teams are in fact more likely to deliver good ROI than traditional teams and more likely to deliver in a timely manner.
5. Value driven life cycle. One result of building a potentially shippable solution every iteration is that agile teams produce concrete value in a consistent and visible manner throughout the life cycle. 
6. Risk and value driven life cycle.  Core agile processes are very clear about the need to produce visible value in the form of working software on a regular basis throughout the life cycle.  Disciplined agile delivery processes take it one step further and actively mitigate risk early in the life cycle – during project start up you should come to stakeholder concurrence regarding the project’s scope, thereby reducing significant business risk, and prove the architecture by building a working skeleton of your system, thereby significantly reducing technical risk.  They also help with transition to agile, allowing traditional funding models to use these milestones before moving to the finer grained iteration based funding that agile allows.
7. Highly collaborative.  People build systems, and the primary determinant of success on a development project is the individuals and the way that they work together.  Agile teams strive to work closely together and effectively as possible.  This is a characteristic that applies to both engineers on the team, as well as their leadership.
8. Disciplined.  Agile software development requires greater discipline on the part of practitioners that what is typically required by traditional approaches. 
9. Self organizing. This means that the people who do the work also plan and estimate the work.
10. Self-organization within an appropriate governance framework. Self-organization leads to more realistic plans and estimates which are more acceptable to the people implementing them.  At the same time these self-organizing teams must work within an appropriate governance framework which reflects the needs of their overall organizational environment.  An “appropriate governance framework” explicitly enables disciplined agile delivery teams to effectively leverage a common infrastructure, to follow organizational conventions, and to work towards organizational goals.  The point is that project teams, regardless of the delivery paradigm they are following, need to work within the governance framework of their organization.  More importantly, effective governance programs should make it desirable to do so.  Our experience is that traditional, command-and-control approaches to governance where senior management explicitly tells teams what to do and how to do it don’t work very well with agile delivery teams.  We’ve also found that lean development governance, an approach which is based on collaboration and enablement, is far more effective in practice.  Good governance increases the chance that agile delivery teams will build systems which fit into your overall organizational environment, instead of yet another stand-alone system which increases your overall maintenance burden and data quality problems.
11. Active stakeholder participation.  Agile teams work closely with their stakeholders, who include end users, managers of end users, the people paying for the project, enterprise architects, support staff, operations stuff, and many more.  Within IBM we distinguish between four categories of stakeholder: principles/sponsors, partners (business partners and others), end users, and insiders These stakeholders, or their representatives (product owners in Scrum, or on-site customers in Extreme Programming, or a resident stakeholder in scaling situations), are expected to provide information and make decisions in a timely manner.
12. Changing needs of stakeholders.  As a project progresses your stakeholders will gain a better understanding of what they want, particularly if you’re showing them working software on a regular basis, and will change their “requirements” as a result.  Changes in the business environment, or changes in organization priority, will also motivate changes to the requirements.  There is a clear need for agile requirements change management [http://www.agilemodeling.com/essays/changeManagement.htm] on modern IT projects.
13. Repeatable results.  Stakeholders are rarely interested in how you delivered a solution but instead in what you delivered.  In particular, they are often interested in having a solution which meets their actual needs, in spending their money wisely, in a high-quality solution, and in something which is delivered in a timely manner.  In other words, they’re interested in repeatable results, not repeatable processes.
14. Right amount of ceremony for the situation.  Agile approaches minimize ceremony in favor of delivering concrete value in the form of working software, but that doesn’t mean they do away with ceremony completely. Agile teams will still hold reviews, when it makes sense to do so.  DDJ’s 2008 Modeling and Documentation Survey found that agile teams will still produce deliverable documentation, such as operations manuals and user manuals, and furthermore are just as likely to do so as traditional teams.  The DDJ September 2009 State of the IT Union survey found that the quality of the documentation delivered by agile teams was just as good as that delivered by traditional teams, although iterative teams (e.g. RUP teams) did better than both agile and traditional.

 Suggested reading:

• The Agile System Delivery Life Cycle (SDLC)
• The Agile Scaling Model (ASM): Adapting Agile Methods for Complex Environments (an IBM Rational white paper)
• The Disciplined Agile Delivery (DAD) home page
  

I recently wrote a detailed article about Large Agile Teams that was a detailed walkthrough of how to structure agile teams of various sizes.  I suspect that this is the most comprehensive online discussion of this topic.  The article addressed the following topics:

1. Organizing Agile Teams.  The article starts with a summary of the results of some industry research that I've done regarding the size of agile teams, showing that agile techniques are in fact being successfully applied on a variety of team sizes.  It then goes into detail describing the organization structure of agile teams at various sizes.  The article starts with a discussion of small agile teams, covering the common rhetoric of how to organize such a team and then making observations about what actually happens in practice.  It then walks through two approaches to organizing medium sized teams of 15 to 50 people - a structure for a single team and a structure for a team of teams.  Finally, it walks through how to organize a large agile program of 50+ people, focusing a fair bit on the need for a leadership team to coordinate the overall activities within the program.  This advice is similar to what is seen in the SAFe framework although proves to be a bit more flexible and pragmatic in practice.
2. Supporting Large Agile Teams.  The leadership structure to support a large agile team is reasonably straightforward once you understand the issues that such a team faces.  In this section the article overviews the need for three important sub teams within your overall leadership team: The Product Delivery Team, The Product Management Team, and The Architecture Team.  It also describes the need for an optional Independent Testing/Integration Team, something misleadingly labeled an integration team in SAFe, that reflects some of the known agile testing and quality practices that I've been writing about for several years.
3. Organizing subteams.  The article includes a detailed discussion for how to organize the work addressed by agile sub teams within a large agile program.  These strategies include feature teams, component teams, and internal open source teams.  As you would expect with the Disciplined Agile Delivery (DAD) framework, the article clearly summarizes the advantages and disadvantages of each approach on provides guidance for when (not) to apply each one.  I suspect you'll find this portion of the article to be one of the most coherent discussions of the Feature vs. Component team debate.
4. Tailoring agile practices.  The article provides a detailed overview of how the various DAD process goals are tailored to address the issues faced by large teams.  This advice includes:  Do a bit more up-front requirements exploration; Do a bit more up-front architectural modelling; Do a bit more initial planning; Adopt more sophisticated coordination activities; Adopt more sophisticated testing strategies; and Integrate regularly.  My hope is that you find this part of the article very illuminating regarding how the DAD framework provides flexible and lightweight advice for tailoring your approach to address the context of the situation that you face.
5. Other Resources.  The article ends with a collection of links to other resources on this topic.

I welcome any feedback that you may have about Large Agile Teams.

Recently I have 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.  In order to get properly account for the costs incurred by software development teams 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.

 

Why is Time Tracking Potentially Valuable?

There are several financial issues to be aware of:

• Capitalization. For public companies capital expenses (CapEx) can potentially 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.
• Matching. One of the goals of good accounting is to accurately reflect the net income of the enterprise and to prevent income manipulation or "smoothing". As such a key tenet is the principle of matching revenues with the appropriate expenses. For software this means that we expense the cost of the software over the lifetime of the asset against the income at that time. An implication of this is that capitalizing software development, when appropriate, before the software goes into production clearly violates the matching principle since there is no benefit of the asset until such time.
• Tax Credits.  In some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature.

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.

 

What Do Agilists Think of Time Tracking?

So, I thought I'd run a simple test. Last week on LinkedIn's Agile and Lean Software Development group I ran a poll to see what people thought about time tracking. The poll provided five options (a limitation of LinkedIn Polls) 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. 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 that a developer performs in a given 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.

I think that there are several interesting implications from this discussion:

1. Agilists need to become more enterprise aware. It's clear to be really effective that agile delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they're doing.  In Disciplined Agile Delivery (DAD) this is something that we refer to as being enterprise aware.  There's far more to enterprise awareness than understanding pertinent accounting principles, for interest disciplined agile teams work towards a common technology roadmap and common business roadmap, but appreciating why time tracking is a potentially valuable activity would be a good start.
2. Management needs to communicate better.  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.
3. 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).
4. Time tracking should be streamlined.  It was obvious from the conversation that several people worked in organizations where the time tracking effort had gotten completely out of hand.  Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much.  Over the years I've helped organizations design measurement programs and I've seen a lot of well-intention efforts become incredibly onerous and expensive for the people they were inflicted upon.  I suspect it's time for a reality check in some of these organizations people were alluding to.  A good heuristic is that for any measurement you should be able to indicate the real cost of collecting it, the use(s) that the information is being put to, and the value resulting from those uses.  If you can't quickly and coherently do that then you need to take a hard look at why you continue to collect that metric.  The lament "we might need it one day" is a symptom that you're wasting time and money.
5. Agile rhetoric is getting in the way.  Some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and stand up meetings may be preventing people from becoming enterprise aware because they believe that all of their management needs are being met by them.
6. You may be missing out on the benefits of time tracking.  Many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.

 

Parting Thoughts

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 many 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.

Granted, time tracking on an agile project team is nowhere near as sexy as topics such as continuous integration (CI), TDD, the definition of done, continous architecture, or many more.  But you know what?  Although it's a mind-numbingly mundane issue it is still an important one. 'Nuff said (I hope).

 

Related Reading

• Time Tracking and Agile Software Development
• Strategies for Tracking Time on Agile Teams

 

 

The basic idea behind DevOps is that your development strategy and operations strategy should reflect one another, that you should strive to optimize the whole IT process.  This implies that development teams should work closely with your operations staff to deliver new releases smoothly into production and that your operations staff should work closely with development teams to streamline critical production issues.

DevOps has its source in agile software development, and it is an explicit aspect of the Disciplined Agile Delivery (DAD) process framework.  As a result there is a collection of agile development strategies which enable effective DevOps throughout the agile delivery lifecycle.  These strategies include:

1. Initial requirements envisioning.  Disciplined agile teams invest time at the beginning of the project to identify the high-level scope in a light-weight, collaborative manner.  This includes common operations requirements such as the need to backup and restore data sources, to instrument the solution so that it can be monitored in real time by operations staff, or to architect the solution in a modular manner to enable easier deployment. 
2. Initial architecture envisioning. Disciplined agile teams will also identify a viable architectural strategy which reflects the requirements of their stakeholders and your organization’s overall architectural strategy (hence the need to work closely with your enterprise architects and operations staff).  One goal is to ensure that the team is building (or buying) a solution which will work well with the existing operational infrastructure and to begin negotiating any infrastructural changes (such as deploying new technologies) early in the project.   Another goal is to ensure that operations-oriented requirements are addressed by the architecture from the very start. 
3. Initial release planning.  As part of release planning the disciplined agile team works closely with their operations group to identify potential release windows to aim for, any release blackout periods to avoid, and the need for operations-oriented milestone reviews later in the lifecycle (if appropriate).
4. Active stakeholder participation.  Disciplined agile teams work closely with their stakeholders, including both operations and support staff, all the way through the lifecycle to ensure that their evolving needs are understood.   
5. Continuous integration (CI).  This is a common technical agile practice where the solution is built/compiled, regression tested, and maybe even run through code analysis tools.  CI promotes greater quality which in turn enables easier releases into production.  
6. Parallel independent testing. For enterprise-class development or at scale, particularly when the domain or technology is very complex or in regulatory environments, disciplined agile team will find they need to support their whole team testing efforts with an independent test team running in parallel to the development team.  These testing issues often include validation of non-functional requirements – such as security, performance, and availability concerns – and around production system integration.  All of these issues are of clear importance for operations departments.   
7. Continuous deployment.  With this practice you automate the promotion of your working solution between environments.  By automating as much of the deployment effort as possible, and by running it often, the development team increases the chance of a successful deployment and thereby reduces the risk to the operations environment. Note that deployment into production is generally not automatic, as this is an important decision to be made by your operations/release manager(s). 
8. Continuous documentation.  With this practice supporting documentation, including operations and support documentation, is evolved throughout the lifecycle in concert with the development of new functionality. 
9. Production release planning.  This is the subset of your release planning efforts which focuses on the activities required to deploy into production. 
10. Production readiness reviews.  There should be at least one review, performed by the person(s) responsible for your operations environment, before the solution is deployed into production.  The more critical the system, the more product readiness reviews may be required. 
11. End-of-lifecycle testing.  Minimally you will need to run your full automated regression test suite against your baselined code once construction ends.  There may also be manual acceptance reviews or testing to be performed, and any appropriate fixing and retesting required to ensure that the solution is truly ready for production. 

For more detail about this topic, I think that you will find the article I wrote for the December 2011 issue of Cutter IT Journal entitled “Disciplined Agile Delivery and Collaborative DevOps” to be of value.

•  People are assigned to a single team
•  Development teams have easy access to business expertise
• Development teams are organized for agile delivery (not traditional)
• Your organization has an agile support group/community of excellence
• Your organization is explicitly addressing barriers to agility
• There is executive sponsorship for agile
• Agile teams are measured on value creation
• Your organization's IT governance strategy includes an agile path
  

There is a fair bit of rhetoric surrounding agile methods, some of which we subscribe to and some of which we don’t. We’d like to briefly examine the rhetoric which we’ve found to be the most misleading for people trying to be effective at adopting agile techniques. The following list is in the format X but Y, where X is the rhetoric and Y is the strategy promoted by the Disciplined Agile Delivery (DAD) process framework. This includes:

1. Requirements evolve throughout the lifecycle BUT the scope should still be agreed to at the beginning of the project. There has to be an initial vision for a project, a vision which your stakeholders should help define and then agree to, and to come to that vision you will need to perform some initial requirements envisioning. A list of high level features is part of this initial vision. Yes, the details are very likely to evolve over time but the fundamental goals of your project and scope of your effort needs to be defined early in your project. In a very small minority of situations you may not be able to get the right people together, either physically or virtually, to define the initial vision – this should be seen as a significant project risk.
2. Simple designs are best BUT the architecture should be thought out early in the lifecycle. Too many developers interpret the advice to focus on simple designs to mean that they should build everything from scratch. Yet more often than not the simplest design is to take advantage of what is already there, and the best way to do that is to work closely with people who understand your existing technical infrastructure. Investing in a little bit of architectural envisioning early in the lifecycle enables your team to identify existing enterprise assets that you can leverage, to identify your architectural options, and to select what appears to be the best option available to you. The details will still emerge over time, and some decisions will be deferred until a later date when it’s more appropriate to make them, but the bottom line is that disciplined agilists think before they act.
3. Teams should be self organizing BUT they are still constrained (and enhanced) by your organizational ecosystem. Intellectual workers, including IT professionals, are most effective when they have a say in what work they do and how they do it. IT professionals can improve their productivity by following common conventions, leveraging and building out a common “dev-ops” infrastructure, building towards a common vision, and by working to common business and technical visions.  In short, disciplined agile professionals are "enterprise aware".
4. Delivery teams don’t need prescriptive process definitions BUT they do need some high-level guidance to help organize their work. Individual IT professionals are typically highly-skilled and highly-educated people often with years of experience, and teams of such people clearly have a wide range of knowledge. As a result of this knowledge it is incredibly rare for such people to read detailed procedures for how to do their work. However, they often still require some high-level advice to help them to organize their work effectively. Teams can often benefit from techniques and patterns used by other teams and this knowledge sharing should be encouraged.
5. IT professionals know what to do BUT they’re still not process experts. A decade ago the strategy was to provide detailed process advice to teams, but recently the pendulum has swung the other way to provide little or no defined process at all. Over the last few years there’s been a trend within the agile community to advise teams to define their own process so that it’s tailored to their own unique situation. While this clearly strokes people’s egos, it’s relatively poor advice for several reasons. First, although every team is in a unique situation there is significant commonality so having at least a high-level process framework from which to start makes sense. Second, although these teams have a wide range of knowledge it might not be complete, nor consistent, nor is it clear what the trade-offs are of combining all the really good techniques that people know about. There is significant benefit in having a flexible process framework such as DAD which shows how everything fits together.
6. IT professionals should validate their own work to the best of their ability BUT they likely aren’t testing experts so therefore need help picking up the appropriate skills. The mantra in the agile community is to test often and test early, and better yet to test first. As a result agile teams have adopted a “whole team” approach where the development team does its own testing. This works when there are people on the team with sufficient testing skills and more importantly can transfer those skills to others. Minimally you will need to embed testers into your delivery teams, but you should also consider explicit training and mentoring of everyone on the team in testing and quality skills.  You may find my agile testing and quality strategies article to be an interesting read.
7. Disciplined agile teams work in an iterative manner BUT still follow a lifecycle which is serial over time. On any given day people on a DAD project team may be performing analysis, testing, design, programming, deployment, or a myriad of other activities and iterating back and forth between them. But, the DAD lifecycle includes three distinct phases which are performed in order. So, DAD is both iterative in the small but serial in the large.

This blog posting has been replaced by the more detailed article: Full Agile Delivery Lifecycles.  

Thank you for your patience.

 

 

One of the scaling factors called out in the Software Development Context Framework is “geographic distribution".   As with the other scaling factors the level of geographic distribution is a range, with co-located teams at one extreme and far-located at the other.  When your team is co-located the developers and the primary stakeholders are all situated in the same work room.  If you have some team members in cubicles or in separate offices then you're slightly distributed, if you're working on different floors in the same building you're a bit more distributed, if you're working in different buildings within the same geographic area (perhaps your team is spread across different office buildings in the same city or some people work from home some days) then your team is more distributed, if people are working in different cities in the same country you're more distributed, and finally if people are working in different cities around the globe you're even more distributed (I call this far located).

As your team becomes more distributed your project risk increases for several reasons:

1. Communication challenges.  The most effective means of communication between two people is face-to-face around a shared sketching space such as a whiteboard, and that requires you to be in the same room together.  As you become more distributed you begin to rely on less effective communication strategies.
2. Temporal challenges.  When people are in different time zones it becomes harder to find common working times, increasing the communication challenges.  One potential benefit, however, is the opportunity to do "follow-the-sun" development where a team does some work during their workday, hands off the work to another team in a significantly different time zone, who picks up the work and continues with it.  This strategy of course requires a high degree of sophistication and discipline on the part of everyone involved, but offers the potential to reduce overall calendar time.
3. Cultural challenges.  As the team becomes more distributed the cultural challenges between sites typically increases.  Different cultures have different work ethics, treat intellectual property differently, have different ideas about commitment, have different holidays, different approaches to things, and so on.

As you would imagine, because the project risk increases the more distributed your team is, the lower the average success rates of agile projects decrease as they become more distributed.  The 2008 IT Project Success Survey found that co-located agile teams has an average success rate of 79%, that near located teams (members were in same geographic area) had a success rate of 73%, and that far-located agile teams had a success rate of 55%.  The success rate decreases similarly for project teams following other paradigms.

The practices that you adopt, and the way that you tailor the agile practices which you follow, will vary based on the level of geographic distribution of your team.  For example, a co-located team will likely do initial architecture envisioning on a whiteboard and keep it at a fairly high-level.  A far-located team will hopefully choose to fly in key team members at the beginning of the project, at least the architecture owners on the various sub-teams, to do the architecture envisioning together.  They will likely go into greater detail because they will want to identify, to the best of their ability, the interfaces of the various subsystems or components which they'll be building.  

Interestingly, the Agility at Scale 2009 survey found that it was quite common for agile teams to be geographically distributed in some manner:

• 45% of respondents indicated that some of their agile teams were co-located
• 60% of respondents indicated that some of their agile teams had team members spread out through the same building
• 30% of respondents indicated that some of their agile teams were working from home
• 21% of respondents indicated that some of their agile teams had people working in different offices in the same city
• 47% of respondents indicated that some of their agile teams had team members that were far located

The bottom line is that some organizations, including IBM, have been very successful applying agile techniques on geographically distributed teams. In fact, agile GDD is far more common than mainstream agile discussion seem to let on. 

Recommended Resources:

• A Practical Guide to Distributed Scrum
• Software Development Context Framework
• Geographically Distributed Agile Teams

Recently I spent some time in the UK with Julian Holmes of Unified Process Mentors. In one of our conversations we deplored what we were seeing in the agile community around certification, in particular what the Scrum community was doing, and he coined the term “integrity debt” to describe the impact it was having on us as IT professionals. Integrity debt is similar to technical debt which refers to the concept that poor quality (either in your code, your user interface, or your data) is a debt that must eventually be paid off through rework. Integrity debt refers to the concept that questionable or unprofessional behavior builds up a debt which must eventually be paid off through the rebuilding of trust with the people that we interact with.
The agile community has been actively increasing their integrity debt through the continuing popularity of Scrum Certification, in particular the program around becoming a Certified Scrum Master (CSM). To become a CSM you currently need to attend, and hopefully pay attention during, a two-day Scrum Master Certification workshop taught by a Certified Scrum Trainer (CST). That’s it. Granted, some CSTs will hold one or more quizzes which you need to pass, an optional practice which isn’t done consistently, to ensure that you pay attention in the workshop. 
Scrum Masters, as you know, take the leadership position on a Scrum team. The idea that someone can master team leadership skills after two entire days of training is absurd. Don’t get me wrong, I’m a firm supporter of people increasing their skillset and have no doubt that many of the CSTs deliver really valuable training. However, there is no possible way that you can master a topic, unless it is truly trivial, in only two days of training. From what I can tell the only thing that is being certified here is that your check didn’t bounce.
The CSM scheme increases the integrity debt of the IT industry by undermining the value of certification. When someone claims that they’re certified there’s an assumption that they had to do something meaningful to earn that certification. Attending a two-day course, and perhaps taking a few quizzes where you parrot back what you’ve heard, clearly isn’t very meaningful. The problem with the term Certified Scrum Master is two-fold: not only does the term Certified imply that the holder of the certification did something to earn it, the term Master implies that they have significant knowledge and expertise gained over years of work. It is very clear that people are falling for the Scrum certification scheme.
A quick search of the web will find job ads requiring that candidates be CSMs, undoubtedly because they don’t realize that there’s no substance behind the certification. Whenever I run into an organization that requires people to be CSMs I walk them through the onerous process of earning the designation and suggest that they investigate the situation themselves. Invariably, once they recognize the level of deception, the customer drops the requirement that people be CSMs.
Another quick search of the web will find people bragging about being a CSM, presumably being motivated by the employment opportunities within the organizations gullible enough to accept Scrum certification at face value. My experience is that the people claiming to be CSMs are for the most part decent, intelligent people who 99.99% of the time have far more impressive credentials to brag about than taking a two-day course. Yet, for some reason they choose to park their integrity at the door when it comes to Scrum certification. I suspect that this happens in part because they see so many other people doing it, in part because they’re a bit desperate to obtain or retain employment in these tough economic times, and in part because the IT industry doesn’t have a widely accepted code of ethical conduct. These people not only embarrass themselves when they indicate on their business cards or in their email signatures that they’re Certified Scrum Masters they also increase the integrity debt of the agile community as a whole.
Yet another search of the web will find people bragging about being Certified Scrum Trainers (CSTs), the people whom have been blessed by the Scrum Alliance to deliver Scrum master certification courses. Once again, my experience is that these are intelligent, skilled people, albeit ones who have also parked their integrity at the door in the pursuit of a quick buck. Surely these people could make a decent living via more ethical means? I know that many of them have done so in the past, so I would presume that they could do so in the future. The actions of the CSTs increase our integrity debt even further.
The group of people who have most embarrassed themselves, in my opinion, are those whom we consider thought leaders within the agile community. Leaving aside the handful who are directly involved with the Scrum certification industry, the real problem lies with those who have turned a blind eye to all of this. The Scrum certification scheme was allowed to fester within our community because few of our thought leaders had the courage to stand up and publicly state what they were talking about in private. This of course is all the more galling when you consider how much rhetoric there is around the importance of courage on software development projects. As Edmund Burke once observed, all that is necessary for evil to triumph is for good men to do nothing.

There are several things that we can do today to start paying off some of our integrity debt:

1. Be discerning, not deceptive. If you’re going to list credentials on your email signature or business card then only choose to list the ones that actually mean something.
2. Educate human resources people. Make them aware of what “Certified Scrum Master” really means and let them think for themselves. I highly suspect that if HR people realized what was going on the demand for CSMs would plummet, and in turn people wouldn’t be tempted by Scrum certification.
3. Act professional, don’t just claim to be certified. Instead of signing up for every easy certification that comes your way why not simply do a good job and let the people you work with be your claim to fame? The good news is that for the past few years the agile community has tried to pay down some of the IT industry’s integrity debt that we have with our stakeholders by providing better return on investment (ROI), delivering systems which are more effective at addressing the needs of your stakeholders, by working in a more timely manner, and by producing greater quality work. All of these claims are borne out by the 2008 Software Development Project Success Rate Survey by the way.
4. Recognize that adding a test doesn’t address the underlying problems. For the past year there’s been a move afoot to have people pass a test as part of earning their CSM (apparently it’s been a challenge to create a non-trivial test to validate your understanding of a topic that you can master by taking a two-day training course). This is something that should have been done from the very beginning, along with some sort of peer review, not years later when the damage has been done. Adding a test at this late date isn’t going to remove the stink that’s built up over the years, but sadly it will fool a few people into believing that they’ve covered it up.
5. Recognize that there is a demand for certification. The agile community needs to put together a decent certification program, something that the Scrum Alliance has clearly failed at doing. My article Coming Soon: Agile Certification provides some thoughts as to what we need to do. The good news is that people such as Ron Jeffries and Chet Hendrickson, and others, are putting together a developer certification program. The really good news is that these are the right people to do this. The really bad news is that they’re doing it under the aegis of the Scrum Alliance, so whatever they accomplish will unfortunately be tainted by the fallout of the CSM debacle.

If we're going to scale agile software development strategies to meet the range of challenges faced by modern organizations, we need to be trustworthy.  Is claiming to be a certified master after taking a two-day course an act which engenders trust?  I don't think so.  As individuals we can choose to do better.  As a community we need to.

Suggested Reading

1. Agile Certification -- A humorous look at certification.
2. IT Surveys -- A great resource for statistics about what IT people are actually doing in practice.

I recently ran into an interesting issue at a customer organization.  This customer is in the process of transitioning to Disciplined Agile Delivery (DAD) and part of that effort is to train, mentor, and coach their people in these new ideas and techniques.  The challenge is that some of "their people" are full time employees (FTEs) and some are contractors/consultants.   When we were planning an upcoming DAD workshop with them, part of the planning effort was to identify who should get that training, which we're delivering in a just-in-time (JIT) basis on a team-by-team basis.  The only people invited to take the training were FTEs because the customer has a policy of not training contractors.   I pushed back a bit on this, but they were adamant about not training contractors because their view was that contractors should either have the skills required to do their jobs or be willing to get those skills on their own time.  Fair enough, but from an agile team building point of view this isn't ideal. 

This situation got me thinking a bit.  One issue is that not all contractors are the same.  Some are short term contractors that are brought in for a specific purpose, they're paid well, and then they move on.  Other contractors stay much longer, sometimes months or even years, and as a result gain deeper knowledge and understanding of your business.  For these longer term contractors it seems to me that there is little difference between them and FTEs, perhaps only in the way that they're remunerated.  Some countries such as the United States now have laws in place limiting how long someone is allowed to remain a contractor because these similarities lead to interesting legal questions around extending benefits to them.

Another issue is that if you intend to build teams from both FTEs and contractors, it behooves you to ensure that these people get similar training, coaching and mentoring to streamline the transition effort. 

Here's the logic I would suggest to address the issue of whether or not to train a contractor:

1. Is the contractor going to be assigned to a key project/product for the organization?  If not, don't train them.
2. Are they someone you want to keep long term?  If not, don't train them and consider not putting them on the new agile team at all.
3. Does the contractor work for a large service provider?  If yes, ask the service provider to cover the costs of training.
4. Is the contractor an independent or working for a smaller service provider?  If yes, include the person in the training if there's room but don't pay their wage during the training period (so you effectively share the investment/cost of training).

As always, let the context of the situation drive your strategy.