Disciplined Agile

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

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

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

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

Related Posts:

• Can you outsource and still be agile?
• Do agile teams take on hard problems?
• Do agile teams face regulatory compliance?
• How geographically distributed are agile teams in practice?
• How large are agile teams in practice?

There are several strategies that you can choose to employ with vertically slicing the requirements for a DW/BI solution. These strategies are described in the following table. There are example stories for each strategy as well as some advice for when to apply each strategy.

Table 1. Vertical slicing strategies for a DW/BI solution.

There are several interesting things about the stories in the table:

1. They are written from the point of view of your stakeholders. They aren’t a technical specification. For example, the first story describes how professors want a list of student names but it isn’t saying from what data source(s), what the element names are, … These are design issues, not requirement issues.
2. They always provide business value. The first story appears to be the beginnings of an attendee list for a seminar. Having something as simple as a list of names does in fact provide a bit of value to professors.
3. Sometimes that business value isn’t (yet) sufficient. It may take several iterations to implement something that your stakeholders want delivered into production, particularly at first. For example, although a list of student names is the beginnings of a class list it might not be enough functionality to justify putting it into production. Perhaps professors also need to know the program that the student is enrolled in, their current year of study, and basic information about the seminar such as the course name, time, and location of it. The decision as to whether the functionality is sufficient to ship is in the hands of your stakeholder (this is one of the reasons why you want to demo your work on a regular basis).

I’ve written a detailed explanation of vertical slicing for a DW/BI solution, and of course there is a wealth of information about agile database techniques in general for those of you interested in greater detail.  

Many people, particularly those new to agile, will tell you that agile teams must be small and co-located.  That is certainly a smart way of organizing a team, but is isn’t required.  In fact agile teams are more likely to be geographically distributed in some way than they are to be co-located.  In practice, not theory.

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following graph summarizes the responses around geographic distribution.

The survey found that less than one-third of agile teams are near-located, where all of the IT members are either co-located or at least in a shared open space.  Previous studies have found that this number drops to one-in-ten teams being near located when you also include primary stakeholders.

Don’t let anyone tell you that you can’t do agile with a geographically distributed team because others are clearly doing so in practice.  Yes, geographically distributed agile is different than near-located agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery.  The Disciplined Agile (DA) toolkit provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including geographic distribution.  In fact, you may find our article around geographically distributed agile teams to be an interesting read.

Related Posts:

• Can you outsource and still be agile?
• Do agile teams take on hard problems?
• How “whole” are agile teams in practice?
• Do agile teams face regulatory compliance?
• How large are agile teams in practice?

The contrite answer is that they’re as large as they need to be, and the contrite agile answer is that they’re as small as they can be.  Now that we’ve gotten the contrite answers out of the way, how large are agile teams in practice?

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following graph summarizes the responses around team size.

This year’s survey found that roughly half (48%) of agile teams are more than 10 people in size and one-quarter are more than 20 people in size.  These findings are similar to what we’ve found in the past with both the 2012 Agility at Scale survey and the 2009 Agility at Scale survey.

In short, don’t let anyone tell you that you can’t do agile with a large team because others are clearly doing so in practice.  Yes, large team agile is different than small team agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery.  The Disciplined Agile (DA) toolkit provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including team size.  In fact, you may find our article around large agile teams to be of interest.

Related Posts:

• Can you outsource and still be agile?
• Do agile teams take on hard problems?
• How “whole” are agile teams in practice?
• Do agile teams face regulatory compliance?
• How geographically distributed are agile teams in practice?

We have recently published a new Inception process goal, Develop Initial Test Strategy.  The potential need for this goal was identified a little over a year ago by an organization that we were actively working with and since then we have worked with several other organizations where it was also clear that this process goal was needed.

The basic idea is that during the Inception phase the team should consider developing an initial test strategy so as to identify how they will approach verification and validation. This includes thinking about how you intend to staff your team, organize your team, capture your plan, approach testing, approach development/programming, choose a platform for test environment(s) platform, choose a platform equivalency strategy, test non-functional requirements, automate test suites, obtain test data, automate builds, report defects, and govern your quality efforts. The goal diagram is depicted in Figure 1 and the update goals overview for Disciplined Agile Delivery (DAD) is shown in Figure 2.

Figure 1. The goal diagram for Develop Initial Test Strategy.

Figure 2. The process goals diagram for DAD.