The Community Blog for Business Analysts

Chase Petsche
Chase Petsche

The Beginning of an Agile Team

I work for a rather large insurance company. We aren't the largest, but we are big enough to have our own SDLC (System Development Lifecycle) that comes packed with paper work, protocol and bureaucracy. Do not misunderstand me - these processes ensure the projects that are active are delivering on time and within budget. My last two efforts 20,000+ hours each have both come in a -2% of budget and were delivered on time. This has been largely due to the depth of documentation in terms of business requirements and tech design that had been accomplished by the time we needed to provide Execution estimates. Pretty remarkable in my opinion. So, what is the problem? Namely 14 months of project work before ANY benefit was delivered to our business partners. We changed direction with this last project - we are trying something new, and even though we've had our fair share of challenges, bumps and bruises, I'm happy with how we've progressed.

It all started when our estimates for delivery based on some scope definition and identification of high-level requirements landed us in July of 2009 - these estimates were given in August of 2008. Our project was denied the approval to continue. We were told to go back and figure out how to deliver in December 2008 or very early first quarter of 2009. Being challenged on estimates is just part of the game, but being asked to cut the effort in half and deliver the same quality of product in half the time is very difficult, if not impossible; we just don't inflate our estimates enough to trim that much fat.

Faced with this challenge, I started researching different project methodologies, different approaches, new ideas. Eventually this search landed me squarely on Agile Development. I pitched the idea to my project manager.

A couple of days later all main players of the project team were assembled. Architects, designers, developers, business analysts, business partners, project management and quality assurance were all together under one room. We reviewed the outlined objectives and in two days had an informal model of the end-state drawn up on a whiteboard. We broke the project into releases and timeboxed iterations (reqs, code, testing) to one month. Release 1 (we term 'Bare Minimum') comprised of the fewest changes needed to deliver an acceptable level of functionality to our business partners.

Release 1 is schedule to transfer later this month - not July. We will have delivered the major infrastructure needed within four iterations. The 2nd release will be within the following month - much quicker. I have a feeling that's how this project will start progressing. With the major infrastructure in place we should be able to role releases out very quickly!

We have learned many, many, many valuable lessons along the way. I'll write about those a separate time. I've been asked by others in our enterprise (different divisions than me) how I was able to persuade the executive sponsors to move to a iterative approach. I think it was a combination of a couple different factors: 1) serious time constraints, our business partners knew it and were willing to try something new; 2) willingness by a few to research, learn and introduce the team to iterative/agile principals; 3) a talented IT team who is willing, able and hungry to try new challenges and succeed in new ways.

Chase Petsche, BA III

This entry was published on Jan 11, 2009 / Chase Petsche. Posted in Business Analysis, SDLC, Process, and Methodologies, Agile Methods. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  0 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Modern Analyst Blog Latests

Jarett Hailes
Jarett Hailes
As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
4 Responses
Howard Podeswa
Howard Podeswa
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
15 Responses
Adrian M.
Adrian M.
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN
1 Responses
Copyright 2006-2019 by Modern Analyst Media LLC