Business Analyst Articles: Business Analysis & Systems Analysis



BA ARTICLE ARCHIVE
» April 2014 (3)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Wednesday, August 25, 2010
8246 Views 4 Comments 7 members voted Article Rating

Whether it is in software development, business analysis, portfolio management or business strategy, everyone wants to be Agile - and nobody wants to admit they aren't Agile. But what does it really take to be Agile? What is the state of Agility like?

First things first, lets get a grip on just what we mean when we say Agile. There are, at least, three different things people talk about when they talk about Agile.

There is the Agile toolkit, that is, the tools, practices, techniques and routines which can help you do a better job. The toolkit is, currently, largely comprised of tools that help you develop software. It contains things like short time-boxed iterations, daily stand-up meetings and frequent planning meetings for project management; test driven development and continuous integration for software engineers; and user stories, feature injection and last-responsible-moment for analysts.

Building on the toolkit are the Agile methods: Scrum, Extreme Programming, DSDM and the new kid-on-the-block Kanban. The methods are prescriptions of how to do things. They draw on the toolkit and add examples, case studies, certificates and the like. Using an Agile method, we are told, will bring about the State of Agile.

Which brings us to the third thing we mean when we talk about Agile: the State of Agile. This is were we, or our employers, want to be. Being Agile implies we are quick on our feet, we can respond to change quickly, we can deliver quickly and seize opportunities. Its not just about speed, although speed makes a lot of things easier; its about delivering what people want, when the want it, where they want it.

This then is out objective: Agility. Using Scrum or DSDM, holding stand-up meetings or writing User Stories are not ends in their own write. They are techniques and practices that have been observed to help organizations achieve Agility.

There are times when we as individuals and as organizations are responsive. If being Agile is somehow different then it implies consistency. One swallow does not a summer make, one act of fast response does not prove Agility. Being Agile has to mean a pattern of being responsive, and fewer, if any, instances of unresponsiveness.

So, given all the hype around Agile where can we find it? To paraphrase the cyber-punk author William Gibson "Agile is already here, its just unevenly distributed."

Being Agile isn't easy, it takes more than sprinkling the Agile Fairy Dust on your team, or using the right buzzwords. Like most things worth having, it takes some effort.

Small companies find it easier to be Agile by their nature. Increasingly larger companies contain pockets of Agility but it doesn't exist across the board. Many of these pockets are isolated.

The London Business School Professor Donald Sull has suggested there are three dimensions to Agility: Strategic, Portfolio and Operational. Most of today's discussion around Agility, particularly in the technology space, relate to just operational Agility.

Today's Agile tools allow opportunities to be spotted sooner and acted on quicker. For many companies that is enough. After all, one doesn't need to be the fastest animal in the jungle, just faster than your competitors, and faster than those who would eat you.

Even these operational tools offer the promise of more. Unfortunately Agile teams can find themselves in difficulty when the wider organization isn't Agile. Teams that could seize opportunities and satisfy customers better find that the annual planning cycle and budgeting rounds are not a good fit for Agile.

This is where Portfolio Agile comes into play. In a world were Lehman's Brothers disappeared overnight, where credit markets froze solid in a few days and volcanic ash brought an industry to its knees it doesn't make sense to decide your projects in September, provide budget in January, start them in February and spend the rest of the year force them into an artificial timetable.

Agile practitioners know this because Agile is empirical in nature and feedback driven. Agile practitioners don't claim to know how long X will take at the start, set them a deadline and they'll sure as hell try and meet it but they've wont predict until they have data.

Portfolio management - and governance for that matter - need embrace some of the Agile tools themselves. Regular reviews, small amounts of money given out when requested and work redirected when the benefits don't show.

Obviously this is going to effect, and be effected by: Strategy. Ask yourself: do you want to be an Agile company? Is Agile your strategy? Or just a means to an end? Are you prepared to do things different to be Agile?

Actually, Agile and modern business strategy are a pretty good fit already. Many strategists gave up on long range planning and five year plans a while ago. Strategists have long known strategy is only part planned, it is also part emergent, the result of learning and feedback.

Still an Agile strategy needs to be turned into action - talk without action doesn't get you very far. Broadly speaking strategy is turned into action through two routes: the operational decisions that are made day-to-day, and the structure and form of the business.

Successful strategy execution depends on thousands of small decisions made every day by employees at all levels in the organization. The Agile way is: fail fast, fail cheap; be prepared to try something, take a risk, see how it goes, if it works do some more, if it doesn't then stop doing. Remember: Agile is empirical, try something, see what the result is, adjust.

Which conveniently brings us back to form. If you are going to build something to see if they come you need to structure your teams so the team is responsive and responsible. The team needs to be equipped with all the skills it needs: builders, analysts, and everyone else to do end-to-end work. Fail cheaply also means the teams should be minimally staffed at first and only grow with success.

Agile strategy without Agile delivery might work, but it could be very expensive. If your strategy isn't Agile then there might still be tools in the Agile toolkit to help you do it, and some of the methods may help delivery. Agile methods can be used to cut costs but that won't make you Agile, it will only make you cheap.

As more and more companies want to be Agile the question that becomes more and more important is "Why do you want to be Agile?" which is another way of asking "What do you want Agile to do for you?". Only when you understand that do you really know what your objective is.

Author: Allan Kelly, Software Strategy

Allan Kelly is a Conference Speaker for the Business Analysis Conference Europe 2010.

He will be presenting the following session: “Objective Agility: What does it take to be an Agile Company?” at the conference.

Allan Kelly helps companies and teams adopt and deepen their Agile practices. His focus is on the management of software development work, including business analysis; product, project and change management, and business strategy alignment. He is the author of "Changing Software Development: Learning to be Agile" and is currently working on a book of business strategy patterns for software companies.

IIBA UK Conference 2010 - Business Analysis Conference


Article photo © Sylvie Thenard - Fotolia.com

Rate this:

COMMENTS

Posted on Wednesday, August 25, 2010 12:55 PM by
epeters1
Allan,
I agree that businesses have to ask themselves whether or not they are ready to become agile, but I think the most important obstacle to look at is the separation between business and IT. (i.e. analyst/developer process relationship). Closing this gap gives most organizations the push to enter the 'State of Agile' - and it takes the toolkit and the methods to do so. So when an executive at a company asks themselves "are we ready to go agile?" - they should look to the balance of effectiveness and efficiency in their IT department's development initiatives, and make sure its providing the organization with what it needs, when it needs it.

The agile mentality in operations, I'd think, emanates to strategy and portfolio agility. IT agility attributes to business agility, which in one way or another, is or should be a goal of any company (especially those in competitive industries.) I suppose the combination of those three agile dimensions form overall business agility, right?

Nice post,
Eric
www.mendix.com
epeters1
Posted on Wednesday, August 25, 2010 10:23 PM by
zarfman
Greetings:

You wrote: The Agile way is: fail fast, fail cheap; be prepared to try something, take a risk, see how it goes, and if it works do some more, if it doesn't then stop doing. Remember: Agile is empirical, try something, see what the result is, and adjust.

Zarfman writes: I am reminded of the three part lag. How much time elapses before a failure is discovered? How long will it take to arrive at a fix for the failure? How long will it take to find out if the fix worked?

How long does it take to fix the problem? I would suggest that it depends on the skill level of the problem solvers. Time seems to fly by when one is trying to find a seemingly elusive solution to a problem. During my professional career I’ve fired many an individual who couldn’t deliver on their promises.

You wrote: This is where Portfolio Agile comes into play. In a world were Lehman's Brothers disappeared overnight, where credit markets froze solid in a few days and volcanic ash brought an industry to its knees.

Zarfman writes: Lehman Brothers took a risk that turned out to be fatal. Moreover, fraudulent transactions didn’t help their cause. Two other banks demanded additional collateral for loans that Lehman desperately needed. Even Barclays’ who bought part of Lehman didn’t understand that what they bought was an illusion not worth what they paid for it. All in all Lehman was a very complicated problem that still is causing problems in the form of billion dollar law suits.

You wrote: It doesn't make sense to decide your projects in September, provide budget in January, start them in February and spend the rest of the year force them into an artificial timetable.

Zarfman writes: What alternative do you suggest?

Regards,

Zarfman
zarfman
Posted on Thursday, August 26, 2010 3:51 PM by
Baronvonh
Please proofread. There are too many usage errors for me to continue reading.
Baronvonh
Posted on Thursday, August 26, 2010 4:59 PM by
zarfman

Greetings Baronvonh:

I had my wife read my post. She understood what I was trying to say. Moreover, she has no background in business analysis or IT. Accordingly, I don't plan to make any changes.

Regards,

Zarfman
zarfman
Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Big Data Analytics for Dummies
Finally, a Big Data book written for business analysts, BI professionals, and data scientists!  Big Data Analytics for Dummies is a valuable resource that addresses the practical dilemmas surrounding Big Data...

A Buyer’s Guide to Customer Analytics
Discover the five crucial criteria of a customer analytics platform in A Buyer’s Guide to Customer Analytics now.

Free Analytics software: Alteryx Project Edition
Alteryx Project Edition provides you with a single solution that delivers the data blending, analytics, and sharing capabilities of Alteryx with just enough allowed runs of your workflow to solve one business problem or to complete one project.

The Business Analyst's Guide to Hadoop
Get started with Hadoop using this whitepaper, "The Business Analyst's Guide to Hadoop".

Copyright 2006-2013 by Modern Analyst Media LLC