The following diagram summarizes a safe and proven strategy for scaling agile delivery strategies at the team level.  There are three features of this strategy:

1. Basic agile and lean methods.   At the base are methods such as Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Agile Data, and many others.  These methods are the source of practices, principles, and strategies that are the bricks from which a team will build its process. 
2. Disciplined Agile Delivery (DAD).  Building on mainstream methods is the DAD process decision framework, providing an end-to-end approach for agile software delivery.  DAD provides the process mortar required to combine the process bricks, effectively doing the “heavy lifting” to describe how all of these great agile strategies fit together.
3. Agility at scale.  Teams operating at scale apply DAD in a context driven manner to address the scaling factors that they face.  These teams may be large, they may be geographically distributed in some way, they may face compliance constraints, they may be addressing a complex domain or technical environment, or they may be organizationally distributed in some manner.  And usually combinations thereof.  Without the solid foundation provided by DAD, agility at scale is incredibly difficult to achieve.

To scale agile successfully you must be able to tailor your approach to reflect the context that you face.  To do this you must understand what your process and organizational structure options are and what tradeoffs each of those options has.  Unless you’re a process expert, this can be challenging.  This is where DAD’s process goal strategy comes in.  Instead of prescribing a single way to do things, as we see in methods such as Scrum and SAFe, DAD instead captures your options in terms of process goals and guides you through making the decisions that best address the situation that you find yourself in.  An example of a process goal diagram, in this case for the Inception phase goal Explore Initial Scope, is shown below. 

The critical thing is that with a goal-driven approach it becomes much easier to understand how to scale agile.  Depending on the context of the situation that a team finds itself in you will address each goal differently.  The strategy for a small, co-located team facing a fairly straightforward situation in a non-regulatory environment works well for that team, the same strategy prescribed to a team in a different situation would put that team at risk of failure.  Instead of prescribing a single way of working that is optimized for a specific situation we need to instead allow, and better yet enable, teams to adopt strategies that reflect the context of the situation that they face.  

We’ve found that four of the twenty-two process goals seem to take about 80% of the tailoring impact.  These goals are:

1. Explore Initial Scope. This is sometimes referred to as initially populating the backlog in the Scrum community, but there is far more to it than just doing that.  This is an important goal for several reasons.  First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding.  Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of the scope of your effort is important input into answering those sorts of questions.
2. Identify Initial Technical Strategy. This is sometimes referred to as initial architecture envisioning or simply initial architecture modeling. You want to address this process goal for several reasons . First, the team should think through, at least at a high level, their architecture so as to identify a viable strategy for moving forward into Construction.  A little bit of up-front thinking can increase your effectiveness as a team by getting you going in a good direction early in the lifecycle.  It can also help to avoid injection of unnecessary technical debt as a result.  Second, the team should strive to identify the existing organizational assets, such as web services, frameworks, or legacy data sources that they can potentially leverage while producing the new solution desired by their stakeholders.  By doing this you increase the chance of reuse, thereby avoiding adding technical debt into your organizational ecosystem, and more importantly you reduce the time and cost of delivering a new solution as the result of reuse.  You will do this by working with your organization’s enterprise architects, if you have any.  This is an aspect of DAD’s philosophy of working in an enterprise aware manner.
3. Move Closer to a Deployable Release.  This Construction phase process goal is important for three reasons. First, it encompasses the packaging aspects of solution development (other important development aspects are addressed by its sister goal Produce a Potentially Consumable Solution).  This includes artifact/asset management options such as version control and configuration management as well as your team’s deployment strategy.  Second, it provides deployment planning options, from not planning at all (yikes!) to planning late in the lifecycle to the more DevOps-friendly strategies of continuous planning and active stakeholder participation. Third, this goal covers critical validation and verification (V&V) strategies, many of which push testing and quality assurance “left in the lifecycle” so that they’re performed earlier and thereby reducing the average cost of fixing any defects.
4. Coordinate Activities. Although it is nice to believe that all of the coordination required by an agile team can be handled with a 15 minute stand up meeting every day the truth is far from that.  This process goal addresses strategies for coordinating the work within a team, coordinating with other development teams (if needed), coordinating with IT groups such as your Enterprise Architects or data management group, and coordinating between subteams a programme or portfolio.

For a more detailed discussion of how these four process goals are the key to scaling your agile software delivery process, please refer to the whitepaper Scaling Agile Software Development: Disciplined Agile Delivery at Scale.   

 

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.

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.

Over the past few months I've had several people ask me whether it makes sense to offshore agile testing, and more importantly when it makes sense to do so.  So I thought I would share my thoughts on the subject:

1. Focus on whole team testing.  The basic strategy is that agile teams should strive to do as much, if not all, of the testing themselves.  We call this whole team testing.  For organizations new to agile this can be daunting because they may be organized in such a way that programmers write code and then hand it over to testers for validation and verification.  The implication is that organizations will need to invest in their staff so that the programmers become more well rounded and pick up testing skills (we refer this as moving from being a specialist to a generalizing specialist).   
2. Offshore entire development teams.  A common strategy for organizing geographically distributed agile teams is to have whole teams at each location.  For example, if your larger team is spread across three locations - Toronto, London, and Bangalore - then each team is responsible for implementing end to end functionality.  With a component-based approach the Toronto team should be fully responsible for one or more subsystems, the London team responsible for one or more subsystems, and the Bangalore team responsible for one or more subsystems.  With a feature-team approach the Toronto team would implement all of the functionality, end-to-end, for a feature regardless of which subsystems that functionality affects.  Agile teams typically aren't organized by job function (e.g. analysis is done in London, design and coding in Toronto, testing in Bangalore) due to the overhead of handoffs between sites, the increased risk of miscommunication due to less effective ways of communicating information, and the increased complexity of managing the work.
3. Adopt independent testing at scale.  You may choose, or be forced to have, an independent test team that focuses on some of the more complex forms of testing.  The general idea is that this team works in parallel to other subteams and tests their working builds on a regular basis.  Having said that, the vast majority of the testing effort should still be done in a whole team fashion. If your team is experiencing agile scaling factors such as domain complexity or technical complexity then you may find that it makes economic sense to have an independent test team focus on forms of testing that are difficult for the subteams to address, in particular pre-production system integration testing.  If your team is in a regulatory domain where independent testing is required, then you're better off to "shift left" this effort with an independent test team to reduce both cost and risk.
4. Offshore independent testing carefully.  I would offshore independent testing only to organizations that I have a very good, long-term relationship with that have proven that they can work in a disciplined agile manner.  I would also want to ensure that they have actual experience with agile independent testing AND are staffing the team with people that have that experience.  A clear sign that they don't understand what is required is if the independent testing team is asking for a detailed requirements specification, an indication that they're planning on doing confirmatory testing which is better suited for whole team testing.  Furthermore, I would only do this if I don't have adequate staff to do so myself AND do not have time to build up my own independent test team.

 

I suspect that you're going to find yourself in serious trouble if:

• You do not have successful experiences with agile delivery in simpler (e.g. non-offshoring) situations first.  Walk before you try to run.
• You think you can save money by having agile programming done in one location and agile testing in another (the coordination costs are going to be much larger than you think)
• You're offshoring testing because you're new to agile (in this situation you don't have the experience to organize let alone govern the offshored activities)   
• You work with a service provider where you don't have a proven track record with them when it comes to agile development (a proven track record with traditional approaches is a good start but still very risky)

In short, it can make sense to offshore agile testing in a very narrow range of situations.  Be very careful.

On Twitter one of the people that I follow recently tweeted in jest "I am waste".  He had been tweeting about the problem that people will often pay consultants for their advice yet will not follow that advice once it's been provided (yet will often still keep paying for more advice).  Perhaps in this situation his efforts were a waste, or perhaps the real issue was that the customer had a long learning process and hadn't yet come to the point where they were willing to act on the advice, we may never know.  But I have to think that there are other situations where this person isn't a waste, regardless of his claims.

This got me thinking that something is a waste in one context yet in another context may be quite valuable.  Or, as the old saying goes, one man's trash is another man's treasure.

For example, consider the following simple value stream: 

[Activity A: 10 min] [Wait time: 20 min] [Activity B: 10 min]

Without considering the context, the wait time of 20 min represents 50% waste in the overall process that we should try to eliminate.

What if that wait time provides people with a much needed rest?  With time to contemplate?  With time to destress?  Eliminating that wait time, or even reducing it, could result a degradation of performance.  In this case, one person's waste (the wait time) is another person's treasure (rest time).  The implication is that we need to work closely with the people intimately involved in a process if we're to help them to improve it.

Context counts.

A fair question to ask is why should your organization consider adopting the Disciplined Agile Delivery (DAD) process framework.  I believe that there are several clear benefits to doing so:

1. DAD shows how agile techniques fit together.  DAD is a hybrid that adopts strategies from a variety of sources, including Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Outside In Development (OID) and many more.  More importantly DAD's process-goal driven approach shows how this all fits together, providing advice for when (and when not) to use each technique and the advantages and disadvantages of doing so.  In doing so DAD enables you to streamline your efforts to tailor agile to reflect the context of the situation you find yourself in.  Furthermore, it provides this advice in the context of a full agile delivery lifecycle, explicitly showing how to initiate a project, construct a solution, and then deploy into production.  Instead of starting with a small agile method such as Scrum and doing all the work to figure out how to tailor ideas from other methods to actually make it work, why not start with a framework that's already done all that work for you?
2. DAD isn't prescriptive.  DAD is far less prescriptive than other agile methods.  For example, where Scrum prescribes a single strategy for managing changing requirements, a strategy called a Product Backlog, DAD suggests several strategies and provides advice for choosing the right one.  Where other agile methods define a single lifecycle, DAD instead describes several lifecycles (an agile Scrum-based one, a lean lifecycle, and a continuous delivery lifecycle to name just three) and once again describes how to choose the right one for your situation.  Your agile team is in a unique situation, and as a result needs a flexible process framework that provides coherent, easy-to-follow tailoring advice.   Isn't it better to adopt strategies that reflect the context that you actually face?
3. DAD explicitly addresses architecture.  Even after a decade of agile software development it still seems that the topic of how agile teams address architecture is a mystery for many people.  As a result DAD builds agile architecture strategies right in, starting with initial architecture envisioning, to proving the architecture with working code, to evolutionary design strategies during construction. 
4. DAD explicitly addresses DevOps.  DevOps is the art of combining development and operations approaches in such a way as to streamline your overall efforts.  DAD "bakes in" DevOps through explicit support for common DevOps practices as well as its robust stakeholder definition which explicitly includes operations and support people.
5. DAD explicitly addresses governance.  Although governance is often considered a dirty word within some agile circles, the reality is that software development teams can and should be governed.  Sadly, many agile teams have traditional governance strategies inflicted upon them, strategies which invariably increase schedule, cost and risk on the project.  But is doesn't have to be this way.  It is possible, and very desirable to adopt agile goverance strategies, strategies which are built right into the DAD framework.
6. DAD explicitly addresses many other important development activities.  Architecture, DevOps, and governance are just the tip of the iceberg.  DAD also shows how critical activities such as analysis, design, testing, quality, technical writing, and many more are addressed in an agile and streamlined manner throughout the delivery lifecycle.  As described earlier, this is done in a non-prescriptive and tailorable manner, thereby removing a lot of the mystery regarding how this agile stuff all fits together into a coherent whole.
7. DAD is solution focused, not software focused.  Although the rhetoric around "potentially shippable software" resonates well with developers it observably and empirically misses the mark.  DAD promotes the more robust idea of "potentially consumable solutions".  Yes, shipping is nice but shipping something that people actually want to use/buy, something that is consumable, is much nicer.  Yes, software is part of the equation but that software runs on hardware, we often also need to develop supporting documentation, we often evolve the business process, and even evolve the organization structure around the usage of the system.  In other words, we're really producing solutions, not just software.  Isn't it better to adopt rhetoric that actually reflects what we're doing in practice?
8. DAD promotes enterprise awareness over team awareness.  One of the great benefits of an agile approach to software development is its focus on the team.  This can also be a bit of a problem, because a team-focused strategy can result in suboptimal decisions for your overall organization.  DAD promotes the idea that disciplined agilists should be enterprise aware, working towards common business and technical goals while leveraging and enhancing the existing infrastructure whenever possible.
9. DAD provides a foundation from which to scale.  The starting point for scaling agile is to understand how agile strategies fit together from project initiation to delivery into production.  If you don't know how to succeed with agile in a straightforward situation then it will prove very difficult to do so in an agility @ scale situation.  DAD not only provides this tailorable foundation from which to scale agile it also takes a robust view of what it means to scale agile (hint: large or distributed teams are only a start).
10. DAD provides a basis for enterprise agile.  As organizations move towards a true "enterprise agile" approach they often find that they need to adopt either DAD as a foundation or invest a fair bit of effort inventing something similar.  They are also starting to adopt strategies from the SAFe framework, or reinventing such, as well as ideas from sources such as Enterprise Unified Process (EUP) (sadly, poorly named in hindsight), ITIL, and even CoBIT.  More on this in a future blog posting.

In short, DAD provides a lot of proven advice culled from years of experience applying agile software techniques in enterprise-class environments.  Instead of figuring all of this stuff out on your own, why not jump ahead and leverage the hard-won lessons learned from other organizations that have already dealt with the challenges that you're struggling with today?

The primary shortcoming of the DAD framework is it makes it very clear that software development, oops I mean solution delivery, is quite complex in practice.  As IT practitioners we inherently know this, but it seems that we need to be reminded of this fact every so often.  DAD doesn't provide a simplistic, feel-good strategy that you can learn in a few hours of training.  Instead it defines a coherent, tailorable strategy that reflects the realities of enterprise IT. 

There is a wealth of information at DAD posted at the  Disciplined Agile Delivery (DAD) web site and great discussions occuring on the DAD LinkedIn discussion forum.  For those of you interested in agile certification, the Disciplined Agile Consortium site will prove valuable too, in particular the list of upcoming DAD workshops provided by several IBM partners.  And of course the book Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise (IBM Press, 2012) written by Mark Lines and myself is a very good read.

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

 

 

On April 25, 2013 I gave a webcast for the Global Rational User Community entitled Disciplined Agile Delivery: Going beyond Scrum .  During the webcast a large number of questions were asked but unfortunately I couldn’t get to all of them.  So I’ve taken the opportunity to write up the answers in this blog posting.

1. Fequently asked questions. Many of the questions are addressed in the DAD FAQ.
2. DAD elevator pitch - I will be starting work in a couple of weeks for a company that has just started its Agile journey this year by implementing Scrum. What would Scott put in an elevator chat as to why they should be moving towards DAD.  The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.  There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.  The article Introduction to Disciplined Agile Delivery provides a more detailed description.
3. The book: Could you please repeat the name of the book that Scott is talking about?  The book is Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise published by IBM Press, June 2012.  The Disciplined Agile Delivery (DAD) website  and the Disciplined Agile Consortium website are also good DAD resources.
4. The Surveys: Where is the data published about geographic distribution and effectiveness?  All of my survey data, the original questions as asked, and my analysis can be downloaded free of charge from my IT Surveys page.  If you ever see a request from me to fill out a survey, please take a few minutes and do so.  I think you'll agree that my surveys page is in fact a very useful resource, so please contribute when you can.
5. Project success criteria: Where would a goal of defining success criteria fall?  In the DAD book we describe how the success criteria for the project should be initially identified during Inception. Success criteria, like other things, could evolve throughout the project.  You might find the IT Process Success Surveys to be of interest as several of them explored what success criteria projects actually have.  Interestingly, its rarely “on time, on budget, to specification”.
6. Transitioning to DAD: How would you typically phase a DAD implementation, let's say in a project pilot where they haven't been exposed yet to Agile?  Same question, any variance if the development team has already started Scrum?  This is a fairly complex question to answer.  The short story is that you need to invest some time to understand what your strengths and weaknesses are so that you can identify what you need to focus on.  You will then likely need to pilot strategies/techniques which are new to your organization before rolling them out widely.  You may also need to invest in training and coaching/mentoring depending on your needs.  My company, Scott Ambler + Associates, offers these sorts of services and more for organizations interesting in adopting disciplined agile strategies. 
7. Skills: I am aware that ideally developer should also be able to test but in reality theses are usually separate roles. Is it in line with your beliefs\suggestions?  Many organizations that are new to agile still have roles that reflect their existing strategy.  Non-agile approaches often have people in specific roles such as programmer, tester, designer, and so on. In DAD we promote a different set of agile roles that reflect agile thinking.  The implication is that you’re going to have to help individuals transition over to the new way of thinking, something we cover in Chapter 4 of the DAD book.  You might also find Mark Lines' blog, No role in DAD for an Analyst?  to provide some insights into issues surrounding the transition from traditional to agile roles.
8. Teaming: What happens with the Product Owner and the Architecture Owner don’t Agree?  See my blog What Happens When People Don’t Agree 
9. Skillsets: Different people of the team have different skills, experience, and time horizons.  We can't all be generalists, can we?  There are several agile roles in DAD, each of which have different rights, responsibilities, and skillsets.  So we’re not promoting the idea that everyone have the same skillset.  However, we do promote the philosophy that people should strive to be T-skilled generalizing specialists so as to improve their productivity.
10. Teaming: What are your thoughts on team cohesion?  Teams will gel over time.  Being co-located helps.  Having people who are dedicated 100% to the team helps.  Building a team of people who want to be there helps.  Self organization helps. 
11. Tool support: Is there an RMC plug-in for DAD + Is there any software behind DAD... or some software that supports it... such as Jazz (RTC) for Agile/Scrum?  Yes, IBM Rational does in fact have an RMC plug in for DAD.  There is also a template for Microsoft TFS from RDA Corp, Software Development Expert’s Practices Advisor supports DAD comprehensively, and I’m currently working with MethodPark to do so too.    Stay tuned to the Disciplined Agile Delivery website for information about tool support.
12. Governance: Regarding enterprise governance and enterprise IT, how do you start taking a culture that imposes common-process, common-tools, central (often outsourced) IT services, and heavyweight stage/gate across all organizations, and get that evolving toward a (still enterprise aware) lean/agile approach?  This is a hard one.  I’m often called into organizations to help with this very issue.  The challenge is that you need to have a deep understanding of IT governance techniques as well as how to govern agile teams.  Governance is something we discussed in detail in the DAD book as well as on the DAD site, see Adopting Agile Governance Requires Discipline. 
13. Executable specifications: TDD was mentioned, can you comment on Behavior Driven Development (BDD) and any impact on this lifecycle?  BDD is a slight nuance to acceptance test-driven development (ATDD).  BDD/ATDD and TDD are both potential practices that you might choose to follow on a DAD team.  I’ve written a fair bit about agile testing and quality strategies and about TDD in detail.
14. Architecture: When does the first version of architecture gets established and what would require to establish it? You typically start thinking about architecture early in a DAD project during Inception following a practice called architecture envisioning.  I’ve also written a fair bit about agile architecture techniques and the potential misconceptions about agile architecture that you may find interesting.
15. Travel plans: Will you be coming to South Africa at some point?  The good news is that Mark Lines, my co-author, will be in South Africa the week of May 20 in Joburg and the following week in Capetown.  Contact us for details.  I hope to be visiting SA later this year but exact dates haven’t been set yet.  So, please stay tuned on Twitter at @scottwambler for further announcements. 
16. Other travel plans: If you'd like me to speak at a local event, including corporate conferences or training events, please contact me. 

 

 

 

 

The Disciplined Agile Consortium recently launched a certification programme for practitioners of Disciplined Agile Delivery (DAD).   There are three practitioner certifications:

1. Disciplined Agile Yellow Belt. This beginner certification indicates to colleagues and employers that you are eager to learn Disciplined Agile Delivery (DAD) strategies that enable you to increase your skills and abilities as a software professional.
2. Disciplined Agile Green Belt. This intermediate certification indicates that you are experienced at DAD and are on your way to becoming a generalizing specialist. You have the potential to be a “junior coach” under the guidance of a senior coach (someone who is likely a Disciplined Agile Black Belt).
3. Disciplined Agile Black Belt. This expert certification indicates that you are a trusted expert with significant proficiency at DAD. You can coach other people in disciplined agile strategies and advise organizations in the adoption and tailoring of the DAD framework.

Differentiate yourself in the marketplace. Certification in Disciplined Agile Delivery (DAD) means something to clients and employers because it needs to be earned. Certification in DAD tells the marketplace you understand how to deliver an agile solution from end-to-end with experience in enterprise-class development.

1. You adopt "standard" agile discipline.   Aspects of agile which require discipline include adopting practices such as test-driven development (TDD), active stakeholder participation, working collaboratively, shortening the feedback cycle, and many more.  These strategies are a great start to becoming disciplined IT professionals. 
2. You take a goal-driven approach.  When we first started working on the DAD framework I didn't want to create yet another prescriptive framework, particularly given Rational's track record with the Rational Unified Process (RUP) framework.  Rational has been pilloried for years for the prescriptive nature of RUP, which is unfortunate because there are a lot of great ideas in RUP that agile teams can benefit from, some of which we adopted in DAD and many of which are being actively reinvented with the agile community even as you read this. Furthermore, there are many prescriptive elements of the Scrum method that can get teams in trouble.  For example, Scrum prescribes that you hold a daily stand up meeting, often called a Scrum meeting, where everyone should answer three questions.  That's a great approach for teams new to agile, but it proves problematic in many situations due to it's prescriptive nature. Do you really need to do this once a day?  I've been on teams where we held coordination meetings twice a day and others only once a week.  Do you really need to stand up?  I've been on geographically distrubited agile teams where many of us were sitting down during coordination calls.  Do you really need to answer three questions, two of which are clearly focused on status regardless of claims otherwise?  I've been on lean teams where we met around our Kanban board and focused on potential blockers.  The answers to these questions depends on the context of the situation you find yourself in.  The challenge, at least from the point of view of a process framework, is how do you avoid falling into the trap of being overly prescriptive.  The strategy we adopted in DAD is to take a goal-driven approach.  The observation is that regardless of the situation you find yourself in there are common goals your team will need to fulfill.  For example, at the beginning of a project common goals include developing an initial plan, initially exploring the scope, initially identifying a technical strategy, and securing initial funding (amongst others).  Throughout construction you should coordinate your activities, improve the quality of your ecosystem, and produce a potentially consumable solution on a regular basis (more on this below).  So, instead of prescribing a daily stand up meeting the DAD framework instead indicates you should coordinate your activities, and gives several options for doing so (one of which is a Scrum meeting).  More importantly DAD describes the advantages and disadvantages of your options so that you can make the choice that's best suited for the situation your team finds itself in (see this blog posting for a detailed example of the types of tables included in the DAD book to help you through such process tailoring decisions).  In short, our experience is that it requires discipline to take a goal driven approach to agile delivery over the prescriptive strategies in other agile processes. 
3. You take a context-driven approach.  There are many tailoring factors, which I describe in the Software Development Context Framework (SDCF), which you need to consider when making process, tooling, and team structure decisions.  For example, a large team will adopt a different collection of practices and tools than a small team.  A geographically distributed team will adopt a different strategy than a team that is co-located.  You get the idea.  Other tailoring factors include compliance, team culture, organization culture, technical complexity, domain complexity, and project type.  It requires discipline to recognize the context of the situation you find yourself in and then act accordingly.
4. You deliver potentially consumable solutions.  One of the observations that we made early in the development of the DAD framework was that disciplined agile teams produce potentially consumable solutions, not just potentially shippable software.  Although delivery of high-quality, working software is important it is even more important that we deliver high-quality working solutions to our stakeholders. For example, not only are we writing software but we may also be updating the hardware on which it runs, writing supporting documentation, evolving the business processes around the usage of the system, and even evolving the organizational structure of the people working with the system.  In other words, disciplined agilists focus on solutions over software.  Furthermore, "potentially shippable" isn't sufficient: not only should it be shippable but it should also be usable and should be something people want to use.  In other words it should be consumable (a concept DAD adopted from IBM's Outside In Development).  Minimally IT professionals should have the skills and desire to produce good software, but what they really need are the skills and desire to provide good solutions. We need strong technical skills, but we also need strong "soft skills" such as user interface design and process design to name just two. The incremental delivery of potentially consumable solutions on an incremental basis requires discipline to do successfully.  DAD teams focus on repeatable results not repeatable processes.
5. You are enterprise aware.   Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you will need to act accordingly. It takes discipline to work with enterprise professionals such as enterprise architects, data admistrators, portfolio managers, or IT governance people who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a DevOps manner throughout the lifecycle, particularly when they may not be motivated to do so.  It requires discipline to accept and potentially enhance existing corporate development conventions (programming guidelines, data guidelines, UI guidelines, ...).  It requires discipline to accept that your organization has an existing technology roadmap that you should be leveraging, building out, and in some cases improving as you go.  In short, enterprise awareness requires a level of discipline not typically seen on many agile teams.
6. You adopt a full delivery lifecycle.  Empirically it is very easy to observe that at the beginning of an agile project there are some activities that you need to perform to initiate the project.  Similarly at the end of the project there are activities that you need to perform to release the solution into production or the marketplace.  The DAD process framework addresses the effort required for the full delivery effort, including project initiation, construction, and deployment.  Our experience is that it requires discipline on the part of IT professionals to include explicit phases for Inception/Initation, Construction, and Transition/Deployment and more importantly to focus the appropriate amount of effort on each.  One danger of explicit phases is that you run the risk of taking what's known as a Water-Scrum-Fall approach, a term coined by Dave West the person who wrote the forward for the DAD book, where you take an overly heavy/traditional approach to inception and transition in combination with a lighter agile approach to construction.  Water-Scrum-Fall occurs because many organizations haven't made a full transition to agile, often because they think it's only applicable to construction.  Our experience is that you can be very agile in your approach to inception and transition, experience we've built into the DAD framework.  Having said that it clearly requires discipline to keep inception activities short and similarly it requires discipline to reduce the "transition phase" to an activity. 
7. You adopt a wider range of roles.  An interesting side effect of adopting a full delivery lifecycle is that you also need to adopt a more robust set of roles.  For example, the Scrum method suggests three roles - Scrum Master, Product Owner, and Team Member - a reflection of the Scrum lifecycle's construction focus.  DAD suggests three primary roles - Team Lead, Product Owner, Team Member, Architecture Owner, and Stakeholder - as well as five secondary roles which may appear at scale.   
8. You embrace agile governance.  Governance establishes chains of responsibil­ity, authority and communication in support of the overall enterprise’s goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles that people play with and within the department.  It requires discipline to adopt an agile approach to governance, and that's something built right into the DAD framework.

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
  

On Nov 16 2011,  Kim Werner, Agile Coach from ATSC and Liz Parnell, Solution Design Manager from Blue Cross Blue Shield of North Carolina (BCBSNC), gave a webcast sharing their experiences regarding how BCBSNC adopted a few Agile techniques, with the help of some good coaching, and adopted some IBM Rational Jazz tools (Rational Team Concert and Rational Requirements Composer) to reduce time to market and lower development costs. BCBCNC works in the highly-regulated healthcare industry, so faced a few interesting constraints when adopting agile.

I recently recorded an audio podcast about Collaborative Development and Operations (DevOps) and how it relates to Disciplined Agile Delivery (DAD).  The podcast is 17 minutes long and covers a range of topics including:

• What are the challenges typically faced by Disciplined Agile Development teams as they begin to transition their working solutions into production?
• How best could this gap between Development and Operations be closed so that they worked collaboratively rather than in silos?
  
• If this DevOps gap was decreased or even closed, what would the measurable value be to Agile projects and their business stakeholders?

On a related note, IBM's Collaborative Development and Operations landing page has some great resources if you're interested in how to implement.

My new white paper, Disciplined Agile Delivery: An Introduction, is now available free of charge from IBM.com. The paper overviews the Disciplined Agile Delivery (DAD) process framework, a hybrid comprised of strategies from Scrum, XP, Agile Modeling, and other agile methods which is people first, learning oriented, and enterprise aware. DAD is the basis from which you can scale agile.

Topics covered:

• Context counts - The Agile Scaling Model
• People first - People, and the way they interact with each other, are the primary determinant of success for a solution delivery project.
• Learning-oriented - The DAD process framework promotes the ideas that team members should collaborate closely and learn from each other, that the team should invest effort to learn from their experiences and evolve their approach, and that individuals should do so as well.
• Hybrid - DAD adopts and tailors strategies from Scrum, XP, Agile Modeling, UP, Kanban, and many others. It addresses many of the issues Mark Kennaley discusses in SDLC 3.0.
  
• IT solution focused - DAD teams produce potentially consumable solutions every construction iteration.  This extends Scrum's "potentially shippable" strategy to explicitly address usability/consumability plus the fact that we're really delivering full solutions not just software.
• Goal-driven delivery life cycle - The DAD lifecycle is focused on delivery, not just construction.  Furthermore it is goals-driven, the DAD process framework suggests various strategies to fulfill those goals but does not prescribe specific practices.
  
• Risk and value driven - The DAD lifecycle is risk and value driven.  It extends Scrum's value-driven lifecycle which produces potentially shippable software each sprint/iteration so that it explicitly includes light-weight milesstones such as ensuring stakeholder consensus as to the scope of the project early in the lifecycle, proving the architecture with working code early in the lifecycle, ensuring sufficient functionality exists before transition, and ensuring production readiness before actual release of the solution.
  
• Enterprise aware - The DAD process framework promotes the ideas that DAD teams should work closely with their enterprise architecture groups to ensure they leverage and evolve the existing infrastructure, adopt and follow corporate guidelines, and work to the overall organizational vision.  DAD teams are self organizing with appropriate governance.

I recently did the voice over for our Rational.Everyware Agility@Scale whiteboard video, which is a bit less than 4 minutes in length.  As I narrate a whiteboard sketch evolves, sometimes using sticky-notes and index cards, to help explain what I'm talking about. 

In the video, I describe:

• The history of agile
• Some of the challenges surrounding traditional development
• Some of the basics of agile, such as increased collaboration with stakeholders and on delivery of consumable solutions
• The benefits of agile, including increased quality, time to value, stakeholder satisfaction, and ROI
• Domains where agile is being applied successfully
• What IBM agility@scale is all about
• How some of the scaling factors change the way that you'll work and approach tooling
  
• Rational Team Concert (RTC), what it is and why you'd be interested in it
• Benefits that customers are seeing with RTC
• How you can download a fully-functional version of RTC for a team of up to 10, with no time limit, free of charge

So, it's basically a cool marketing video for a bunch of free stuff.

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.

For some reason, it seems as if everyone's grandfather at one point in time recommended to use the right tools for the job.  That's practical wisdom from my point of view, one that is certainly an issue for agile development. 


One of the primary messages, I hope, of the Agile Scaling Model (ASM) is that context counts.  Although the focus of the ASM is on describing a contextual framework for tailoring your process to meet the needs of the situation that you find yourself in, it's also applicable to your tooling selection.  For example, the tool choices of a co-located team will be much different than that of a geographically distributed team.  A co-located team will likely use a whiteboard or paper for their agile modeling efforts, whereas distributed team members may need to capture their diagrams using a more sophisticated tool such as Rational Requirements Composer (RRC) so that their work can be shared electronically.  Having said that, RRC would be overkill for a co-located team (unless they had regulatory compliance issues).  Different teams, different situations, therefore different tooling choices.


One of the concerns that I run into from customers is that some of our legacy products don't support agile very well.  Once again, it's a matter of context because many of our legacy products reflect the realities faced by more traditional teams.  The challenge occurs when you try to take a legacy product which is well suited for traditional development, such as Rational ClearCase, and try to apply it on agile projects.  Although ClearCase makes sense in certain scaling situations, particularly very large teams that are geographically distributed, you'd be better advised to use something like Rational Team Concert (RTC) for configuration management on most agile teams (note that RTC does far more than just SCM).


So, if you're taking an agile approach you should consider Rational tools such as RTC, RRC, Rational BuildForge, Rational AppScan, and others which support agile development.  Granted, some you would only use at scale -- for example Buildforge is a good option in really complex environments, but if you don't face that complexity then you'll likely find that RTC's build engine is sufficient.  Similarly, if you're taking a traditional approach to development then you'll likely consider products such as ClearCase, Appscan, RTC, and Rational Software Architect (RSA) instead.  Different situations, different tooling choices. 


What's even more confusing is that some products support a range of process paradigms.  For example, RTC supports agile, lean, iterative, and traditional approaches to development.  The same can be said of Appscan and several other products.  Notice how I listed RTC and Appscan for both agile and traditional development above. 


So, if anyone tells you that Rational tools don't support agile development don't believe them.  Ask them which tools that they're talking about, and ask them if they're aware of the Rational products that do support agile development.  Context counts.

I'm happy to announce that IBM Rational's RP252 Advanced Disciplined Agile Delivery (DAD) workshop is now available.  This is a 3-day, hands-on workshop which teaches students the fundamentals of Disciplined Agile Delivery (DAD).  This workshop is offered both publicly and privately.

I'm happy to announce that a revised version of the Lean Development Governance white paper which I co-wrote with Per Kroll is now available.  This version of the paper reflects our learnings over the past few years helping organizations to improve their governance strategies.

There's a more detailed description of the paper here.

There is a distinct rhythm, or cadence, at different levels of the agile process. We call this the agile 3C rhythm, for coordinate, collaborate, and conclude (which is sometimes called stabilize). The agile 3C rhythm occurs at three levels in Disciplined Agile Delivery (DAD):

1. Day. A typical day begins with a short coordination meeting, called a Scrum meeting in the Scrum method. After the daily coordination meeting the team collaborates throughout most of the day to perform their work. The day concludes with a working build, hopefully you had several working builds throughout the day, which depending on your situation may require a bit of stabilization work to achieve.
2. Iteration. DAD construction iterations begin with an iteration planning session (coordinate) where the team identifies a detailed task list of what needs to be done that iteration. Note that iteration modeling is often part of this effort. Throughout the iteration they collaborate to perform the implementation work. They conclude the iteration by producing a potentially consumable solution, a demo of that solution to key stakeholders, and a retrospective to identify potential improvements in the way that they work.
3. Release. The DAD lifecycle calls out three explicit phases - Inception, Construction, and Transition – which map directly to coordinate, collaborate, and conclude respectfully.

The agile 3C rhythm is similar conceptually to Deming’s Plan, Do, Check, Act (PDCA) cycle:

• Coordinate maps to plan
• Collaborate maps to do
• Conclude maps to check and act

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.

IBM Rational recently published an update to my Agility@Scale e-book, which can be downloaded free of charge.  The e-book is a 21 page, 2.3 meg PDF (sorry about the size, guess the graphics did it) .   It overviews the Agile Scaling Model (ASM) (which has since been replaced by the Software Development Context Framework (SDCF) ), Disciplined Agile Delivery (DAD), the scaling factors of agility at scale, and ends with some advice for becoming as agile as you can be.  In short it's a light-weight coverage of some of the things I've been writing about in this blog the past couple of years.  Could be a good thing to share with the decision makers in your organization if they're considering adoption agile strategies.

• Pre-production system integration testing.  Does the solution work within your overall organizational ecosystem?  Importantly, if this is one of several teams currently developing new solutions, does this team's solution work with what will be in production (including the work in progress of other teams) when they go to release?  In mid-to-large organizations the only economical way to do this sort of testing is via an independent, centralized team.
• Usability testing.  Although it's possible to do usability testing on the development team, the reality is that usability testing is a specialized skill that few people have (although could pick up via non-solo development).  Furthermore, particularly for solutions with many potential users, you may want to invest in a usability testing lab.  This is a centralized resource, or an outsourced resource these days, which is shared across many teams.
• Security testing.  Security testing is also a specialized skill, albeit one well supported with sophisticated security testing tools such as the Rational Appscan suite which can be included in your continuous integration (CI) strategy.  Many organizations will centralize their security testing efforts.
• Exploratory testing.  The fundamental goal of exploratory testing is to discover where the solution breaks, as opposed to confirmatory testing which focuses on showing that the solution conforms to the requirements (this is the type of testing the development team typically focuses on).  Exploratory testing is also a skill, a good one which everyone should strive to pick up, but exploratory testers are often few in number in many organizations.  So, to leverage their skills effectively you may want to have some of them on the independent test team while they mentor others while doing so.
• Non-functional testing. Non-functional requirements have a tendency to fall through the cracks on some development teams.  Knowing this the independent test team will often "test to the risk" and focus on non-functional issues.
• And much more.  The above points are just exemplars, not an exact list.  Please follow some of the links above for greater detail.

1. The developers still do the majority of the testing.  Just because there's an independent test team it doesn't imply that they are the ones doing all the testing.  In fact, nothing could be further from the truth.  They should be doing the minority of the testing effort, albeit the more difficult forms of it.
2. An independent test team will support multiple dev teams.  For example, a test team of 5-6 people could support several development teams totalling 70 to 80 people.  I typically look for a 15:1 or 20:1 ratio of developers to independent testers, hopefully even higher than that.
3. You need to consider better tooling.  Although the development team will still be using common agile testing tools such as the xUnit and FIT frameworks the independent test team (ITT) will need more sophisticated tooling.  First, the ITT will need to be able to report defects back to the team easily.  When the development team is using a Jazz-based tool such as Rational Team Concert (RTC) then this can easily be done using either RTC (the web interface may be sufficient) or another Jazz-enabled product such as Rational Quality Manager (RQM).  Second, the ITT will likely need more sophisticated testing tools, such as Rational Appscan for static and dynamic security testing and Rational Performance Tester (RPT) for performance testing (just two of several software quality management tools you should consider).
4. Independent testing is economical. Although I listed several tools in my previous point (hey, I do work for a vendor after all) an "unfortunate" implication of my advice (unfortunate for IBM at least) is that you can reduce the number of licenses that you require and still get this critical testing done by centralizing their use.
5. It may be a bit more complicated in regulatory environments.  In a strict regulatory environment the independent test team may need to repeat, or at least validate, the testing efforts of the development team.  In regulatory environments my fundamental advice is always this -- Have practical people, including yourself, read and interpret the regulations.  If you leave it to the bureaucrats you'll get a bureaucratic solution.
6. This is an important scaling technique.  Parallel independent testing, when done in an agile manner, is an important technique which you should consider when scaling agile strategies to meet the uniques needs of the situation that you find yourself in. 

This article has been replaced by an official "Disciplined Agile Manifesto".

 

The text of the original article remains below.

---------------------------------------------------------------------------------------

I've recently been working with Mark Lines of UPMentors and we've had some interesting discussions around evolving the Agile Manifesto which I thought I would share here to obtain feedback.  Note that this is not any sort of official position of IBM, nothing in my blog is by the way (unless explicitly stated so), nor is it some sort of devious plot to take over the agile world (although if we did have some sort of devious plot, we'd make the exact same claim).  What we hope to accomplish is to put some ideas out there in the hopes of getting an interesting conversation going.

Over the past decade we’ve applied the ideas captured in the Agile Manifesto and have learned from our experiences doing so.  What we’ve learned has motivated us to suggest changes to the manifesto to reflect the enterprise situations which we have applied agile and lean strategies in.  We believe that the changes we’re suggesting are straightforward:

1. Where the original manifesto focused on software development, a term which too many people have understood to mean only software development, we suggest that it should focus on solution delivery.
2. Where the original focused on customers, a word that for too many people appears to imply only the end users, we suggest that it focus on the full range of stakeholders instead.
3. Where the original manifesto focused on development teams, we suggest that the overall IT ecosystem and its improvement be taken into consideration.
4. Where the original manifesto focused on the understanding of, and observations about, software development at the time there has been some very interesting work done within the lean community since then (and to be fair there was very interesting work done within that community long before the Agile Manifesto was written).  We believe that the Agile Manifesto can benefit from lean principles.

Our suggested rewording of the Agile Manifesto follows, with our suggested changes in italics.

Updating the Values of the Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working solutions over comprehensive documentation
3. Stakeholder collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Updating the Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.
2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the stakeholder’s competitive advantage.
3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Stakeholders and developers must work together daily throughout the project.
5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
7. Quantified business value is the primary measure of progress.
8. Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.
15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams. 

We’re agile – things evolve, including manifestos.  Looking forward to your feedback (add a comment).

 

Updates Since this Was First Published:

• February 2011: At the 10th Anniversary of the Agile Manifesto get together several people, including myself, brought up the idea of updating the Agile Manifesto.  Unfortunately the decision by the original writers of the manifesto was to adopt a very strict, non-agile change management approach where any changes to the manifesto would need the approval of all 17 of them.  So, pretty much zero chance of there ever being any changes (hence the lack of changes so far). 
• June 2012: This extension to the manifesto was retitled "A Disciplined Agile Manifesto" and published as in the book Disciplined Agile Delivery written by myself and Mark Lines.
• November 2012: Mark and I formed Scott Ambler+Associates.
• February 2013: The Disciplined Agile Consortium (DAC) is formed.  The mission of DAC is to evolve and support the Disciplined Agile Delivery (DAD) framework.
• April 2014: Official Disciplined Agile Manifesto posted on the Disciplined Agile Delivery (DAD) site.

Further reading:

• The Declaration of Interdependence (some other thoughts about, arguably, evolving the manifesto)
• Examining the Agile Manifesto
• Disciplined Agile Delivery website

 

 

 

One of the scaling factors called out in the Software Development Context Framework (SDCF) is domain complexity.  The general idea is that agile teams will find themselves in different situations where some teams are developing fairly straightforward solutions, such as an informational website, whereas others are addressing very complex domains, such as building an air-traffic control system (ATCS).  Clearly the team building an ATCS will work in a more sophisticated manner than the one building an informational website.  I don't know whether agile techniques have been applied in the development of an ATCS, although I have to think that agile's greater focus on quality and working collaboratively with stakeholders would be very attractive to ATCS delivery teams, I do know that agile is being applied in other complex environments: The 2009 Agility at Scale Survey found that 18% of respondents indicated that their organizations had success at what they perceived to be very complex problem domains,.

Increased domain complexity may affect your strategy in the following ways:

1. Reaching initial stakeholder consensus becomes difficult.  One of the risk reduction techniques called out in Disciplined Agile Delivery (DAD) is to come to (sufficient) stakeholder consensus at the beginning of the project during the Inception phase (called Sprint 0 in Scrum or Iteration 0 in other agile methods).  Stakeholder consensus, or perhaps "near concensus" or "reasonable agreement" are better terms, can be difficult to come to the more complex the problem domain is because the stakeholders may not fully understand the implications of what they're making decisions about and because there is likely a greater range of stakeholders with differing goals and opinions.  The implication is that your project initiation efforts may stretch out, increasing the chance that you'll fall back on the old habits of big requirements up front (BRUF) and incur the costs and risks associated with doing so. 
2. Increased prototyping during inception.   It is very common for disciplined agile teams to do some light-weight requirements envisioning during inception to identify the scope of what they're doing and to help come to stakeholder consensus.  The greater the complexity of the domain, and particularly the less your team understands about the domain, the more likely it is that you'll benefit from doing some user interface (UI) prototyping to explore the requirements.  UI prototyping is an important requirements exploration technique regardless of paradigm, and it is something that you should consider doing during both initial requirements envisioning as well as throughout the lifecycle to explore detailed issues on a just in time (JIT) manner.
3. Holding "all-hands reviews".    One strategy for getting feedback from a wide range of people is to hold an "all hands review" where you invite a large group of people who aren't working on a regular basis with your team to review your work to date.  This should be done occasionally throughout the project to validate that the input that you're getting from your stakeholder represenatives/product owners truly reflects the needs of the stakeholders which they represent.  The 2010 How Agile Are You? Survey found that 42% of "agile teams" reported running such reviews.
4. Increased requirements exploration.  Simple modeling techniques work for simple domains.  Complex domains call for more complex strategies for exploring requirements.  The implication is that you may want to move to usage scenarios or use cases from the simpler format of user stories to capture critical nuances more effectively.  A common misunderstanding about agile is that you have to take a "user story driven approach" to development.  This is an effective strategy in many situations, but it isn't a requirement for being agile.
5. The use of simulation.  You may want to take your prototyping efforts one step further and simulate the solution.  This can be done via concrete, functional prototypes, via simulation software, via play acting, or other strategies.
6. Addition of agile business analysts to the team.  Analysis is so important to agile teams we do it every day.  In situations where the domain is complex, or at least portions of the domain is complex, it can make sense to have someone who specializes in exploring the domain so as to increase the chance that your team gets it right.  This is what an agile business analyst can do.  There are a few caveats.  First, even though the domain is complex you should still keep your agile analysis efforts as light, collaborative, and evolutionary as possible.  Second, this isn't a reason to organize your team as a collection of specialists and thereby increase overall risk to your project.  The agile analyst may be brought on because their specialized skills are required, but the majority of the people on the team should still strive to be generalizing specialists.  This is also true of the agile analyst because their may not be eight hours a day of valuable business analysis work on the team, and you don't want the BA filling in their time with needless busy work.

The important thing is to recognize that the strategies which work well when you're dealing with a simple domain will not work well for a complex domain.  Conversely, techniques oriented towards exploring complex domains will often be overkill for simple domains.  Process and tooling flexiblity is key to your success.

1. Does the team regularly produce value for their stakeholders?
2. Does the team validate its own work to the best of its ability?
3. Are stakeholders actively involved?
4. Is the team self organizing?
5. Does the team strive to improve their process?

Some interesting results include:

• 94% of teams which are claiming to be agile are providing value to stakeholders on a regular basis.  
• 87% of teams which are claiming to be agile are validating their own work.  
• 95% of teams which are claiming to be agile are working closely with stakeholders.  
• 56% of teams which are claiming to be agile are self organizing. 
• 88% of teams which are claiming to be agile are improving the process that they follow throughout the lifecycle.  
• Teams which are claiming to be agile often aren't.  53% of "agile teams" meet the five criteria, although 72% meet all but the self-organization criteria.
• Teams which are moving towards agile but aren't there yet are reasonably close.  39% of those teams meet all five criteria and 63% meet all but self-organization.

• Whenever someone claims to be on an agile team you may want to explore that claim a bit deeper.
• The low level of self organization may be an indicator of cultural challenges with organizations in that their project managers aren't giving up sufficient control.  The Agility at Scale survey in November 2009 found that 59% of respondents who indicated that their organization hadn't adopted agile techniques yet that a rigid culture was hampering their efforts.  The IT Governance and Project Management survey in July 2009 discovered that "questionable behaviors", many of which were ethically questionable (I'm being polite), were far too common within IT project management.
• Although "agile teams" may not be as agile as they claim, they're still doing better than traditional V-model teams, as revealed (again) by the 2010 IT Project Success survey.
• If there was some sort of consensus within the agile community as to the criteria for determining whether a team is agile, I highly suspect that the agileness ratings would increase over time.  What gets measured often improves.
• However, how agile you are isn't anywhere near as important as getting better at what you're doing.  So perhaps I'm barking up the wrong tree on this issue.  ;-) 

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 of the Agile Scaling Model (ASM) is technical complexity.  The fundamental observation is that the underlying technology of solutions varies and as a result your approach to developing a solution will also need to vary.  It’s fairly straightforward to achieve high-levels of quality if you’re building a new system from scratch on a known technology platform, but not so easy when there are several technologies, the technologies are not well known, or legacy assets are involved.  

There are several potential technical complexities which a Disciplined Agile Delivery (DAD) team may face:

1. New technology platforms.  Your team may choose to work with a technology platform which is either new to the team or sometimes even new to the industry.  In the past few years new technology platforms include the Android operating system, Apple’s iPad platform, and various cloud computing (http://www.ibm.com/ibm/cloud/) platforms.  Working with these platforms may require you to adopt new development tools and techniques, not to mention the need to train and mentor your staff in their usage.  Furthermore, your team may need to allocate time for architectural spikes to explore how to use the new technology and to prove the overall architecture with working code early in the project lifecycle (this is a DAD milestone).   
2. Multiple technology platforms.  IT solutions often run on multiple platforms.  For example, a system’s user interface (UI) could run in a browser, access business logic implemented using J2EE on Websphere which in turn invokes web services implemented in COBOL running on a Z-series mainframe, and stores data in an Oracle database, a DB2 database, and in several XML files.  Implementing new business functionality, or updating existing functionality, could require changes made on several of these platforms in parallel.  The implication is that you’ll need to adopt tools and strategies which enable your team to develop, test, and deploy functionality on all of these platforms.  Testing and debugging in particular will become more difficult as the number of technology platforms increases, potentially requiring you to adopt the practice of parallel independent testing.  The Agility at Scale survey found that 34% of respondents indicated that their agile teams were working with multiple technology platforms.
   
3. Legacy data.  IT solutions should leverage existing, legacy data wherever possible to reduce the number of data sources and thereby increase data quality within your organization.  Also, using existing data sources can potentially speed up development, assuming your team has a good relationship with the owners of the legacy data sources (sadly, this often isn’t the case as the Data Management Survey found).  Working with legacy data sources may require improved database regression testing, practices, database refactoring practices, and agile approaches to data administration. The Agility at Scale survey found that 42% of respondents indicated that their agile teams were working with legacy data sources (personally, I’m shocked that this figure is so low, and fear that many agile teams are contributing to data quality problems within their organization as a result).
   
4. Legacy systems.  There are several potential challenges with legacy systems.  First, the code quality may not be the best either because it was never really that good to begin with or because it’s degraded over the years as multiple people worked with it.  You know you’ve got a quality problem if you’re either afraid to update the code or if when you do so you have to spend a lot of time debugging and then fixing problems revealed when doing the update.  If the legacy system is a true asset for your organization you will want to pay off some of this technical debt by refactoring the code to make it of higher quality.  Second, you may not have a full regression test suite in place, making it difficult to find problems when you do update the code let alone when you refactor it.  Third, your development tools for your legacy code may be a bit behind the times.  For example, I often run across mainframe COBOL developers still working with basic code editors instead of modern IDEs such as Rational Developer for System Z.   Some of the strategies to deal effectively with legacy systems are to adopt a modern development toolset if you haven’t already done so (better yet, if possible adopt a common IDE across platforms and thereby reduce overall licensing and support costs) and to adopt agile practices such as static code analysis, dynamic software analysis, and continuous integration (CI).  The Agile Project Initiation Survey found that 57% of respondents were integrating their new code with legacy systems and 51% were evolving legacy systems.
5. Commercial off-the-shelf (COTS) solutions.  COTS solutions, also called package applications, can add in a few complexities for agile teams.  The packages rarely come with regression test suites, they often have rules about what you can modify and what you shouldn’t (rules that are ignored at your peril), and they’re often architected with the assumption that they’re the center of the architectural universe (which is a valid assumption if they’re the only major system within your organization).  As I describe in my article Agile Package Implementations it is possible to take an agile approach to COTS implementations, although it may require a significant paradigm shift for the people involved. The Agility at Scale survey found that 15% of respondents indicated that their agile teams were working with COTS solutions.  
6. System/embedded solutions.  For the sake of simplicity, if your team is developing a solution with both hardware and software aspects to it then you’re a systems project.  Embedded systems are a specialization where the system has a few dedicated functions often with real-time constraints.  Bottom line is that systems/embedded projects are typically more challenging than software-only projects – it gets really interesting when laws of physics starts to kick in, such as when you’re building satellites or space probes.  I highly suggest Bruce Douglass’s book Real-Time Agility if you are interested in taking an agile approach to systems/embedded solution delivery.
   

The technical complexity faced by a project team is contextual – Working with four technology platforms is straightforward for someone used to dealing with seven, but difficult for someone used to dealing with just one.

Recommended Reading:

• Agile Legacy System Analysis and Integration Modeling 
• Scaling Agile: An Executive Guide

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

 

In Implementing Lean Software Development, Mary and Tom Poppendieck show how the seven principles of lean manufacturing can be applied to optimize the whole IT value stream. These principles are:

1. Eliminate waste. Lean thinking advocates regard any activity that does not directly add value to the finished product as waste. The three biggest sources of waste in software development are the addition of unrequired features, project churn and crossing organizational boundaries (particularly between stakeholders and development teams). To reduce waste it is critical that development teams be allowed to self organize and operate in a manner that reflects the work they’re trying to accomplish. Walker Royce argues in “Improving Software Economics” that the primary benefit of modern iterative/agile techniques is the reduction of scrap and rework late in the lifecycle.
2. Build in quality.  Your process should not allow defects to occur in the first place, but when this isn’t possible you should work in such a way that you do a bit of work, validate it, fix any issues that you find, and then iterate.  Inspecting after the fact, and queuing up defects to be fixed at some time in the future, isn’t as effective.  Agile practices which build quality into your process include test driven development (TDD) and non-solo development practices such as pair programming and modeling with others.
3. Create knowledge.  Planning is useful, but learning is essential. You want to promote strategies, such as iterative development, that help teams discover what stakeholders really want and act on that knowledge. It’s also important for a team to regularly reflect on what they’re doing and then act to improve their approach.
4. Defer commitment.  It’s not necessary to start software development by defining a complete specification, and in fact that appears to be a questionable strategy at best. You can support the business effectively through flexible architectures that are change tolerant and by scheduling irreversible decisions to the last possible moment. Frequently, deferring commitment requires the ability to closely couple end-to-end business scenarios to capabilities developed in multiple applications by multiple projects.
5. Deliver quickly.  It is possible to deliver high-quality systems quickly. By limiting the work of a team to its capacity, which is reflected by the team’s velocity (this is the number of “points” of functionality which a team delivers each iteration), you can establish a reliable and repeatable flow of work. An effective organization doesn’t demand teams do more than they are capable of, but instead asks them to self-organize and determine what they can accomplish. Constraining these teams to delivering potentially shippable solutions on a regular basis motivates them to stay focused on continuously adding value.
6. Respect people. The Poppendiecks also observe that sustainable advantage is gained from engaged, thinking people. The implication is that you need a lean governance strategy that focuses on motivating and enabling IT teams—not on controlling them.
7. Optimize the whole.  If you want to be effective at a solution you must look at the bigger picture. You need to understand the high-level business processes that individual projects support—processes that often cross multiple systems. You need to manage programs of interrelated systems so you can deliver a complete product to your stakeholders. Measurements should address how well you’re delivering business value, because that is the sole reason for your IT department.

Lean thinking is important for scaling agile in several ways:

1. Lean provides an explanation for why many of the agile practices work.  For example, Agile Modeling’s practices of light weight, initial requirements envisioning followed by iteration modeling and just-in-time (JIT) model storming work because they reflect deferment of commitment regarding what needs to be built until it’s actually needed, and the practices help eliminate waste because you’re only modeling what needs to be built.
2. Lean offers insight into strategies for improving your software process.  For example, by understanding the source of waste in IT you can begin to identify it and then eliminate it. 
3. Lean principles provide a philosophical foundation for scaling agile approaches.   
4. It provides techniques for identifying waste.  Value stream mapping, a technique common within the lean community whereby you model a process and then identify how much time is spent on value-added work versus wait time, helps calculate overall time efficiency of what you’re doing.  Value stream maps are a straightforward way to illuminate your IT processes, providing insight into where significant problems exist.  I’ve created value stream maps with several customers around the world where we analyzed their existing processes which some of their more traditional staff believed worked well only to discover they had efficiency ratings of 20-30%.  You can’t fix problems which you are blind to.

 Timo Tenhunen has recently published his master's thesis, Challenges in Scaling Agile Software Development , and has been kind enough to make it available online.  I suspect you'll find it to be an interesting read.

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

One of the scaling factors called out in the Agile Scaling Model (ASM) is “regulatory compliance”.   This name is a bit of a misnomer because this scaling factor really addresses two issues: complying to regulations imposed upon you from external sources and choosing to adhere to internal regulations willingly adopted by your organization.   It is relatively common for agile teams to find themselves in such situations.  For example, in the 2009 Agile Practices Survey one third of respondents said that they were applying agile on projects where one or more industry regulations applied.

First let’s consider external regulatory compliance.  In these situations you may face the need to undergo an audit by an external regulatory body with consequences for non-compliance ranging from anywhere to a warning to a fine or even to legal action.  Sometimes even a warning may be a grave thing.  A few years ago I was working with a pharmaceutical company which had discovered that a warning from the FDA for non-compliance with their CFR 21 Part 11 regulation, when reported in major newspapers, resulted on average in a half-billion dollar loss to their market capitalization as the result of a dip in their stock price.   There are financial regulations such as Sarbanes-Oxley and Basel II, informational regulations such as HIPAA which focuses on health information  privacy, technical regulations such as ISO 27002 for security practices, and even life-critical regulations such as some of the FDA regulations.  

External regulations are typically managed by a government organization or industry watchdog will range in complexity and can have a myriad of effects on project teams.  For example, you may need to be able to prove that you had a documented process and that you followed it appropriately; you may need to produce extra artifacts, or more detailed artifacts, than you normally would; you may need to add extra features to your solution, such as tracking financial information, that you wouldn’t have normally implemented; you may need to produce specific reports to be submitted to the regulatory body; or you may even need to submit your team to audits, sometimes scheduled and sometimes not, to ensure regulatory compliance.  Interestingly, even though many of those requirements go against the agile grain, the 2009 Agility at Scale Survey found that organizations were successfully applying agile techniques while still conforming to external regulations.  So yes, it is possible to scale your agile strategy to address regulatory compliance.

Second, let’s consider compliance to internally adopted, or sometimes even developed, “regulations” which you will be potentially evaluated/appraised against.  Perfect examples of these are process improvement frameworks such as CMMI and ISO 900x.  Similar to external regulations, the 2009 Agility at Scale Survey found that some agile teams are succeeding in situations where they have chosen to adopt such frameworks.  It’s important to note that frameworks such as CMMI aren’t primarily about ensuring the compliance of development teams to a standard process, regardless of what CMMI detractors may claim, but instead about process improvement.  Process improvement at the IT department (or beyond) is an enterprise discipline issue from the point of view of ASM, implying that frameworks such as CMMI affect more than one scaling factor.  

When you find yourself in a regulatory situation, whether those regulations are imposed or willingly adopted, the best advice that I can give is to read the regulations and develop a strategy to conform to them in the most agile manner possible.  If you let bureaucrats interpret the regulations you’ll likely end up with a bureaucratic strategy, but if you instead choose to take a pragmatic approach you will very likely end up with a very practical strategy.  Part of that strategy is to treat the regulatory representative(s) within your organization as important stakeholders whom you interact with regularly throughout the project.

 You are invited to participate in my 2010 IT Project Success survey (http://www.surveymonkey.com/s/StateOfITUnion). The goal of this survey series is to find out how we define IT project success in practice and how successful our projects actually are. The survey should take you about 5 minutes to complete, and your privacy will be completely protected.

At the end of the survey you will be given the chance to be entered into a draw for one of 10 copies of Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself by Watts Humphrey and William R. Thomas published in April 2010 by Addison Wesley. I'm reading it right now and it's a really great book.

This is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at www.ambysoft.com/surveys/ so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.

Thank you very much for taking your valuable time to fill out this survey.

Rolf Nelson recently recorded a short (5 min) podcast about IBM Rational Team Concert (RTC).  RTC is a complete agile collaborative development environment providing agile planning, source code management, work item management, build management, and project health, along with integrated reporting and process support.  I've worked with RTC for a couple of years now and have been truly impressed with it.  What should be of interest to many people is the Express-C version which is a free, fully-featured, 10-license version of RTC which can be easily downloaded from www.jazz.net.  

People who are new to agile are often confused about how agile teams address architecture, but luckily we're seeing more discussion around agile architecture now in the community so this problem is slowly being addressed from what I can tell.  But, what I'm not seeing enough discussion about, at least not yet, is how is enterprise architecture addressed in the overall agile ecosystem.  So I thought I'd share some thoughts on the subject, based on both my experiences over the years (see the recommended resources at the bottom of this posting) as well as on an enterprise architecture survey which I ran in January/February 2010. 

My belief is that effective enterprise architecture, particularly in an agile environment, is:

1. Business driven.  Minimally your EA effort should be driven by your business, not by your IT department.  Better yet it should be business owned, although this can be a challenge in many organizations because business executives usually aren't well versed in EA and view it as an IT function.  Yes, IT is clearly an important part of EA but it's not the entirety of EA nor is it the most critical part.  In many organizations the IT department initiates EA programs, typically because the business doesn't know to do so, but they should quickly find a way to educate the business in the need to own your organization's EA efforts.
   
2. Evolutionary. Your enterprise architecture should evolve over time, being developed iteratively and introduced incrementally over time.  An evolutionary approach enables you act on the concrete feedback that you receive when you try to actually implement it, thereby enabling you to steer its development successfully.
   
3. Collaborative. The EA survey clearly pointed to "people issues" being critical determinants of success, and of failure, of EA programs.  My experience is that the best enterprise architects, just like the best application architects, work closely with the intended audience of their work, both on the business side of things as well as on the IT side.  They will "roll up their sleeves" and become active members of development teams, often in the role of Architecture Owner on agile teams or Architect on more traditional teams.  Their mission is to ensure that the development teams that they work with leverage the EA, to mentor developers in architecture skills, and to identify what works and what doesn't in practice so that they can evolve the EA accordingly.  Enterprise architects, architects in general, who don't participate actively on development teams (holding architecture reviews isn't active participation) run the risk of being thought of as "ivory tower" and thus easy to ignore.
   
4. Focused on producing valuable artifacts.  The most valuable artifacts are useful to the intended audience, are light weight, and ideally are executable.  Many EA programs run aground when the enterprise architects focus on artifacts that they've always wanted but that development teams really aren't very excited about -- yes, it might be interesting to have a comprehensive comparison of cloud technologies versus mainframe technologies, but a collection of reusable services would be fare more interesting to them.  A detailed enterprise data model indicating suggested data attributes would be intellectually interesting to develop, but a list of legacy data sources with a high-level description of their contents would be immediately valuable to many development teams.  A detailed model depicting desired web services would be useful, but an actual collection of working services that I can reuse now would be even better.
   
5. An explicit part of development.  In Disciplined Agile Delivery (DAD) architectural activities are an explicit part of the overall delivery process.  Part of the architectural advice is that delivery teams should work closely with their organization's enterprise architects so that they can leverage the common infrastructure, and sometimes to help build it out, effectively.  Disciplined agile teams realize that they can benefit greatly by doing so. 
   

The Agile Scaling Model (ASM) calls out addressing enterprise disciplines, such as enterprise architecture, as one of eight scaling factors which may apply to a given project.  The interesting thing about this scaling factor is that it's the only one where things get potentially easier for development teams when we move from the simple approach, having a project focus, to the more complex approach, where we have an enterprise focus. By having a common infrastructure to build to, common guidelines to follow, and valuable artifacts to reuse project teams can benefit greatly.  So, I guess my advice is to seriously consider adding enterprise disciplines to your agile strategy.


Recommended Resources:

• Agile Architecture: Strategies for Scaling Agile
• Agile Enterprise Architecture
• The Architecture Owner Role: How Architects Fit in on Agile Teams
• Enterprise Architecture: Reality over Rhetoric
• Enterprise Architecture Survey Results

My new paper Scaling Agile: An Executive Guide is now available.  As the title suggests the paper overviews how to scale agile strategies to meet your organization's unique needs. 

The executive summary:
Agile software development is a highly collaborative, quality-focused approach to software and systems delivery, which emphasizes potentially shippable working solutions produced at regular intervals for review and course correction. Built upon the shoulders of iterative development techniques, and standing in stark contrast to traditional serial or sequential software engineering methods, agile software delivery techniques hold such promise that IBM has begun to adopt agile processes throughout its Software Group, an organization with over 25,000 developers. But how can practices originally designed for small teams (10-12) be “scaled up” for significantly larger operations? The answer is what IBM calls “agility@scale.”

There are two primary aspects of scaling agile techniques that you need to consider. First is scaling agile techniques at the project level to address the unique challenges individual project teams face. This is the focus of the Agile Scaling Model (ASM). Second is scaling your agile strategy across your entire IT department, as appropriate. It is fairly straightforward to apply agile on a handful of projects, but it can be very difficult to evolve your organizational culture and structure to fully adopt the agile way of working.

The Agile Scaling Model (ASM) defines a roadmap for effective adoption and tailoring of agile strategies to meet the unique challenges faced by a software and systems delivery team. Teams must first adopt a disciplined delivery lifecycle that scales mainstream agile construction techniques to address the full delivery process, from project initiation to deployment into production. Then teams must determine which agile scaling factors – team size, geographical distribution, regulatory compliance, domain complexity, organizational distribution, technical complexity, organizational complexity, or enterprise discipline, if any — are applicable to a project team and then tailor their adopted strategies accordingly to address their specific range of complexities.

When scaling agile strategies across your entire IT organization you must effectively address five strategic categories — the Five Ps of IT: People, principles, practices, process, and products (i.e., technology and tooling). Depending on your organizational environment the level of focus on each area will vary. What we are finding within many organizations, including IBM, is that the primary gating factor for scaling agile across your entire organization is your organization’s ability to absorb change.

When you are first adopting agile techniques in your organization a common strategy is to run one or more pilot projects.  When organizing these projects you typically do as much as you can to make them successful, such as finding:

1. Projects where the stakeholders are willing to actively work with you.
2. IT people who are flexible, willing to try new things, and willing to collaborate with one another.
3. IT people who are generalizing specialists, or at least willing to become so.
4. Finding a project which is of medium complexity (therefore it's "real" in the sense that it's significant to your organization) but not one where it can make or break your organization (therefore it's safe to experiment with).

In North America we refer to this as "cherry picking" because you're picking the cherry/best situation that you can find.

Some thoughts:

1. Being agile may not have been the primary determinant of success.  You set up an environment where you have a good relationship with your stakeholders, where you have good people who want to work together, and the project is challenging but not impossible.  Oh, and by the way you adopted a few agile techniques as well.  Sounds to me that situation you could have adopted a few not-so-agile techniques instead and still succeed.  Although my various project success surveys, see my IT surveys page for details, have shown time and again that agile project teams are more successful than traditional project teams I haven't been able to tease out (yet) whether this success is attributable to agile or just attributable to improved project initiation efforts.
   
2. When adopting agile/lean widely across your organization, you can't cherry pick any more.  For the past few years I've been working with IT organizations that are in the process of adopting agile/lean strategies across their entire organization, not just across a few pilot projects.  What these organizations are finding is that they need to find ways to adopt agile where the business isn't as willing to work with IT, where some of the people aren't so flexible or collaborative, where some of the people are narrowly specialized and not as willing to expand their skills, or where the project exhibits scaling factors which motivates you to tailor your agile approach.  It's harder to succeed with agile in these situations because they're not as "cherry" as what you've experienced previously.  Luckily, if you've been successful previously then you now have some agile experienced people, you have successes to reference, and you've likely overcome some problems even in the cherry situations which you have learned from.  So, your cherry successes will hopefully improve your ability to succeed even in "non cherry" situations.
   
3. You need to work smarter, not harder. If the source of your success was actually from improved project initiation practices and not from agile, then recognize that and act accordingly.  Realistically part of your success was from that and part was from agile, and the organizations that adopt a measured improvement approach potentially have the data to determine which practices lead to success and which didn't.  Without the metrics you're effectively flying blind when it comes to deciding how to improve.  There is clearly a mandate for smarter work practices within IT, within your organization as a whole for that matter.
   

If you want to gain more insight into some of the issues that you'll face when adopting agile across your organization, I suspect that you'll find my recent paper Scaling Agile: An Executive Guide to be interesting.  I've got a more detailed paper in the works, so stay tuned to this blog.

• Examining the Agile Manifesto 
• Reworking the Agile Manifesto for Enterprise Agile
• Scaling Agile: Start with a Disciplined Foundation
• Scaling Agile: The Software Development Context Framework
• Disciplined Agile Delivery (DAD) home page
• Generalizing Specialists: Improving Your IT Skills

The SEMAT vision has recently been posted online.  SEMAT is short for Software Engineering and Method and Theory (SEMAT) and I am one of several signatories and a provider of input into the effort. 

There are several reasons why I'm involved with SEMAT:

1. The industry clearly needs something like this.  Ivar Jacobson has been writing and speaking for awhile now about how our industry behaves in a similar manner to the fashion industry -- we lurch from one cool idea (the fashion) to another and few of us observe that the current fashion is often just a rehash of fashion(s) from the past.
2. The right people are involved.  The SEMAT initiative has attracted a wide range of industry experts, including both the old guard, the new "agile guard", and people in between.  Arguably we may be short a few people, the data community isn't well represented and I'm not sure we have the systems community covered well, but we can address those challenges in time.
3. We'll achieve something.  We may not pull of the entire vision, but we are going to produce something of value and I hope that it has a positive impact on the industry.  Time will tell.

I have several thoughts about the SEMAT vision which I'd like to share with you:

1. The vision is coherent.  A lot of reasoned effort went into it's development as you can see when you read it.
   
2. It will be a challenge to identify a non-trivial kernel.  Even developing a kernel language will be hard as people will often stick to their preferred terms.  For example, is it an iteration, a sprint, or a time box?
3. Practitioners may not notice.  It will also be a significant challenge to get practitioners interested in the SEMAT effort and more importantly to leverage the material.  For example, the patterns community has a long history of producing great work which for the most part is ignored by the vast majority of practitioners, with the exception of a handful of the hundreds of patterns out there.  So, although SEMAT is likely to produce some great ideas, will anyone care?
4. Academics may not notice.  I suspect that this will be less of a problem than practitioners not noticing, but it's still a possibility. 

Next steps:

1. Position papers from many of the signatories, including myself, will soon be published at the SEMAT site.   Several non-signatories have been invited to submit papers as well.
2. A workshop is being held in the third week of March in Zurich.  At this workshop the people who published position papers will flesh out our ideas.
3. I'll blog about these things as they occur.

Just like there are 5Ps of marketing, there are also “5 Ps” of IT:

1. People. People and the way they work together have a greater effect on the outcomes of a project than the processes they’re following or the products (tools and technologies) that they’re using. People issues include having visible executive sponsorship, building an environment of trust, empowering staff, focusing on leadership as well as management, recognizing that the primary gating factor when improving processes is people’s ability to absorb change, and promoting a cross-discipline strategy at both the team and individual levels.
2. Principles/philosophies. We’ve found both internally within IBM as well as with many of our customers that there is a need to define a common set of principles to provide a consistent foundation to enable effective teamwork and continuous process improvement. These principles help to guide people’s decisions when their processes and practices don’t directly address the situation which they find themselves in.
3. Practices/patterns. A practice is a self-contained, deployable component of a process.  You might find the IBM Practices interesting.
4. Products. This includes the technologies – such as databases, application servers, networks, and client platforms – and tools such as integrated development environments, testing tools, and project planning tools used to create solutions for stakeholders.
5. Processes. The previous 4Ps do not exist in a vacuum, we need some sort of glue to help piece all of this together. Minimally this glue is a lifecycle although more often than not it is a full process or method.

My experience is that to be successful at software process improvement (SPI) across your entire IT department that you must address these 5Ps. How you address each issue, and to what extent, will vary based on your situation.

My January 2010 DDJ Agile Update, Tragic Mistakes When Adopting Test Driven Development (TDD) , is now online.  In the article I summarize what I consider to be common, and tragic, mistakes that I'm seeing organizations make when they attempt to adopt TDD.

These mistakes include:

• Not providing sufficient training, education, and mentoring
• Not supporting pair programming
• Not reducing the creation of non-executable detailed speculations early in the project
• Not reducing the confirmatory testing being done by their independent QA/testing team
• Completely reducing initial requirements envisioning and architecture envisioning
• Completely reducing parallel independent testing

The article also goes into potential benefits of TDD as well as potential challenges that you're face when adopting it.

As you may know I write the agile update newsletter for Dr. Dobb's Journal (DDJ).  One of the things that I do for DDJ is run the "State of the IT Union" surveys to find out what IT professionals are actually doing in practice. I invite you to fill out the January 2010 edition of the survey at http://www.surveymonkey.com/s/StateOfITUnion. The survey should take you about 5-7 minutes to complete, and your privacy will be completely protected.  

At the end of the survey you will be given the chance to be entered into a draw for one of ten copies of "The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise" by Martin Abbott and Michael Fisher published in December 2009 by Addison Wesley. 
 
The results of this survey will be summarized in a forthcoming newsletter, most likely my March 2010 agile update. Furthermore, this is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at www.ambysoft.com/surveys/ so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.

Agile requirements activities are evolutionary (iterative and incremental) and highly collaborative in nature.  Initially requirements are explored at a high level via requirements envisioning at the beginning of the project and the details are explored on a just-in-time (JIT) basis via iteration modeling and model storming activities.  The way that you perform these agile practices, and the extent to which you do so, depends on the situation in which a project team finds itself.  The Agile Scaling Model (ASM) is a contextual framework for effective adoption and tailoring of agile practices to meet the unique challenges faced by a system delivery team of any size.  To see how this works, let's apply the concepts of the ASM to see how we would scale our agile approach to requirements. 

First, let's consider how a small, co-located team would work.  The first two categories of the ASM are core agile development and disciplined agile delivery, the focus of both are small co-located teams in a fairly straightforward situation.   In these situations simple techniques such as user stories written on index cards and sketches on whiteboards work very well, so the best advice that I can give is to stick with them.  Some teams will take a test-driven development (TDD) approach where they capture their requirements and design in the form of executable specifications, although this sort of strategy isn't as common as it should be (yet!), likely because of the greater skill and discipline that it requires. Traditionalists often balk at this approach, believing that they need to document the requirements in some manner.  But, for a small co-located team working in a collaborative manner, requirements documentation proves to be little more than busy work, often doing nothing more than justifying the existence of a business analyst who hasn't made the jump to agile yet.  Don't get me wrong, there are good reasons to write some requirements documentation, and we'll see this in a minute, but you should always question any request for written specifications and try to find more effective ways to address the actual goal(s) motivating the request.  Never forget that written documentation is the least effective communication option available to you.

Although inclusive tools such as whiteboards and paper work well for requirements, for development activities you will need electronic tools.  You will either put together an environment from point-specific tools or adopt something more sophisticated such as IBM Rational Team Concert (RTC) which is already fully integrated and instrumented.  RTC is a commercial tool, but luckily you can download a 10-license environment free of charge, which is just perfect for a small team.   Larger teams, of course, will need to purchase licenses. One of the things that a disciplined agile delivery approach adds to core agile development is it addresses the full delivery life cycle, which is important because it explicitly includes pre-construction activities such as requirements envisioning.  The first step in scaling agile techniques is to adopt a full delivery life cycle which covers the full range of activities required to initiate a project, produce the solution, and then release to solution to your end users. 

More interesting is the third category of the ASM, Agility@Scale, and how its eight agile scaling factors affect the way that you tailor your process and tooling strategy.  Let's explore how each one could potentially affect your agile requirements strategy:

1. Geographical distribution.  The majority of agile teams are distributed in some manner -- some people are working in cubicles or private offices, on different floors, in different buildings, or even in different countries -- and when this happens your communication and coordination risks goes up.  To counter this risk you will need to perform a bit more requirements envisioning up front to help ensure that everyone is working to the same vision, although this doesn't imply that you need to write detailed requirements speculations which would dramatically increase the risk to your project.  Remember, agilists do just barely enough modeling and are prepared to iteratively elicit the details when they need to do so.  The more distributed the team is the more likely they will need to adopt software-based requirements modeling tools such as IBM Rational Requirements Composer (RRC) which supports streamlined, agile requirements elicitation throughout the delivery life cycle. Index cards and whiteboards are great, but they're difficult to see if you're outside the room where they're posted.  I've written a fair bit about distributed agile development in this blog.
   
2. Team size.  Some organizations, including IBM, are successfully applying agile techniques with teams of hundreds of people.  A team of one hundred people will naturally work much differently than a team of ten people, or of one thousand people.  Large teams are organized into collections of smaller teams, and the requirements for the overall project must be divvied up somehow between those teams.  The implications are that as the team size grows you will need to invest a bit more time in initial requirements envisioning, and in initial architecture envisioning for that matter; you will need to use more sophisticated tools; and may need to use more sophisticated modeling techniques such as use cases and functional user interface prototypes. See large agile teams for more advice.
   
3. Compliance requirement.  When regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 – are applicable you are likely going to be required to capture requirements specifications in some manner and to enact traceability between those requirements.  However, I highly recommend that you read the actual regulations yourself and don't let bureaucrats interpret them for you (doesn't it always seem that their interpretation always results in an onerous, documentation heavy solution?) because I have yet to run into a regulation which required you to work in an ineffective manner.  Managing your requirements as work items in RTC can often more than meet your regulatory requirements for documentation and traceability, although you may want to consider a tool such as IBM Rational RequisitePro for complex regulatory situations.
4. Domain complexity.  The manner in which you elicit requirements for a data entry application or an informational web site will likely be much simpler than for a bio-chemical process monitoring or air traffic control system.  More complex domains will require greater emphasis on exploration and experimentation, including but not limited to prototyping, modeling, and simulation.  Although user stories may be effective as a primary requirements artifact in simple domains, in more complex domains you are likely to find that you need to drive your requirements effort with more sophisticated modeling techniques.
   
5. Organization distribution.  Sometimes a project team includes members from different divisions, different partner companies, or from external services firms.  In these cases, particularly where the work is strictly organized between the various organizations (perhaps for security concerns), you may need a more sophisticated approach to managing the requirements.  RTC enables you to organize the requirements between teams, and then to automatically track progress in real time via the RTC project dashboard.
   
6. Technical complexity.  The technical complexity of a solution can vary widely, from a single platform silo application to a multi-platform application working with legacy systems and data to a full-blown systems engineering effort.  Complex technical domains, just like complex business domains, require more complex strategies for requirements elicitation and management.  The requirements for your legacy systems are likely to have been captured using tools and techniques appropriate for that platform, for example the requirements for your COBOL application may have been captured using data flow diagrams and data models, whereas the requirements for your Java legacy application where captured using UML diagrams.   The subteam working on the COBOL system might be using IBM Rational Application Developer (RAD) and RTC for Z whereas the Java subteam may use Eclipse with RTC.  Because systems engineering projects can stretch on for years, particularly when the hardware is being developed in parallel to the software, sophisticated tooling such as IBM Rational DOORS is often used in these situations.  For more information about systems engineering, see the IBM Rational Harmony process.
7. Organizational complexity.  Your approach to requirements elicitation and management will be affected by a host of organizational complexities, including your corporate culture.  When the culture is flexible and collaborative you can be very agile in your approach to requirements, but as it becomes more rigid you become more constrained in what is considered acceptable and thus take on greater project risk.  For example, many organizations still struggle with their approach to funding projects, often demanding that the project team provides an "accurate" estimate up front to which they will be held to.  This in turn motivates risky behavior on the part of the development, including a "big requirements up front (BRUF)" approach where a detailed requirements speculation is developed early in the project.  This is just one example of how questionable corporate culture can impact the way in which an agile team works.
   
8. Enterprise discipline.  Some organizations have enterprise-level disciplines, such as enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management in place.  These disciplines can easily be agile and from what I can tell the more successful efforts appear to lean more towards the agile end of the spectrum rather than the traditional end.  Having an enterprise business modeling effort underway will affect your project-level requirements strategy -- you'll be able to leverage existing models, have access to people who understand the domain at an enterprise level, and will likely need to map your project efforts back to your enterprise models.  The enterprise modelers will likely be using tools such as IBM Rational System Architect or IBM Websphere Business Modeler.
   

It is important to note that the way that you tailor the agile practices that you follow, and the tools that you use, will reflect the situation that you find yourself in.  In other words, you need to right size your process and the Agile Scaling Model (ASM) provides the context to help you do so.  As you saw above, in simpler situations you will use the simpler tools and techniques which are commonly promoted within the core agile development community.  But, when things become a bit more complex and one or more of the scaling factors applies you need to modify your approach -- just don't forget that you should strive to be as agile as you can be given the situation that you find yourself in.


Further reading:
• Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)
• The Agile Scaling Model (ASM): Adapting Agile Methods for Complex Environments white paper download
• DDJ's November 2009 State of the IT Union Survey for statistics around how organizations are scaling agile in practice
• Requirements Envisioning on Agile Projects at Scale
• Rethinking the Role of Business Analysts: Towards Agile Business Analysis?

Preview



+Advanced Settings
Emoticons
Delay publishing the entry until the following time:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59   (GMT-05:00) Eastern Time (US & Canada)

Allow comments forunlimited days1 day2 days3 days4 days5 days7 days10 days20 days30 days60 days90 days

Specify a custom URL for this entry:
URL: https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/agile_requirements_at_scale

Include URL linking to external media (such as a podcast)
External media URL:


Return To Edit ModePreview
• Print this page
• Share this page
• Follow developerWorks
Share this page:
• Facebook
• LinkedIn
• Twitter
• Delicious
• Digg
• StumbleUpon
• Close [x]
Follow developerWorks:
• Facebook
• Twitter
• Close [x]
Technical topics
• AIX and UNIX
• IBM i
• Information
  Management
• Lotus
• Rational
• Tivoli
• WebSphere
• Cloud computing
• Industries
• Integrated Service
  Management
• Java technology
• Linux
• Open source
• SOA and web services
• Web development
• XML
More...
Evaluation software
• By IBM product
• By evaluation method
• By industry
Events
• Briefings
• Webcasts
• Find events
Community
• Forums
• Groups
• Blogs
• Wikis
• Terms of use
• Report abuse
• IBM Champion
  program
More...
About developerWorks
• Site help and feedback
• Contacts
• Article submissions
Related resources
• Students and faculty
• Business Partners
IBM
• Solutions
• Software
• Software services
• Support
• Product information
• Redbooks
• Privacy
• Accessibility