I was recently in Bangalore speaking at the Rational Software Conference, which was really well done this year, and visiting customers. In addition to discussing how to scale agile software development approaches, particularly when the team is distributed geographically and organizationally, I was also asked about what I thought about a software factory approach to development. My instinctual reaction was negative, software factories can result in lower overall productivity as the result of over specialization of staff (I prefer generalizing specialists
), too many hand-offs between these specialists (I find close collaboration to be far more effective), and too much bureaucratic overhead to coordinate these activities. I initially chalked it up to these people still believing that software development was mostly a science, or perhaps an engineering domain, whereas my experiences had made me come to believe that software development is really more art than it is a science. Yet, the consistent belief in this strategy by very smart and experienced people started me thinking about my position.
Just let me begin by saying that this blog posting isn't meant to be yet another round in the age old, and relatively inane, "art vs. science" debate within the software development community. That debate is a symptom of versusitis
, a dread disease which particularly plagues the IT industry and which can any of us at any time. There is no known cure, although the combination of experience, open-mindedness, and critical thought are the best inoculation against versusitis that we have so far. In that vein, let me explore the issues as I see them and I will let you think for yourself.
On the one hand software development has aspects of being an art for several reasons. First, the problem definition is never precise, nor accurate, and even when we have detailed specifications the requirements invariably evolve
anyway. The lack of defined, firm requirements requires us to be flexible and to adjust to the situation that we find ourselves in. Second, teams typically find themselves in unique situations, necessitating a unique process and tool environment to reflect this (assuming that you want to be effective, otherwise there's nothing stopping you from having a "repeatable process" and consistent tool environment). Third, software is built by people for people, requiring that the development team have the ability to build a system with a user interface which meets the unique needs of their end users. One has only to look at the myriad UI designs out there to see that surely there is a bit of art going on. Fourth, if software development wasn't at least partially art then why hasn't anyone succeeded at building tools which take requirements as inputs and produce a viable solution that we can easily deploy? It's been over four decades now, so there's been sufficient time and resources available to build such tooling. Fifth, regardless of how much of a scientific/business facade we put over it, our success rate at producing up front detailed cost estimates and schedules speak for itself (see Funding Agile Projects
for links to articles).
On the other hand software development has aspects of being a science for several reasons. First, some aspects of software development have in fact been automated to a significant extent. Second, there is some mathematical basis to certain aspects of software development (although in the case of data-oriented activities the importance of relational theory
often gets blown way out of proportion and I have yet to see a situation where formal methods proved to be of practical value).
What does this have to do with Agility@Scale. As you know, one of the agile scaling factors
is Organizational Complexity, and cultural issues are the hardest to overcome. Whether your organization believes that software development is mostly an art or mostly a science is a cultural issue which will be a major driver in you choice of methods and practices. Organizations which believe that software development is more of a science will prefer strategies such as software factories, model-driven architecture (MDA),
and master data management (MDM)
. And there is ample evidence to support the claims that some organizations are succeeding at these strategies. Although you may not agree with these strategies, you need to respect the fact that many organizations are making them work in their environments. Similarly, organizations which believe that software development is more of an art will find that agile and lean strategies are a better fit, and once again there is ample evidence that organizations are succeeding with these approaches (there's also evidence that agile projects are more successful
than traditional projects, on average). Once again, you may not agree with these strategies but you need to respect the fact that other people are making them work in practice.
Trying to apply agile approaches within an organization that believes software development is mostly a science will find it difficult at best, and will likely need to embark on a multi-year program to shift their culture (likely an expensive endeavor which won't be worth the investment). Similarly, trying to apply a software factory strategy in an organization that believes that software development is mostly an art will also run aground. The bottom line is that one size does not fit all, that one strategy is
not right for all situations and that you need to understand the trade-offs of various strategies, methodologies, techniques, and practices and apply them appropriately given the situation that you face. In other words, it depends! If you are embarking on a software process initiative, and you don't have the broad experience required to effective choose between strategies (very few organizations do, although many believe otherwise), then you should consider Measured Capability Improvement Framework (MCIF)
to help increase your chance of success.
Modified by ScottAmbler
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:
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.
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).
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.
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.
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.
I'm happy to announce that I've accepted the role of Managing Director of the Scrum Alliance
(SA), a part-time position in addition to my duties here at IBM. On the surface this must appear to be a radical and unpredictable departure for me, considering my history of being critical when it comes to some of the past activities of the Scrum Alliance. To be fair, I've actually been critical of the Certified Scrum Master (CSM) scheme
, and rightfully so. But I have also actively embraced the good ideas contained in Scrum and have incorporated them, with attribution, in my writings about Disciplined Agile Delivery (DAD)
and other agile topics. I believe that I've made this very apparent in this blog and in other sources such as the Agile Modeling
site. So, it really isn't such a radical departure for me afterall, although still arguably one that was difficult to predict. In fact, one of the reasons why the Scrum Alliance approached me to be Managing Director is the fact that I have been critical of many of the Scrum community's behaviors.
So, over the next few months you're going to see what I believe to be some welcome changes at the Scrum Alliance. Our first step at serving you better will be to apply agile strategies and principles in the way that we work. Importantly, we'll be taking a three pronged strategy based on respect, clarity, and integrity. We have dubbed this strategy "Scrum Alliance 2.0".
To be more respectful of existing and potential SA members, we will begin executing the following activities:
- Adopt respectful language on the site. We've begun a review of the SA web site to identify potentially disrespectful language. For example, on the About page we indicate that Scrum trainers pay for your first two years of SA membership fees. Who do we think we're kidding? Those fees are clearly coming out of the money that you paid to take the training and we shouldn't hide this fact. I believe that our improved clarity strategy, see below, will go a long way to increasing our respectfulness towards others.
- Tone down the rhetoric. There's been a lot of rhetoric espoused over the years regarding Scrum, which is true of many other issues within the IT industry and not just Scrum. From now on any rhetoric that we do promote we're going to actually live by. For example, not only are we going to claim that Scrum increases visibility (which it can in fact do) we're going to be an examplar of that by being open ourselves. More on this below.
- Deprecate the chicken and pig analogy. Calling people chickens and pigs may be fun at first, and to be fair the analogy helps to cut through some of the politics surrounding many project teams, but the terminology is in fact disrespectful. We can and should do better.
Clarity through openness and honesty
We are also starting to execute on four activities for improving the clarity of how we operate:
- 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.
- 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.
- 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.
- 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.
Integrity through actions, not words
Finally, we're taking three actions to increase the overall integrity of the Scrum community:
- 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.
- 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.
- 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.
As I hope you have guessed by now this blog is an April Fool's joke
. I have no intention of becoming the Managing Director of the Scrum Alliance and my condolences go out to anyone who would take on this position. This blog posting does however reflect what I would do to bring greater clarity, integrity, and respect to the Scrum community. The Scrum Alliance can and should choose to do a lot better. I hope it has been food for thought.
Modified by ScottAmbler
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.
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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Disciplined. Agile software development requires greater discipline on the part of practitioners that what is typically required by traditional approaches.
- Self organizing. This means that the people who do the work also plan and estimate the work.
- 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.
- 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.
- 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.
- 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.
- 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.
Modified by ScottAmbler
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:
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.
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.
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).
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.
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.
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.
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).
I have a young daughter and she's at the age where she wants to dress herself. The problem is that if we pick a single outfit and try to get her to wear it she refuses (I've lost count of the times I've heard "I don't want that"). At the other extreme if we let her pick her own outfit from the closet she'll be there for hours trying everything on. As experienced parents advise what we need to do is present her with two or three choices and ask her to pick what she wants.
So how does this relate to software development? Once again, let's look at extremes. First, consider Scrum's approach of prescribing a single way of doing things. For example, Scrum prescribes that you hold a daily meeting, called a Scrum, where everyone stands up and answers the same 3 questions. Scrum also prescribes a single change management strategy where you have a stack of requirements prioritized by business value. Scrum prescribes three roles - ScrumMaster, Product Owner, and Team Member - as well as other things. Don't get me wrong, these strategies are all great in certain circumstances but not for all. Prescribing one way of doing things is an extreme, so perhaps we shouldn't be surprised when people refuse to do it that way or struggle to make it work given the situation that they face.
At the other extreme consider RUP's approach where it presents repository of techniques from which to select the ones appropriate for you. The problem is that now we have an overwhelming way of doing things from which to choose, all of them good options in certain situations. So why are we surprised when teams struggle to identify a coherent tailoring of RUP?
Now let's consider the middle ground. The Disciplined Agile Delivery (DAD) process decision framework takes a goals-driven approach. So, instead of saying "hold a daily stand up meeting and answer these three questions" it says to regularly coordinate within the team and there are several ways of doing so (hold a Scrum meeting, hold a Kanban-style meeting, and so on). Yes, DAD does provide a large number of techniques to choose from (as does the agile community in general) but it also provides a straightforward way to choose between them. DAD does this by describing the advantages and disadvantages of each technique and suggests when, and when not, to use each approach. When people are presented with viable options, and the trade-offs associated with each, it's much more likely that they'll choose an approach that is better suited for their situation.
Scrum's single prescribed strategy works well only when that strategy is appropriate for the situation at hand. Similarly, telling my daughter exactly what to wear works well only when she's in the mood to wear that outfit. RUP's cafeteria approach to software process works well when you have the expertise, and time, to choose what's best for you. Similarly, asking my daughter to pick out her outfit from all the choices in her closet only works well when I've got a lot of time to wait for her. In both situations a better strategy is to present options, describe the trade offs, and then let people pick what's right for them given the context of the situation that they face. This is exactly what the DAD framework promotes.
I believe the goals-based approach of Disciplined Agile Delivery (DAD) represents an important step forward in the software process realm. It's time to recognize the extremes for what they are and move to a more viable middle ground.
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:
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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).
- 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.
- Production release planning. This is the subset of your release planning efforts which focuses on the activities required to deploy into production.
- 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.
- 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.
There’s more to it though than simply adopting some good practices. Your process must also embrace several supporting philosophies. The Disciplined Agile Delivery (DAD)
process framework not only adopts the practices listed above, and more, but it also promotes several philosophies which enable DevOps:
- Delivery teams should be enterprise aware, that they should work with people such as operations staff and enterprise architects to understand and work towards a common operational infrastructure for your organization.
- Operations and support people should be recognized as key stakeholders of the solution being worked on.
- The delivery team should focus on solutions over software. Software is clearly important, but we will often provide new or upgraded hardware, supporting documentation (including operations and support procedures), change the business/operational processes that stakeholders follow, and even help change the organizational structure in which our stakeholders work.
- Your process should include an explicit governance strategy. Effective governance strategies motivate and enable development teams to leverage and enhance the existing infrastructure, follow existing organizational conventions, and work closely with enterprise teams – all of which help to streamline operations and support of the delivered solutions.
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.
In November 2011 Paul Gorans, the Accelerated Solution Delivery (ASD) practice lead in IBM GBS, and I ran an agile adoption survey
. The survey explored a range of issue, including the factors that appear to be associated with the success and failure of agile project teams. Paul wrote up his thoughts in his Agile State of the Art Survey
article on ibm.com and I did the same for Dr Dobb's Journal in Agile Success Factors
. This blog posting summarizes the results of the survey.
Factors which appear to accelerate agile adoption include:
- 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
Factors which appear to decelerate agile adoption include:
- Agile teams are measured using traditional metrics
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:
- 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.
- 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.
- 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".
- 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.
- 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.
- 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.
- 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.
Modified by ScottAmbler
This blog posting has been replaced by the more detailed article: Full Agile Delivery Lifecycles.
Thank you for your patience.
Modified by ScottAmbler
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:
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.
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.
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.
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:
- 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.
- 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.
- 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.
- 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.
- 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
- Agile Certification -- A humorous look at certification.
- IT Surveys -- A great resource for statistics about what IT people are actually doing in practice.
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:
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.
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.
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.
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.
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.
Modified by ScottAmbler
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:
Is the contractor going to be assigned to a key project/product for the organization? If not, don't train them.
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.
Does the contractor work for a large service provider? If yes, ask the service provider to cover the costs of training.
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.