Whether you’ve never heard of Agile or you just finished your nth Agile project, you need to understand that Agile is here to stay! Are you, the Business Analyst, an extinct species in this new world? Is your career changing? Do you need new skills?
Agile guru and visionary Scott Ambler talked with Adrian Marchis, ModernAnalyst.com's Publishing Editor, and shared his vision on what’s next for Agile and his thoughts on the role of the business analyst in the Agile world.
Modern Analyst.com: First and foremost: What is Agile?
Scott Ambler: There are so many important features of agile:
- It’s evolutionary in nature so it’s iterative and incremental.
- Agile approaches are highly collaborative so we try to communicate as practically as possible.
- We try to avoid documentation and prefer more effective means of communication such as face-to-face.
- We’re self organizing, so that the people that do the work are the ones that are best suited to organize and plan it. That’s a bit different.
- We do some documentation. We will hold some reviews but we’re really smart about it, and we focus on value.
- Other important thing is the focus on quality. We are producing higher quality than we did in the traditional world. This is due to the focus on iterative approaches and factoring, testing and stuff like that.
- We work closely with stakeholders resulting in higher stakeholder satisfaction.
- And probably one of the more radical things, one of the more radical aspects of agile is that we welcome changing requirements. A change in requirement late in the lifecycle is a competitive advantage as long as you can act on it.
So, this is a bit different for a lot of traditionalists. We rethought things a bit and, as a result, we have higher levels of productivity and higher levels of success.
ModernAnalyst.com: One thing you mentioned that is common in agile is the focus on collaboration. Does agile work for projects that have distributed teams?
Scott Ambler: Yes it does actually. This is one of the things that we looked into in the Agile Adoption Survey.
We specifically asked about that and we explored the success rate in three different scenarios:
- near located, where you’re in the same building and you could get together on a daily basis if you had to; that might mean you need to drive but you could do it if you had to.
- Then far located, it’s all plane to get there physically.
We found that co-located agile team had an 83% success rate. Near location team have a 72% success rate and far located had a 60% success rate. So, there is a risk premium the more distributed you become and the implication being that you want to throw better process at those approaches and better tooling. The real implication is that you don’t want to be distributed if you can avoid it.
And if you have to be distributed (if you have people working from home or on different floors in the same building), organizing an approach like that is significantly different than organizing a co-located one. So, this is something the project management community, really needs to pay attention to it because the risks are measurable and have been measured.
So, it shouldn’t be news to anybody. People are doing distributed agile.
ModernAnalyst.com: Another thing you mentioned is that agile is a very iterative process and that iterations are at a core of agile. So how does agile differ from RUP (Rational Unified Process)? Isn’t RUP also an iterative process?
Scott Ambler: RUP is iterative. RUP actually introduced and socialized a lot of the concepts that the agile community takes for granted like the focus on delivering working software on a regular basis, on iterations, on collaborations, on working iteratively, on delivering software incrementally, on testing throughout the lifecycle. So, it really sort of paved the way for the agile community. And RUP can be as agile as you want to make it.
There’re wonderful studies out there, case studies and books and stuff like that on how RUP can be agile. I was writing about how RUP could be agile long before I joined IBM. So, I think that’s an important thing to note. There’s a lot of knowledge out there on agile approaches to RUP.
And what I’m also seeing is that as the agile community is figuring out how to scale and do more complex things; that they are adopting a lot of the techniques that have been in RUP for a long time. It’s frustrating to watch them reinvent the wheel because they apparently don’t want to read about RUP. They like to beat up on RUP a lot. They beat up on RUP a lot but not realizing that there’re a lot of really great ideas … that they can take advantage of. But we’re an industry that loves to reinvent the wheel I guess, so I guess we have to do that yet again.
ModernAnalyst.com: How did you arrive at agile? Have you always worked on agile projects or did you start with more traditional approaches?
Scott Ambler: I’ve been all over the board so it’s interesting. I guess years ago, I was very agile not knowing it. Then I guess in the mid 90s, as I’ve gone to bigger and bigger projects, I started working in a more formal manner and got heavily into CMMI (CMM at the time) for a few years. But really sort of saw the formal approaches struggle. And beginning in the late 90s, began moving away from it. That’s actually one of the reasons why I became so interested in RUP… I was kind of looking at Scrum at the time, too. I was very heavily into process for almost two decades now, I guess. So, I was always looking for better ideas of how to work.
So, yeah, I’ve been on both sides of the fence I guess and can safely say that agile does appear to work. It does work better in practice than the more formal traditional stuff. And a lot of the stuff around traditional element isn’t really formal at all. It certainly isn’t disciplined. It’s more bureaucratic and I think there’s a lot of bureaucracy that gets touted as formalism and touted as discipline.
ModernAnalyst.com: So, you’re saying if I just use a template, it’s not necessarily disciplined, right?
Scott Ambler: Yeah, exactly. There’s actually a really great book out right now, that I don want to suggest to your readers… The book is called “Adrenaline Junkies and Template Zombies.” It’s a collection of patterns and anti-patterns for IT. So, one of the anti-patterns is template zombies; those are people who just fill in templates and making sure it’s filled out. Whether or not it makes sense, just fill it out. Whether or not it’s even the right template, but I have a template, I’m going to fill it out. It’s just a novel waste of time. A lot of wastage in general…. It’s a really interesting book and one of the really neat things about it … they present these patterns and anti-patterns just as a collection of one or two pages in length. … I suspect it will end up being one of those instant classics that we’ll be referring to 20 years from now.
ModernAnalyst.com: I noticed a couple of times you’ve mentioned something that a lot of the people in the traditional world would be surprised; and maybe even people from the agile world. Your survey respondents indicated that they actually used documentation?
Scott Ambler: Yeah. We ran this very detailed survey on how people are modeling and documenting in general. It wasn’t an agile specific thing. So, what we did was we started out with the usual, “Who are you” type questions. We also asked to choose a type of project that you’re going to describe throughout the rest of the survey. They’re given the choices of agile and traditional and iterative and ad hoc. The really neat thing is that it split out almost evenly. So, roughly a quarter, 25% plus or minus five we had in each of these four categories.
It was really interesting to see the habit when it comes to modeling and documentation. One of the things that the agile community is harping on for a few years now, is that agile is actually more disciplined than traditional. I have run the numbers exactly but just eyeballing things, it appears that many of the modeling and documentation practices you see on traditional projects, you also see on ad hoc projects.
One of the reasons why I run these surveys is I want to find out what’s actually happening because there’s a lot of religious discussion out there… And I use the term religion on purpose because people just have these religious beliefs over what works and what they should be doing. What is the proper way of working? There is no data to back it up, right? Particularly in a traditional community, there’s a phenomenal amount of theory out there, which has never really been backed up or if it was looked into, the numbers are basically show: oh-oh, that was a really bad idea to begin with. So, I’m trying to gather the numbers to find out what’s going on.
What was one thing that we found was that the agile folks are just as likely if not more likely than traditional people to write deliverable documentation like user manual, operations documentations, support documentation, system overview documentation. The true deliverable type stuff, which I thought was a bit surprising. So, I was thinking about this a bit; and what I think was going on is one of the things that we do know, is that Agilists are actually more likely to deliver than traditionalists. That type of documentation is something that you would write towards the end of the project as things stabilize. So, I think what’s going on is Agilists are more likely to get to the end, therefore, they are more likely to do the type of work that you would do at the end, which is finish up this documentation. That’s my theory at least. I can’t back that up with real numbers but that’s what the trend appears to…
I was surprised that Agilists were just as likely if not more likely to write documentation.
That’s not what I expected.