Agile Project Management
Managing in the face of ever-changing
requirements
Kevin Aguanno, PMP, MAPM
OK, here is the first one I have looked at that has ‘Agile’ in the title. It is basically an Agile overview, by a published author on the topic.
My comments/thoughts:
… why are ‘traditional’ methods always described as forcing the Requirements to be ‘locked down’, ie. no changes allowed during development? A simple Change Management process can be used to address any and all possible changes to a project, not just requirement changes. The aim of such a process is not just to identify a change, but to document its impact on the project. Agile projects seem to live in a fantasy world where the sponsor did not demand to know the cost, effort and target date before agreeing to pay for the project, so I guess Agile sponsors don’t care about changes that could increase cost or delay delivery.
…my favourite Agile principle: ‘Working software over comprehensive documentation’… how many times have you heard a maintenance programmer a few years down the road after implementation complain that the system documentation he/she has to work with is ‘too comprehensive’?
…Agile project characteristic: ‘Early and continuous delivery of usable deliverables’… Agreed, so why can’t you know what you will deliver before you start, if each delivery is small? The presenter describes Feature Driven Development as an Agile methodology, where it says the first thing to do is build a model for the whole domain, then start iterating. Well, what is in that model? Your requirements!: a function model, a data model, a process model, whatever… those are documentation of Requirements.
…about Features (in the SCRUM methodology too); what does a feature look like? How to you document it? How do you know what data is needed for a Feature? Cute names don't an artifact make.
OK, that’s it for now. I have looked at about a dozen other presentations as well, all of them pretty good but nothing has jumped out at me to comment on. I know there are at least a few more on Agile I have yet to look at, but I won’t write about Agile again unless something really interesting comes up.
Wednesday, May 17, 2006
Saturday, May 13, 2006
BA World - afterthoughts
So, my presentation covered the content of a lot of my early posts on this blog, i.e:
-what is an Information System Requirement...
- you need multiple documenting artifacts to capture different types of requirements
- the multiple artifacts need to be integrated to eliminate duplication/redundancy
My sense of the audience that came to see me.... ..........wait, I have to say that I am beyond thrilled that upwards of 50 people did come to see me, certainly encourages me to do it again..... ..... anyway, I think I was speaking to some people who are not (yet) getting to use any artifacts, and are still churning out paragraph-based documents... and some people are only getting to use one artifact and trying to cram everything into it, the best evidence for 'one artifact does not fit all'. So, I hope I gave people some ideas that will help them back in their work-places.
I was also a little surprised that when I asked if there were any data modelers in the room, only one person raised their hand; and that person seemed to be young enough not to know who Ron Ross is, or was to data modeling. I am still not sure what to make of that, Data Modeling is still the senior method/artifact to me, everything else builds on the data, in Use Cases, in Business Rules, and more.
In the meantime, I have started scanning through some of the other presentations, so will report next on the highlights next time...
-what is an Information System Requirement...
- you need multiple documenting artifacts to capture different types of requirements
- the multiple artifacts need to be integrated to eliminate duplication/redundancy
My sense of the audience that came to see me.... ..........wait, I have to say that I am beyond thrilled that upwards of 50 people did come to see me, certainly encourages me to do it again..... ..... anyway, I think I was speaking to some people who are not (yet) getting to use any artifacts, and are still churning out paragraph-based documents... and some people are only getting to use one artifact and trying to cram everything into it, the best evidence for 'one artifact does not fit all'. So, I hope I gave people some ideas that will help them back in their work-places.
I was also a little surprised that when I asked if there were any data modelers in the room, only one person raised their hand; and that person seemed to be young enough not to know who Ron Ross is, or was to data modeling. I am still not sure what to make of that, Data Modeling is still the senior method/artifact to me, everything else builds on the data, in Use Cases, in Business Rules, and more.
In the meantime, I have started scanning through some of the other presentations, so will report next on the highlights next time...
Friday, May 12, 2006
The day after BA World
First off, it took me 3 hours to drive home, downtown Toronto to K/W (assuming u know where that is..)
Other than presenting, the most fun I had was listening to Scott Ambler dissing Business Analysts, but not Business Analysis, on a panel discussion. I had one innocent question when one of the other panelists mentioned offshoring, but after some other questions from the floor that had Scott complaining about 'useless documentation produced by BAs' and 'BAs should learn to code', I got the mike back and vented on him a bit about how BAs like me work successfully with developers every day... then when things slowed down, I got the mike again and the MC (good Ms. Kerton!) warned me to ask a question only, which I was going to do, as I started to speak Scott called me an 'evil man'! All in good jest, of course, and I accept it as a compliment. I must see if he has a forum and continue the discussion, if possible. He is certainly one of the most recognized proponent of Agile approaches, so I give him full credit for coming to BA World and participating on the panel (about the future of the BA role). Our wonderfull IIBA president, Kathleen Barret, was also on the panel and had plenty of chances to mix it up with Scott as well, but they agreed on a few things too.It is somewhat amazing/exciting that we actually have a controversial subject to discuss, so also full credit to BA World for addressing it. I had to duck out before the session ended to get ready for my own little show, so if anyone else was there and has any news on how it ended, do let me know.
The other new and good event was roundtable group discussions on various topics like where does the BA role belong in an organization, and BAs as PMs, and (my favourite) Agile Analysis. Volunteers facilitated the sessions, and groups of 5 or 6 people made for great discussions; there were roundtables on PM subjects too (as BA World is partnered with the longer-running Project World), so I hope the PMs enjoyed theirs as well.
That's it for now. I am gathering more thoughts on how my presentation went, and the very good discussions I had with some attendees afterwards, plus I have some business cards and email addresses to check up on, and all the the presentations I didn't see on CD to go over... so more on BA World in my next post.
Other than presenting, the most fun I had was listening to Scott Ambler dissing Business Analysts, but not Business Analysis, on a panel discussion. I had one innocent question when one of the other panelists mentioned offshoring, but after some other questions from the floor that had Scott complaining about 'useless documentation produced by BAs' and 'BAs should learn to code', I got the mike back and vented on him a bit about how BAs like me work successfully with developers every day... then when things slowed down, I got the mike again and the MC (good Ms. Kerton!) warned me to ask a question only, which I was going to do, as I started to speak Scott called me an 'evil man'! All in good jest, of course, and I accept it as a compliment. I must see if he has a forum and continue the discussion, if possible. He is certainly one of the most recognized proponent of Agile approaches, so I give him full credit for coming to BA World and participating on the panel (about the future of the BA role). Our wonderfull IIBA president, Kathleen Barret, was also on the panel and had plenty of chances to mix it up with Scott as well, but they agreed on a few things too.It is somewhat amazing/exciting that we actually have a controversial subject to discuss, so also full credit to BA World for addressing it. I had to duck out before the session ended to get ready for my own little show, so if anyone else was there and has any news on how it ended, do let me know.
The other new and good event was roundtable group discussions on various topics like where does the BA role belong in an organization, and BAs as PMs, and (my favourite) Agile Analysis. Volunteers facilitated the sessions, and groups of 5 or 6 people made for great discussions; there were roundtables on PM subjects too (as BA World is partnered with the longer-running Project World), so I hope the PMs enjoyed theirs as well.
That's it for now. I am gathering more thoughts on how my presentation went, and the very good discussions I had with some attendees afterwards, plus I have some business cards and email addresses to check up on, and all the the presentations I didn't see on CD to go over... so more on BA World in my next post.
Thursday, May 11, 2006
Live from BA World
Hi all, just a quick note at 3:30 pm at Business Analyst World in Toronto... did my presentation at 1:15, and all seems to have gone well. It was still a little nervewracking, and the clipon microphone came off twice, but I finished early, took some questions, and had some good after-presentation discussions with a few people. Verbal reviews were encouraging, now just have to wait for the feedback sheets(!).
I recommend speaking at a conference like this, if you have something you want to share. What you may think is normal or well-known, still might news to others... anyway, I will post some more on BA World over the next few days.
I recommend speaking at a conference like this, if you have something you want to share. What you may think is normal or well-known, still might news to others... anyway, I will post some more on BA World over the next few days.
Tuesday, May 09, 2006
PM/BA World this week.
OK, Project Management and Business Analyst World are on this week in Toronto; I make my presentation on Thursday (May 11).
My subject is Integrating Business Analysis Artifacts (including Business Rules).The details are available at :http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646
I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld. See http://www.projectworldcanada.com/ for details.So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.
My subject is Integrating Business Analysis Artifacts (including Business Rules).The details are available at :http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646
I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld. See http://www.projectworldcanada.com/ for details.So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.
Wednesday, April 26, 2006
Anyone familiar with 'Profesy' from SOFEA Inc.?
Overall I have not been impressed with automated Requirements tools from vendors like Rational or MKS; they just seem to be just list managers with change control... but I would like to hear from anyone using one of these products who finds them useful.
The main reason for today's post is a white paper I read today, from SOFEA Inc about their 'Customer Oriented Software Development' Methodology, which is supported by their Profesy tool (which is a pretty aggresive, self-confident name, even if it is spelled with an 'f' insteaf of 'ph').
The white paper is a pretty good, almost entertaining read for 15 pages, laying out how getting the right Requirements is the most important part of software development ( a little ego-stroking for us Business Analysts) but the methods used in the past (waterfall) could not ensure getting it right, and newer methods (CMMI or Agile) that were supposed to improve this have not made any impact.
So, what is SOFEA suggesting? ...that Requirements can't really capture the 'Customer Idea' that initiates software projects, you need to transform the 'Customer Idea' into 'Customer Needs' first, and from those you can generate all the rest of the usual development artifacts, starting with the Requirements... and then the White paper ends! No example of a Customer Need! or how it is different than what a Requirement would be!
I have been cruising their website (www.sofeainc.com) and have not seen any more detail; there are a few more documents available to download, but they make you identify yourself and your company before you can get the document ( I hate websites that do that!) , and I am not yet ready to contribute my identity to their marketing database. Perhaps they consider the definition and content of a 'Customer Need' to be a company secret, but they have to give it up at some point.
So, is anyone out there using Profesy? or has at least seen some more details that they could share? If so, post a comment to let me know. I am pretty much prepared to be underwhelmed if or when I get more details, but the white paper was just so good as far as it went, I can only hope they really have something good here.
The main reason for today's post is a white paper I read today, from SOFEA Inc about their 'Customer Oriented Software Development' Methodology, which is supported by their Profesy tool (which is a pretty aggresive, self-confident name, even if it is spelled with an 'f' insteaf of 'ph').
The white paper is a pretty good, almost entertaining read for 15 pages, laying out how getting the right Requirements is the most important part of software development ( a little ego-stroking for us Business Analysts) but the methods used in the past (waterfall) could not ensure getting it right, and newer methods (CMMI or Agile) that were supposed to improve this have not made any impact.
So, what is SOFEA suggesting? ...that Requirements can't really capture the 'Customer Idea' that initiates software projects, you need to transform the 'Customer Idea' into 'Customer Needs' first, and from those you can generate all the rest of the usual development artifacts, starting with the Requirements... and then the White paper ends! No example of a Customer Need! or how it is different than what a Requirement would be!
I have been cruising their website (www.sofeainc.com) and have not seen any more detail; there are a few more documents available to download, but they make you identify yourself and your company before you can get the document ( I hate websites that do that!) , and I am not yet ready to contribute my identity to their marketing database. Perhaps they consider the definition and content of a 'Customer Need' to be a company secret, but they have to give it up at some point.
So, is anyone out there using Profesy? or has at least seen some more details that they could share? If so, post a comment to let me know. I am pretty much prepared to be underwhelmed if or when I get more details, but the white paper was just so good as far as it went, I can only hope they really have something good here.
Wednesday, April 12, 2006
Requirements are a means to an end.
A scan through my previous entries will confirm that I view documented Requirements as an essential artifact for systems development.
Given that, I don't want to imply that Requirements are 'sacred' in some way or worse yet, an end in themselves. They are a vital but intermediate deliverable along the way to delivering the solution that your business needs to succeed.
This brings me to the often-cited problem in Requirements work most commonly known as 'analysis paralysis'. Requirements gathering, analysis, and documentation cannot be some endless task that defers delivering the Requirements because of uncertainties or changes in the details of the Requirements. It does require sufficient time, but historically I have seen the effort spent on Requirements average around 25% of a total systems project. If you are spending more than 25% on a regular basis, you might have some paralysis going on.
(Sidebar: the other 75%? Typically I see 50% on design, build, and unit testing, and 25% on the rest of Testing: System, User, Acceptance, Volume, Regression, and probably more I am forgetting.)
How can you avoid paralysis?
- Define a clear scope of the Business process or function that is to be supported by the solution. If you have or can quickly put together a process map (start by defining all the external events the business must respond to), then it can be shown what you are are gathering Requirements for, and what you are not. Having that Process Map also helps identify units of work in process steps that can be documented as Use Cases.
- If nailing scope down is difficult, then time-box the work; take what you do have defined as likely in scope, and spend 2 to 3 weeks of focussed work with business involvement, and you will be surprised the volume of Requirements you will produce. Stop at the end of the time-box, and re-group/review with your Sponsor. You may have enough to start a round of development/delivery, or a better view of how much time you need to finish a complete set of Requirements.
It is also important to recognize the Requirements will change, but not necessarily for the reasons you might think. For example, you may document a portion of the requirements and review it with the business staff involved in the gathering, and you just may have written it down wrong or misunderstood what they told you; reviews/walkthroughs are essential for any quality product. If you can succeed in getting agreement that the documented Requirements are correct from the business, the amount of change after that point will be minimal.
(Agile methods proponents will tell you the business changes too much and too often for documented requirements to remain valid; don't believe it. Core information systems requirements about collecting, storing and using data do not change much over time; what does change the most is process/procedural activities, the main reason why an Information System should not automate business process, especially now that BPM tools are available that are designed to accommodate procedure changes. As author Steve McConnell recently said, the main reasons requirements change during agile development is that the requirements were not fully investigated before development started.)
The last advice I would offer to fellow BA's is that you document the Requirements, but you do not own them; they belong to the business. So, don't agonize over what may happen to Requirements after you have delivered them. There is a quote about working whose source I must track down, as it guides me every day; it is:…
"Show up on time, do your best, don't get attached to the results".
Wise words. Besides, there is always another project up next that needs its Requirements documented, so get to it!…
Wednesday, April 05, 2006
Discussion of Agile and Business Analysis/Analysts, continues
Here's an email message set from the Agile Analysis Yahoo Group...
From : Chris Matts
Reply-To :
Sent : Wednesday, March 29, 2006 2:17 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Hi Jeff, Kent. Long time no speak. Hello David
Lets get something straight. There is a place for business analysts within Agile. Business Analysis is not about writing documents though.Lets get something else straight. The reason Agile says they do not need them is because approximately 98% of BAs are crap. I should know I have interviewed close to 100 in the last year or so. One of the problems is that no one knows what a BA is. I do (from my perspective) and as a result I have tried to train the 20 people in my department to do the role. Guess what..... they are lazy/scared and do not want to change.........
Does this sound like Agile?Drop me a line and we can chat when I'm sober.
Chris
From : David Wright
Reply-To : agileanalysis@yahoogroups.com
Sent : Thursday, March 30, 2006 6:03 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Chris, what are you drinkin'? I think I could use some too...
"Business Analysis is not about writing documents though."
Right, it is about documenting Requirements, which is different.
I have written about this a fair bit at
http://www.businessanalysis56.blogspot.com/
From : Kevin Brennan
Reply-To :
Sent : Thursday, March 30, 2006 7:41 PM
To : agileanalysis@yahoogroups.com
Subject : Re: [agileanalysis] Any activity in this Group?
Chris Matts wrote:> Lets get something else straight. The reason Agile says they do not need> them is because approximately 98% of BAs are crap....
That's one of the big reasons the IIBA got started. The goal behind developing the Body of Knowledge and associated certification activities is to try and get people to understand what a BA does and does not do. I agree, it's hard to find someone with the right general skills.A big part of the problem is that a lot of BAs are "accidental"; they get seconded to the job as part of an IT project and then become a"Business Analyst" because their old job got filled while the poject was going. The result is that many BAs are little more than above-average end users with no special training or aptitude for the role.-------------------------------------
Kevin Brennan, PMPCo-Chair, IIBA Body of Knowledge Committeekevin.brennan@theiiba.org
From : Jeff Patton
Reply-To : agileanalysis@yahoogroups.com
Sent : Friday, March 31, 2006 8:24 AM
To :
Subject : RE: [agileanalysis] Any activity in this Group?
:-) Good to hear from you Chris! Although Chris might be drunk, his point isn't completely off. I'll be honest. I work alongside business analysts in agile contexts, and struggle with their thought processes at times. I consider myself an interaction designer. I work with end users and business stakeholders, talk with them about their goals, build models, think hard, and work to arrive at solutions that optimize business's return on investment while meeting user goals. I call that work design. The BAs I work with do very much the same work, only they refer to it as requirements capturing. I struggle with the term requirements capture vs. design. For me design implies some creativity and invention - and most importantly some responsibility. Requirements capture doesn't imply any of those things to me - sounds sort of like a passive thing that requires good listening and recording skills. Although I know that if I pick up any decent book on requirements work, I'll find the words creativity and invention in it - I just won't find the words design in it -at least not in reference to what the BA does. I sometimes wonder if that posture of elicitation and capture vs. a posture of responsible design isn't part of the key to their effectiveness - or lack thereof.
Although I'm not drunk, my plane is over 3 hours late and I'm ticked off and stuck at the airport. So if this sounds inflammatory to BAs - I'll blameUnited Airlines.
Cheers,-Jeff
From : David Wright
Reply-To :
Sent : Friday, March 31, 2006 9:58 AM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
In short, having Requirements first supports the choice of solution, which may not always be to design and develop something new.I can't recall where I first heard this mantra-like statement, but it has stayed with me:
"Re-Use before Buy, Buy before Build, Build for Re-Use".
Requirements are like blue-prints, especially those using models. If system delivery and software development (which are not always the same thing) are to move beyond being a craft to a real discipline, we have to stop starting with Design and know What to build before we decide How.
Dave Wright
>From: "Kent J. McDonald" mailto:kent@kentmcdonald.com
Reply-To: agileanalysis@yahoogroups.com>
To: agileanalysis@yahoogroups.com>
Subject: RE: [agileanalysis] Any activity in this Group?>
Date: Fri, 31 Mar 2006 21:13:11 -0600>>
Is it necessarily a bad thing that Software Development is a craft?
>-->Kent J. McDonald>kent@kentmcdonald.com>http://www.kentmcdonald.com>Words to lead by: Collaborate; Iterate; Serve the Team; Consider Context;>Practice Excellence; Reflect and Adapt; Deliver Value
From :
David Wright
Reply-To :
Sent :
Saturday, April 1, 2006 9:22 PM
To : agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
"Is it necessarily a bad thing that Software Development is a craft?"
A craft-work approach to delivery implies custom-made, low-volume and high-cost results. Shoes haven't made by cobblers for a century or two, and just because software is a relatively new and uniquely malleable product, this does not mean it won't and shouldn't be produced using engineering-based production methods. This will be the way software will become a product where quality is assumed, not just hoped for.
What implications does this have for programming as we know it? It will become less and less of a technical creation skill amd more of an assembly role, putting together software components to create systems.
(If that upsets any programmers reading this, well, I have been out drinking some single-malt tonight, so my opinions may be a little direct by this time of night.... :-) )Dave W
From : Chris Matts
Reply-To :
Sent : Wednesday, March 29, 2006 2:17 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Hi Jeff, Kent. Long time no speak. Hello David
Lets get something straight. There is a place for business analysts within Agile. Business Analysis is not about writing documents though.Lets get something else straight. The reason Agile says they do not need them is because approximately 98% of BAs are crap. I should know I have interviewed close to 100 in the last year or so. One of the problems is that no one knows what a BA is. I do (from my perspective) and as a result I have tried to train the 20 people in my department to do the role. Guess what..... they are lazy/scared and do not want to change.........
Does this sound like Agile?Drop me a line and we can chat when I'm sober.
Chris
From : David Wright
Reply-To : agileanalysis@yahoogroups.com
Sent : Thursday, March 30, 2006 6:03 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Chris, what are you drinkin'? I think I could use some too...
"Business Analysis is not about writing documents though."
Right, it is about documenting Requirements, which is different.
I have written about this a fair bit at
http://www.businessanalysis56.blogspot.com/
From : Kevin Brennan
Reply-To :
Sent : Thursday, March 30, 2006 7:41 PM
To : agileanalysis@yahoogroups.com
Subject : Re: [agileanalysis] Any activity in this Group?
Chris Matts wrote:> Lets get something else straight. The reason Agile says they do not need> them is because approximately 98% of BAs are crap....
That's one of the big reasons the IIBA got started. The goal behind developing the Body of Knowledge and associated certification activities is to try and get people to understand what a BA does and does not do. I agree, it's hard to find someone with the right general skills.A big part of the problem is that a lot of BAs are "accidental"; they get seconded to the job as part of an IT project and then become a"Business Analyst" because their old job got filled while the poject was going. The result is that many BAs are little more than above-average end users with no special training or aptitude for the role.-------------------------------------
Kevin Brennan, PMPCo-Chair, IIBA Body of Knowledge Committeekevin.brennan@theiiba.org
From : Jeff Patton
Reply-To : agileanalysis@yahoogroups.com
Sent : Friday, March 31, 2006 8:24 AM
To :
Subject : RE: [agileanalysis] Any activity in this Group?
:-) Good to hear from you Chris! Although Chris might be drunk, his point isn't completely off. I'll be honest. I work alongside business analysts in agile contexts, and struggle with their thought processes at times. I consider myself an interaction designer. I work with end users and business stakeholders, talk with them about their goals, build models, think hard, and work to arrive at solutions that optimize business's return on investment while meeting user goals. I call that work design. The BAs I work with do very much the same work, only they refer to it as requirements capturing. I struggle with the term requirements capture vs. design. For me design implies some creativity and invention - and most importantly some responsibility. Requirements capture doesn't imply any of those things to me - sounds sort of like a passive thing that requires good listening and recording skills. Although I know that if I pick up any decent book on requirements work, I'll find the words creativity and invention in it - I just won't find the words design in it -at least not in reference to what the BA does. I sometimes wonder if that posture of elicitation and capture vs. a posture of responsible design isn't part of the key to their effectiveness - or lack thereof.
Although I'm not drunk, my plane is over 3 hours late and I'm ticked off and stuck at the airport. So if this sounds inflammatory to BAs - I'll blameUnited Airlines.
Cheers,-Jeff
From : David Wright
Reply-To :
Sent : Friday, March 31, 2006 9:58 AM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
In short, having Requirements first supports the choice of solution, which may not always be to design and develop something new.I can't recall where I first heard this mantra-like statement, but it has stayed with me:
"Re-Use before Buy, Buy before Build, Build for Re-Use".
Requirements are like blue-prints, especially those using models. If system delivery and software development (which are not always the same thing) are to move beyond being a craft to a real discipline, we have to stop starting with Design and know What to build before we decide How.
Dave Wright
>From: "Kent J. McDonald" mailto:kent@kentmcdonald.com
Reply-To: agileanalysis@yahoogroups.com>
To: agileanalysis@yahoogroups.com>
Subject: RE: [agileanalysis] Any activity in this Group?>
Date: Fri, 31 Mar 2006 21:13:11 -0600>>
Is it necessarily a bad thing that Software Development is a craft?
>-->Kent J. McDonald>kent@kentmcdonald.com>http://www.kentmcdonald.com>Words to lead by: Collaborate; Iterate; Serve the Team; Consider Context;>Practice Excellence; Reflect and Adapt; Deliver Value
From :
David Wright
Reply-To :
Sent :
Saturday, April 1, 2006 9:22 PM
To : agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
"Is it necessarily a bad thing that Software Development is a craft?"
A craft-work approach to delivery implies custom-made, low-volume and high-cost results. Shoes haven't made by cobblers for a century or two, and just because software is a relatively new and uniquely malleable product, this does not mean it won't and shouldn't be produced using engineering-based production methods. This will be the way software will become a product where quality is assumed, not just hoped for.
What implications does this have for programming as we know it? It will become less and less of a technical creation skill amd more of an assembly role, putting together software components to create systems.
(If that upsets any programmers reading this, well, I have been out drinking some single-malt tonight, so my opinions may be a little direct by this time of night.... :-) )Dave W
Tuesday, April 04, 2006
Agile falls short, says author
Software development concept hasn’t blossomed: McConnell
By: Paul Krill(31 Mar 2006)
From Computerworld Canada: www.itworldcanada.com
The article is at http://www.itworldcanada.com//Pages/Docbase/ViewArticle.aspx?ID=idgml-8e5499c3-e4fe-49ac-8230-9fa5a564512e
but you might have to register to read it.
Steve McConnell lists his worst ideas of Agile, my favourites being:
•Requirements are always changing.”[The] single most common source of changing requirements [is] requirements that were not significantly investigated in the first place,” said McConnell.
• Requirements can be gathered or they just drop out of the sky like manna from Heaven.
• Entrepreneurial companies cannot be afraid of risk.
• One single development approach will work best for all projects.
Mr. McConnell is a published author on software topics; while I don't know what his original views of Agile might have been, he has certainly laid a shot over the bow of agile proponents.
Comments, anyone?
By: Paul Krill(31 Mar 2006)
From Computerworld Canada: www.itworldcanada.com
The article is at http://www.itworldcanada.com//Pages/Docbase/ViewArticle.aspx?ID=idgml-8e5499c3-e4fe-49ac-8230-9fa5a564512e
but you might have to register to read it.
Steve McConnell lists his worst ideas of Agile, my favourites being:
•Requirements are always changing.”[The] single most common source of changing requirements [is] requirements that were not significantly investigated in the first place,” said McConnell.
• Requirements can be gathered or they just drop out of the sky like manna from Heaven.
• Entrepreneurial companies cannot be afraid of risk.
• One single development approach will work best for all projects.
Mr. McConnell is a published author on software topics; while I don't know what his original views of Agile might have been, he has certainly laid a shot over the bow of agile proponents.
Comments, anyone?
Friday, March 31, 2006
Discussion on Agile, and Methodologies in General, Part 3
From :
Kent J. McDonald
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 7:33 PM
To :
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry to hear you were under the weather. That seems to be going aroundhere as well. I've moved up the sections I am replying to and cutting therest out. Hope that's ok (want to keep the message from getting too long).
DAVEW....1) How much time (hours per day) do Agile developers need to be withcustomers/users? Finding available time on key people's schedules is aconstant challenge for me; I basically have to prepare ahead for a veryfocused 60 to 90 minutes that I might get a day (or every 2 days) to gatherrequirements. I often end up addressing multiple projects with differentbusiness people in parallel in order to keep productive. In fact, mycompany expects partcipation in multiple projects at the same time.
Kent... It depends on the environment. Reality dictates that you figure outwhat works within the constraints you are working in. Working on multipleprojects at the same time is not ideal, but I know it happens quite often.
-----------------------------------------------------------
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifactsshould ensure that what is delivered is of value, and no more; I don't havetime to produce content that is not used. ...and any good methodology andartifact set will evolve over time to capture what is required, and dropwhat is no longer required.
Kent...A good methodology is only part of the story. The real key is how do peopleimplement that methodology. Take the RUP for example. Rational decidedthat they were going to make the UP into a product, and wanted to make surethat they provided artifacts to cover as many different types of projects aspossible. The trouble is, more than a few people ignore the advice to craftthe methodology to fit the needs of that particular project and end up doingmore than they need because the methodology "requires" it. More often thennot, the "and drop what is no longer required" does not occur in practice.The ability to do that, to me, is a sign of a mature developmentorganization.
----------------------------------------------------------->
Kent... I actually think analyzing the business is doing more than creating the >requirements, it should also be about collaborating with the customers >to help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for thebusiness; if you have already started developing software, you have probablyselected the technical architecture and operating environment. How do youknow if you shouldn't have gone in a very different direction? Where do youmake the choice to re-use an existing system, or buy instead of build?
Kent...I'm not sure that I was implying that you started developing software. WhenI said "help them arrive at the best solution to their business problem." Iwas thinking things such as understanding what the problem really is andlooking at all possible approaches, which may not include a technologysolution. I should have also made a comment about helping the customerdetermine if they really have a problem, or if they are focusing on thewrong problem.
------------------------------------------------------------
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of aproject between delivering the best solution and delivering it on time isbest resolved as an external discussion between 2 people, rather than aninternal dilemna for one person... at least that's what works for me.
Kent... 2 Heads is always better than one. I just happen to be a believer that ifthose 2 heads are experienced in a variety of skill sets (with obviousspecialties in one or two fields) the result will be better becausecollaboration is more likely to happen vs when people only specialize andfeel the need to do extensive "Hand offs" between functions. Of course youcannot always get people that are able to and enjoy doing a variety ofdifferent tasks, but it is always something for which to strive.
--------------------------------------------------------------
DAVEWYes, methodologies and documented processes for any activity that producesdifferent deliverables each time (like Information Systems) should not betreated as written in stone. Certification is a long-standing approach tocreating and perpetuating a profession; in fact, there is an ISO standardfor doing it. Managers and HR directors for years have been telling me howimportant it is to 'act professional' and all, I think I would like toactually be recognized as one.
Kent... I don't think you have to be certified to "act professionally", and Isuspect that there are some people with certifications that do not always"act professionally." Certifications have their place, but they have theirflaws as well. My advice to Managers and HR would be to "use with caution."
Kent J. McDonaldkent@kentmcdonald.com
http://www.kentmcdonald.com
Words to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value
Kent J. McDonald
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 7:33 PM
To :
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry to hear you were under the weather. That seems to be going aroundhere as well. I've moved up the sections I am replying to and cutting therest out. Hope that's ok (want to keep the message from getting too long).
DAVEW....1) How much time (hours per day) do Agile developers need to be withcustomers/users? Finding available time on key people's schedules is aconstant challenge for me; I basically have to prepare ahead for a veryfocused 60 to 90 minutes that I might get a day (or every 2 days) to gatherrequirements. I often end up addressing multiple projects with differentbusiness people in parallel in order to keep productive. In fact, mycompany expects partcipation in multiple projects at the same time.
Kent... It depends on the environment. Reality dictates that you figure outwhat works within the constraints you are working in. Working on multipleprojects at the same time is not ideal, but I know it happens quite often.
-----------------------------------------------------------
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifactsshould ensure that what is delivered is of value, and no more; I don't havetime to produce content that is not used. ...and any good methodology andartifact set will evolve over time to capture what is required, and dropwhat is no longer required.
Kent...A good methodology is only part of the story. The real key is how do peopleimplement that methodology. Take the RUP for example. Rational decidedthat they were going to make the UP into a product, and wanted to make surethat they provided artifacts to cover as many different types of projects aspossible. The trouble is, more than a few people ignore the advice to craftthe methodology to fit the needs of that particular project and end up doingmore than they need because the methodology "requires" it. More often thennot, the "and drop what is no longer required" does not occur in practice.The ability to do that, to me, is a sign of a mature developmentorganization.
----------------------------------------------------------->
Kent... I actually think analyzing the business is doing more than creating the >requirements, it should also be about collaborating with the customers >to help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for thebusiness; if you have already started developing software, you have probablyselected the technical architecture and operating environment. How do youknow if you shouldn't have gone in a very different direction? Where do youmake the choice to re-use an existing system, or buy instead of build?
Kent...I'm not sure that I was implying that you started developing software. WhenI said "help them arrive at the best solution to their business problem." Iwas thinking things such as understanding what the problem really is andlooking at all possible approaches, which may not include a technologysolution. I should have also made a comment about helping the customerdetermine if they really have a problem, or if they are focusing on thewrong problem.
------------------------------------------------------------
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of aproject between delivering the best solution and delivering it on time isbest resolved as an external discussion between 2 people, rather than aninternal dilemna for one person... at least that's what works for me.
Kent... 2 Heads is always better than one. I just happen to be a believer that ifthose 2 heads are experienced in a variety of skill sets (with obviousspecialties in one or two fields) the result will be better becausecollaboration is more likely to happen vs when people only specialize andfeel the need to do extensive "Hand offs" between functions. Of course youcannot always get people that are able to and enjoy doing a variety ofdifferent tasks, but it is always something for which to strive.
--------------------------------------------------------------
DAVEWYes, methodologies and documented processes for any activity that producesdifferent deliverables each time (like Information Systems) should not betreated as written in stone. Certification is a long-standing approach tocreating and perpetuating a profession; in fact, there is an ISO standardfor doing it. Managers and HR directors for years have been telling me howimportant it is to 'act professional' and all, I think I would like toactually be recognized as one.
Kent... I don't think you have to be certified to "act professionally", and Isuspect that there are some people with certifications that do not always"act professionally." Certifications have their place, but they have theirflaws as well. My advice to Managers and HR would be to "use with caution."
Kent J. McDonaldkent@kentmcdonald.com
http://www.kentmcdonald.com
Words to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value
Wednesday, March 29, 2006
Discussion on Agile, and Methodologies in General, Part 2
From :
David Wright
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 6:52 PM
To :
agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry, been under the weather for a few days... so let me review and return the favour! DaveW>>
>The key to your statement above is *formal*. Agile methods recognize the>importance of requirements just as much as other methodologies, they just>have the philosphy that given a choice between recording the key points and>then having the ability to collaborate directly with the customer/user when>software development is underway vs documenting everything and throwing the>document over the wall to the developers, they would choose the former. We>all know that real life fits somewhere in the middle. A common agile>requirement mechanism is the user story, which typically consists of a>statement in the form AS A I Want so that>. Where the details are expressed as acceptance tests>so that the requirement artifact can provide multiple uses. Agile>approaches also discourage requirements inventory where all of the>requirements for a project are fully elaborated at the beginning of the>project. Rather they suggest that the requirements are listed at a very>high level at the beginning of the project for scoping purposes, then they>are elaborated upon during the iteration in which that particular chunk of>functionality is built.>
DAVEW....1) How much time (hours per day) do Agile developers need to be with customers/users? Finding available time on key people's schedules is a constant challenge for me; I basically have to prepare ahead for a very focused 60 to 90 minutes that I might get a day (or every 2 days) to gather requirements. I often end up addressing multiple projects with different business people in parallel in order to keep productive. In fact, my company expects partcipation in multiple projects at the same time.2) High-level Requirements are common when scoping a project, either as "I need..." or "The solution must..." statements. I am currently working on a project where high-level requirements were used to define 4 separate phases. Benefits and costs estimated for each phase were used to prioritize the work, and I am now working with the business on detailed requirements for the first phase. I will be feeding those requirements to the assigned designer as they stabilize, who will start development of the first phase while I proceed to detailing the requirements for the second phase, and so on.WIll the results be 'formal'? I suppose, since they will be documented, communicated and approved, and form a baseline for development that virtually eliminates mis-understandings..
>>>>>>>I think if you look at software development overall (including the >Analysis,>development, testing, etc.) from a value perspective, you may find yourself>asking how rigorous should your requirements activities be in order to>provide the information that developers need without performing non value>added work. Where that line falls varies between teams and projects.>
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifacts should ensure that what is delivered is of value, and no more; I don't have time to produce content that is not used. ...and any good methodology and artifact set will evolve over time to capture what is required, and drop what is no longer required.......
"Business Analyst". It is not bad title, and it is one I>have had off and on since 1984, and it does describe what we do --- analyze>the business --- but not what we create: the Requirements.>>>I actually think analyzing the business is doing more than creating the>requirements, it should also be about collaborating with the customers to>help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for the business; if you have already started developing software, you have probably selected the technical architecture and operating environment. How do you know if you shouldn't have gone in a very different direction? Where do you make the choice to re-use an existing system, or buy instead of build?
>>.....I think this is part of the reason that, when some companies hire a Business>Analyst, they believe they are also getting a Project Manager and Software>Tester (the latter better known as Quality Assurance Analysts). I have also>met Business Analysts who would agree with this. I would certainly agree>that having multiple skills will make you more marketable, but it should be>clear that these are three separate skill-sets that are not always>compatible.>
>I would be one of those BA's that agree with that statement.>
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of a project between delivering the best solution and delivering it on time is best resolved as an external discussion between 2 people, rather than an internal dilemna for one person... at least that's what works for me.>>
<snip>>>....................................................If you consider yourself a Business>Analyst, it is imperative you seek out the IIBA, and highly recommended >that>you join.>>
>The good thing about the IIBA is that it is provide a source for BA's to go>for information about Business Analysis and providing a network for people>to expand their knowledge about the subject.>>I would caution about putting too much stock in certifications and BOK's.>Certifications indicate someone's ability to learn one set of knowledge>about a given area and take a test on it, they do not provide a reliable>measure of that person's ability in the subject area that they are being>certified on. BOK's are great because they provide a compiled set of some>knowledge about an area. They become dangerous when people start to>interpret that set of knowledge as *the only correct* thinking for a given>field, and people forget that items in the BOK do not work equally well in>all situations.>>I would agree that you should join the IIBA if you consider yourself a BA >(I>myself am a member). Just remember what a certification is really telling>you, and remember that just because some practices do not find their way>into the BOK does not mean that they are not correct or useful in certain>situations.> >
DAVEWYes, methodologies and documented processes for any activity that produces different deliverables each time (like Information Systems) should not be treated as written in stone. Certification is a long-standing approach to creating and perpetuating a profession; in fact, there is an ISO standard for doing it. Managers and HR directors for years have been telling me how important it is to 'act professional' and all, I think I would like to actually be recognized as one.>
Dave Wright
David Wright
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 6:52 PM
To :
agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
Sorry, been under the weather for a few days... so let me review and return the favour! DaveW>>
DAVEW....1) How much time (hours per day) do Agile developers need to be with customers/users? Finding available time on key people's schedules is a constant challenge for me; I basically have to prepare ahead for a very focused 60 to 90 minutes that I might get a day (or every 2 days) to gather requirements. I often end up addressing multiple projects with different business people in parallel in order to keep productive. In fact, my company expects partcipation in multiple projects at the same time.2) High-level Requirements are common when scoping a project, either as "I need..." or "The solution must..." statements. I am currently working on a project where high-level requirements were used to define 4 separate phases. Benefits and costs estimated for each phase were used to prioritize the work, and I am now working with the business on detailed requirements for the first phase. I will be feeding those requirements to the assigned designer as they stabilize, who will start development of the first phase while I proceed to detailing the requirements for the second phase, and so on.WIll the results be 'formal'? I suppose, since they will be documented, communicated and approved, and form a baseline for development that virtually eliminates mis-understandings..
>>
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifacts should ensure that what is delivered is of value, and no more; I don't have time to produce content that is not used. ...and any good methodology and artifact set will evolve over time to capture what is required, and drop what is no longer required.......
"Business Analyst". It is not bad title, and it is one I>have had off and on since 1984, and it does describe what we do --- analyze>the business --- but not what we create: the Requirements.>>
DAVEWRequirements definition is crucial to selecting the best solution for the business; if you have already started developing software, you have probably selected the technical architecture and operating environment. How do you know if you shouldn't have gone in a very different direction? Where do you make the choice to re-use an existing system, or buy instead of build?
>>.....I think this is part of the reason that, when some companies hire a Business>Analyst, they believe they are also getting a Project Manager and Software>Tester (the latter better known as Quality Assurance Analysts). I have also>met Business Analysts who would agree with this. I would certainly agree>that having multiple skills will make you more marketable, but it should be>clear that these are three separate skill-sets that are not always>compatible.>
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of a project between delivering the best solution and delivering it on time is best resolved as an external discussion between 2 people, rather than an internal dilemna for one person... at least that's what works for me.>>
<snip>>>....................................................If you consider yourself a Business>Analyst, it is imperative you seek out the IIBA, and highly recommended >that>you join.>>
DAVEWYes, methodologies and documented processes for any activity that produces different deliverables each time (like Information Systems) should not be treated as written in stone. Certification is a long-standing approach to creating and perpetuating a profession; in fact, there is an ISO standard for doing it. Managers and HR directors for years have been telling me how important it is to 'act professional' and all, I think I would like to actually be recognized as one.>
Dave Wright
Discussion on Agile, and Methodologies in General
I recently sent the following email to a Yahoo group I belong to on Agile Analysis...
It has been quiet at this group for some months now... anyone out there doing what they consider to be agile analysis on current/recent projects?I'll be honest, I am still skeptical on this topic... see http://businessanalysis56.blogspot.com/2006/01/information-system-requirements-still.html ...but I am still open to being persuaded.Dave W
..and ended up starting a conversation on the topic that started with the following reply from Kent Mcdonald:
David,I would say yes there are people doing what they consider to be agileanalysis on current/recent projects, they just don't happen to be posting tothis list. The most active discussion surrounding agile analysis typeactivities appear on the Agile Modeling list.(http://groups.yahoo.com/group/agilemodeling/) This list is moderated byScott Ambler who has done a lot of writing on Analysis related activities. Isuggest you read his writtings and join the mailing list. Based on readingyour blog post, I think you may find some of it interesting.
As a matter of fact, when I first started this list, I got a bit of pushbackasking if a list focusing on Agile Analysis was really necessary and whether it continued the fractionalization of the software development community.You can look back in the archives and follow the discussion. My thought basically was that we would "let the market decide" and based on your observation about traffic, they may have been right. None the less, I believe there still is value in talking about doing analysis in an agile manner. This has different meanings for different projects in different environments. In those environments that support full blown agile, that means developers working with customers directly. In environments thataren't quite ready for agile, that means that analysts collaborating with both developers and customers to make sure they are working with the customers to understand their needs and with the developers to understand what information they need to properly develop what the customer needs.
David, I read the blog entry that you referenced and had some thoughts. Ihope you don't mind that I replied to parts of it in this message.-----------------------------------------------------------------------------------------------------------------------If you are familiar with newer Agile or Extreme methods for developingsoftware, you will know that they disdain formal requirements, preferring towork directly with end-users to deliver software in small increments. Ibelieve that these methods are a natural reaction to software developers'long-standing frustrations with receiving poor, incorrect or no Requirementsto work with. Developers should be focused on creating software, and timethey spend trying to find out what they should develop, or developing thewrong software, is a waste of their valuable time.
The key to your statement above is *formal*. Agile methods recognize theimportance of requirements just as much as other methodologies, they justhave the philosphy that given a choice between recording the key points andthen having the ability to collaborate directly with the customer/user whensoftware development is underway vs documenting everything and throwing thedocument over the wall to the developers, they would choose the former. Weall know that real life fits somewhere in the middle. A common agilerequirement mechanism is the user story, which typically consists of astatement in the form AS A I Want so that. Where the details are expressed as acceptance testsso that the requirement artifact can provide multiple uses. Agileapproaches also discourage requirements inventory where all of therequirements for a project are fully elaborated at the beginning of theproject. Rather they suggest that the requirements are listed at a veryhigh level at the beginning of the project for scoping purposes, then theyare elaborated upon during the iteration in which that particular chunk offunctionality is built.
Why do Developers get poor Requirements? There is often no common disciplineor accepted practices being used when creating Requirements in a softwaredevelopment project; but, if Developers do get good Requirements, theresulting software is better is almost every way, primarily that it willmeet the needs of the business that requested and paid for it.
Agree here.
As a discipline, Project Management faced similar problems in the past, buttoday its practitioners all recognize common approaches and techniques: WorkBreakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, andmore. They also have seen their work coalescing as a profession through thePMI and its PMP certification. Project Managers also started with theadvantage that their job title actually describes what they do - ProjectManagers manage projects. Software Developers have the same advantages,although the wide variety of languages and environments mean no singlecertification can be had.
There are positives and negatives to being considered a "profession" and tocertification. More comments on that later.
So, I think Model Driven Architecture will play an increasing role overtime; in the mean-time, if it shows that methods for producing requirementscan be rigorous enough (good enough) to generate code, then why not use suchmethods to document Requirements for developers to use for the rest ofsoftware development
I think if you look at software development overall (including the Analysis,development, testing, etc.) from a value perspective, you may find yourselfasking how rigorous should your requirements activities be in order toprovide the information that developers need without performing non valueadded work. Where that line falls varies between teams and projects.
An ancient Chinese saying tells us that 'All wisdom begins with callingthings by their right names.' So, the job of gathering and documentingRequirements needs a Name. I am being somewhat disingenuous here, as thereis well-known job name already, but it is not always used the same way; I amtalking about the "Business Analyst". It is not bad title, and it is one Ihave had off and on since 1984, and it does describe what we do --- analyzethe business --- but not what we create: the Requirements.
I actually think analyzing the business is doing more than creating therequirements, it should also be about collaborating with the customers tohelp them arrive at the best solution to their business problem.
I think this is part of the reason that, when some companies hire a BusinessAnalyst, they believe they are also getting a Project Manager and SoftwareTester (the latter better known as Quality Assurance Analysts). I have alsomet Business Analysts who would agree with this. I would certainly agreethat having multiple skills will make you more marketable, but it should beclear that these are three separate skill-sets that are not alwayscompatible.
I would be one of those BA's that agree with that statement.
The last question about the Business Analyst job is the importance ofspecific business knowledge and experience, aside from analytical andrequirements-related skills. Again, companies will ask for Business Analysiswith experience in Supply Chain Logistics or Life Insurance or ExpressDelivery or Human Resources or Commercial Credit or Finance/Accounting.Well, I have worked in all of these business 'domains' and more withoutneeding to change how I do my job. In the end, the business people beingserved by Information Systems - executives/sponsors, managers, end-users ---are the ones who need to know their business; what I need to do is be ableto quickly understand their business in order to gather and document theirInformation Systems Requirements.
Agree completely. It has also been my experience that someone who does notnecessarily have a long history in a particular industry, but is able toquickly pick it up, is often not influenced by filters, and would be morelikely to ask those probing questions that could lead to groundbreakingchanges in how the business works based on borrowing ideas from otherindustries.
Finally, you may ask how technical a Business Analyst needs to be. My basicrecommendation is you need to understand what technology can do in order todeliver the solutions that meet the Requirements, but you don't need to knowhow the technology will do it. I started as a PL1 and IMS programmer beforemoving to Business Analysis; since then, I have done Requirements forsystems implemented on mainframes, minis and PCs, using environments fromTSO to OS2 to Windows to Browsers; again, the technology to be used to didnot really change how I did my job; in fact, the best Requirements are thosethat can be implemented in multiple technical environments.
Knowing the technology certainly does not hurt. And sometimes it's nice toknow when a technologist is giving you bad information, especially whenworking with the developers to realize the requirements.
And about certification for Business Analysts, we can now look to theInternational Institute of Business Analysis, at www.iiba.com . It is beingcreated and developed following the appropriate ISO standard forprofessional certification organizations and, much like the PMI, isdeveloping a Body of Knowledge for Business Analysis andcertification/testing based on that BOK. If you consider yourself a BusinessAnalyst, it is imperative you seek out the IIBA, and highly recommended thatyou join.
The good thing about the IIBA is that it is provide a source for BA's to gofor information about Business Analysis and providing a network for peopleto expand their knowledge about the subject.I would caution about putting too much stock in certifications and BOK's.Certifications indicate someone's ability to learn one set of knowledgeabout a given area and take a test on it, they do not provide a reliablemeasure of that person's ability in the subject area that they are beingcertified on. BOK's are great because they provide a compiled set of someknowledge about an area. They become dangerous when people start tointerpret that set of knowledge as *the only correct* thinking for a givenfield, and people forget that items in the BOK do not work equally well inall situations.I would agree that you should join the IIBA if you consider yourself a BA (Imyself am a member). Just remember what a certification is really tellingyou, and remember that just because some practices do not find their wayinto the BOK does not mean that they are not correct or useful in certainsituations.
Looking forward to anyone's thoughts.Kent J. McDonaldkent@kentmcdonald.comhttp://www.kentmcdonald.comWords to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value-----Original Message-----
It has been quiet at this group for some months now... anyone out there doing what they consider to be agile analysis on current/recent projects?I'll be honest, I am still skeptical on this topic... see http://businessanalysis56.blogspot.com/2006/01/information-system-requirements-still.html ...but I am still open to being persuaded.Dave W
..and ended up starting a conversation on the topic that started with the following reply from Kent Mcdonald:
David,I would say yes there are people doing what they consider to be agileanalysis on current/recent projects, they just don't happen to be posting tothis list. The most active discussion surrounding agile analysis typeactivities appear on the Agile Modeling list.(http://groups.yahoo.com/group/agilemodeling/) This list is moderated byScott Ambler who has done a lot of writing on Analysis related activities. Isuggest you read his writtings and join the mailing list. Based on readingyour blog post, I think you may find some of it interesting.
As a matter of fact, when I first started this list, I got a bit of pushbackasking if a list focusing on Agile Analysis was really necessary and whether it continued the fractionalization of the software development community.You can look back in the archives and follow the discussion. My thought basically was that we would "let the market decide" and based on your observation about traffic, they may have been right. None the less, I believe there still is value in talking about doing analysis in an agile manner. This has different meanings for different projects in different environments. In those environments that support full blown agile, that means developers working with customers directly. In environments thataren't quite ready for agile, that means that analysts collaborating with both developers and customers to make sure they are working with the customers to understand their needs and with the developers to understand what information they need to properly develop what the customer needs.
David, I read the blog entry that you referenced and had some thoughts. Ihope you don't mind that I replied to parts of it in this message.-----------------------------------------------------------------------------------------------------------------------If you are familiar with newer Agile or Extreme methods for developingsoftware, you will know that they disdain formal requirements, preferring towork directly with end-users to deliver software in small increments. Ibelieve that these methods are a natural reaction to software developers'long-standing frustrations with receiving poor, incorrect or no Requirementsto work with. Developers should be focused on creating software, and timethey spend trying to find out what they should develop, or developing thewrong software, is a waste of their valuable time.
Why do Developers get poor Requirements? There is often no common disciplineor accepted practices being used when creating Requirements in a softwaredevelopment project; but, if Developers do get good Requirements, theresulting software is better is almost every way, primarily that it willmeet the needs of the business that requested and paid for it.
As a discipline, Project Management faced similar problems in the past, buttoday its practitioners all recognize common approaches and techniques: WorkBreakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, andmore. They also have seen their work coalescing as a profession through thePMI and its PMP certification. Project Managers also started with theadvantage that their job title actually describes what they do - ProjectManagers manage projects. Software Developers have the same advantages,although the wide variety of languages and environments mean no singlecertification can be had.
I think if you look at software development overall (including the Analysis,development, testing, etc.) from a value perspective, you may find yourselfasking how rigorous should your requirements activities be in order toprovide the information that developers need without performing non valueadded work. Where that line falls varies between teams and projects.
An ancient Chinese saying tells us that 'All wisdom begins with callingthings by their right names.' So, the job of gathering and documentingRequirements needs a Name. I am being somewhat disingenuous here, as thereis well-known job name already, but it is not always used the same way; I amtalking about the "Business Analyst". It is not bad title, and it is one Ihave had off and on since 1984, and it does describe what we do --- analyzethe business --- but not what we create: the Requirements.
I think this is part of the reason that, when some companies hire a BusinessAnalyst, they believe they are also getting a Project Manager and SoftwareTester (the latter better known as Quality Assurance Analysts). I have alsomet Business Analysts who would agree with this. I would certainly agreethat having multiple skills will make you more marketable, but it should beclear that these are three separate skill-sets that are not alwayscompatible.
Finally, you may ask how technical a Business Analyst needs to be. My basicrecommendation is you need to understand what technology can do in order todeliver the solutions that meet the Requirements, but you don't need to knowhow the technology will do it. I started as a PL1 and IMS programmer beforemoving to Business Analysis; since then, I have done Requirements forsystems implemented on mainframes, minis and PCs, using environments fromTSO to OS2 to Windows to Browsers; again, the technology to be used to didnot really change how I did my job; in fact, the best Requirements are thosethat can be implemented in multiple technical environments.
And about certification for Business Analysts, we can now look to theInternational Institute of Business Analysis, at www.iiba.com . It is beingcreated and developed following the appropriate ISO standard forprofessional certification organizations and, much like the PMI, isdeveloping a Body of Knowledge for Business Analysis andcertification/testing based on that BOK. If you consider yourself a BusinessAnalyst, it is imperative you seek out the IIBA, and highly recommended thatyou join.
Looking forward to anyone's thoughts.Kent J. McDonaldkent@kentmcdonald.comhttp://www.kentmcdonald.comWords to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value-----Original Message-----
Thursday, March 02, 2006
Come and see my presentation at Business Analyst World, Toronto, May 2006
I am happy to announce that I am scheduled to make a presentation at this year's Business Analyst World in Toronto, on May 11. My subject is Integrating Business Analysis Artifacts (including Business Rules).
The details are available at:
http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646
I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld.
See http://www.projectworldcanada.com/ for details.
So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.
The details are available at:
http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646
I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld.
See http://www.projectworldcanada.com/ for details.
So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.
Thursday, February 23, 2006
A little off topic: linkedin.com
If you are in IT/IS or are a general web enthusiast, you are probably familiar with the Networking sites out there that seem to be a business version of "Six Degrees of Separation". I personally belong to linkedin.com after being invited to join by a valued former co-worker. I now have 10 direct connections, and it can be interesting to follow through and see who is in your network when you go two or more connections into it. I haven't found the site terribly useful in any practical way yet, but the potential is there, I think.
In any case, linkedin now offers to put your 'profile' on the web with your own URL, so I have done so at https://www.linkedin.com/in/dwwright99 . You can choose how much information you want to publish and how much you want to keep private.
Anyway, now I want to see how long before I turn up on a search at zoominfo.com .
In any case, linkedin now offers to put your 'profile' on the web with your own URL, so I have done so at https://www.linkedin.com/in/dwwright99 . You can choose how much information you want to publish and how much you want to keep private.
Anyway, now I want to see how long before I turn up on a search at zoominfo.com .
Wednesday, January 25, 2006
Information System Requirements still matter...
If you are familiar with newer Agile or Extreme methods for developing software, you will know that they disdain formal requirements, preferring to work directly with end-users to deliver software in small increments. I believe that these methods are a natural reaction to software developers’ long-standing frustrations with receiving poor, incorrect or no Requirements to work with. Developers should be focused on creating software, and time they spend trying to find out what they should develop, or developing the wrong software, is a waste of their valuable time.
Why do Developers get poor Requirements? There is often no common discipline or accepted practices being used when creating Requirements in a software development project; but, if Developers do get good Requirements, the resulting software is better is almost every way, primarily that it will meet the needs of the business that requested and paid for it.
As a discipline, Project Management faced similar problems in the past, but today its practitioners all recognize common approaches and techniques: Work Breakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, and more. They also have seen their work coalescing as a profession through the PMI and its PMP certification. Project Managers also started with the advantage that their job title actually describes what they do – Project Managers manage projects. Software Developers have the same advantages, although the wide variety of languages and environments mean no single certification can be had.
There is no similar structured discipline or professional recognition around Requirements today; but I submit that it will exist in the future, for two main reasons:
…1) the need has been recognized by a growing number of Requirements ‘practitioners’, who have founded an association similar in mandate and purpose to that of the PMI for PM… more on that later.
… 2) It has been demonstrated in the past the Requirements can be documented using modeling methods with enough rigor that software can be automatically generated from the Requirements. Yes, the main CASE tools of 10 to 15 years ago failed to catch on, but not because they did not work. I see this level of rigor and code generation surfacing again with Model-Driven Architecture.
Granted, I am in no position to say that model-based Requirements and code generation are going to reduce or eliminate creation of software by programmers. I could however draw on the common justification for any automation that is used so often; that it won’t eliminate people’s work or jobs, but free them up to work on more challenging tasks .
So, I think Model Driven Architecture will play an increasing role over time; in the mean-time, if it shows that methods for producing requirements can be rigorous enough (good enough) to generate code, then why not use such methods to document Requirements for developers to use for the rest of software development?
But where to begin?
An ancient Chinese saying tells us that ‘All wisdom begins with calling things by their right names.’ So, the job of gathering and documenting Requirements needs a Name… I am being somewhat disingenuous here, as there is well-known job name already, but it is not always used the same way; I am talking about the “Business Analyst”. It is not bad title, and it is one I have had off and on since 1984, and it does describe what we do --- analyze the business --- but not what we create: the Requirements.
I think this is part of the reason that, when some companies hire a Business Analyst, they believe they are also getting a Project Manager and Software Tester (the latter better known as Quality Assurance Analysts). I have also met Business Analysts who would agree with this. I would certainly agree that having multiple skills will make you more marketable, but it should be clear that these are three separate skill-sets that are not always compatible.
I myself have and will manage small to middle-sized projects, but primarily when I have first completed the Requirements myself; if you need more than one Business Analyst to get the Requirements delivered, you need a separate Project Manager. I do recognize that many Business Analysts have worked hard to acquire Project Management skills and experience to then become a certified PMP, but it is often because there has been no equivalent certification for Business Analysts; again, more on that later.
I have also had a successful career as Business Analyst without testing software; I see that as a very specific discipline for which I have great respect, but no inclination to perform. It’s possible or probable that I have no talent for it either.
Another issue I have with the misuse of the Business Analyst title are those companies who advertise for a ‘Business Analyst’ with specific software product experience, such as Oracle Financials or SAP (even a specific SAP module). I think what these companies are looking for are ‘Application Analysts’. This again is a separate skill-set, and a popular one, but these analysts still need to have the Requirements of the business provided to them, and I believe ‘real’ Business Analysts are probably doing that first.
The last question about the Business Analyst job is the importance of specific business knowledge and experience, aside from analytical and requirements-related skills. Again, companies will ask for Business Analysis with experience in Supply Chain Logistics or Life Insurance or Express Delivery or Human Resources or Commercial Credit or Finance/Accounting. Well, I have worked in all of these business ‘domains’ and more without needing to change how I do my job. In the end, the business people being served by Information Systems – executives/sponsors, managers, end-users --- are the ones who need to know their business; what I need to do is be able to quickly understand their business in order to gather and document their Information Systems Requirements.
Finally, you may ask how technical a Business Analyst needs to be. My basic recommendation is you need to understand what technology can do in order to deliver the solutions that meet the Requirements, but you don’t need to know how the technology will do it. I started as a PL1 and IMS programmer before moving to Business Analysis; since then, I have done Requirements for systems implemented on mainframes, minis and PCs, using environments from TSO to OS2 to Windows to Browsers; again, the technology to be used to did not really change how I did my job; in fact, the best Requirements are those that can be implemented in multiple technical environments.
And about certification for Business Analysts, we can now look to the International Institute of Business Analysis, at www.iiba.com . It is being created and developed following the appropriate ISO standard for professional certification organizations and, much like the PMI, is developing a Body of Knowledge for Business Analysis and certification/testing based on that BOK. If you consider yourself a Business Analyst, it is imperative you seek out the IIBA, and highly recommended that you join.
So, Business Analysts deliver Information Systems Requirements; if you navigate back through this blog, you will see how it is done. (It is the accepted Blog format for entries to be LIFO, so I would recommendyou can make your way back to my first entry http://businessanalysis56.blogspot.com/2005/07/welcome-to-business-analysis.html and then work your way forward. I have recently learned about a website/service called squarepusher.com that may be useful in turning these blog entries into a standard website, so I will keep you all informed on my progress there...)
Why do Developers get poor Requirements? There is often no common discipline or accepted practices being used when creating Requirements in a software development project; but, if Developers do get good Requirements, the resulting software is better is almost every way, primarily that it will meet the needs of the business that requested and paid for it.
As a discipline, Project Management faced similar problems in the past, but today its practitioners all recognize common approaches and techniques: Work Breakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, and more. They also have seen their work coalescing as a profession through the PMI and its PMP certification. Project Managers also started with the advantage that their job title actually describes what they do – Project Managers manage projects. Software Developers have the same advantages, although the wide variety of languages and environments mean no single certification can be had.
There is no similar structured discipline or professional recognition around Requirements today; but I submit that it will exist in the future, for two main reasons:
…1) the need has been recognized by a growing number of Requirements ‘practitioners’, who have founded an association similar in mandate and purpose to that of the PMI for PM… more on that later.
… 2) It has been demonstrated in the past the Requirements can be documented using modeling methods with enough rigor that software can be automatically generated from the Requirements. Yes, the main CASE tools of 10 to 15 years ago failed to catch on, but not because they did not work. I see this level of rigor and code generation surfacing again with Model-Driven Architecture.
Granted, I am in no position to say that model-based Requirements and code generation are going to reduce or eliminate creation of software by programmers. I could however draw on the common justification for any automation that is used so often; that it won’t eliminate people’s work or jobs, but free them up to work on more challenging tasks .
So, I think Model Driven Architecture will play an increasing role over time; in the mean-time, if it shows that methods for producing requirements can be rigorous enough (good enough) to generate code, then why not use such methods to document Requirements for developers to use for the rest of software development?
But where to begin?
An ancient Chinese saying tells us that ‘All wisdom begins with calling things by their right names.’ So, the job of gathering and documenting Requirements needs a Name… I am being somewhat disingenuous here, as there is well-known job name already, but it is not always used the same way; I am talking about the “Business Analyst”. It is not bad title, and it is one I have had off and on since 1984, and it does describe what we do --- analyze the business --- but not what we create: the Requirements.
I think this is part of the reason that, when some companies hire a Business Analyst, they believe they are also getting a Project Manager and Software Tester (the latter better known as Quality Assurance Analysts). I have also met Business Analysts who would agree with this. I would certainly agree that having multiple skills will make you more marketable, but it should be clear that these are three separate skill-sets that are not always compatible.
I myself have and will manage small to middle-sized projects, but primarily when I have first completed the Requirements myself; if you need more than one Business Analyst to get the Requirements delivered, you need a separate Project Manager. I do recognize that many Business Analysts have worked hard to acquire Project Management skills and experience to then become a certified PMP, but it is often because there has been no equivalent certification for Business Analysts; again, more on that later.
I have also had a successful career as Business Analyst without testing software; I see that as a very specific discipline for which I have great respect, but no inclination to perform. It’s possible or probable that I have no talent for it either.
Another issue I have with the misuse of the Business Analyst title are those companies who advertise for a ‘Business Analyst’ with specific software product experience, such as Oracle Financials or SAP (even a specific SAP module). I think what these companies are looking for are ‘Application Analysts’. This again is a separate skill-set, and a popular one, but these analysts still need to have the Requirements of the business provided to them, and I believe ‘real’ Business Analysts are probably doing that first.
The last question about the Business Analyst job is the importance of specific business knowledge and experience, aside from analytical and requirements-related skills. Again, companies will ask for Business Analysis with experience in Supply Chain Logistics or Life Insurance or Express Delivery or Human Resources or Commercial Credit or Finance/Accounting. Well, I have worked in all of these business ‘domains’ and more without needing to change how I do my job. In the end, the business people being served by Information Systems – executives/sponsors, managers, end-users --- are the ones who need to know their business; what I need to do is be able to quickly understand their business in order to gather and document their Information Systems Requirements.
Finally, you may ask how technical a Business Analyst needs to be. My basic recommendation is you need to understand what technology can do in order to deliver the solutions that meet the Requirements, but you don’t need to know how the technology will do it. I started as a PL1 and IMS programmer before moving to Business Analysis; since then, I have done Requirements for systems implemented on mainframes, minis and PCs, using environments from TSO to OS2 to Windows to Browsers; again, the technology to be used to did not really change how I did my job; in fact, the best Requirements are those that can be implemented in multiple technical environments.
And about certification for Business Analysts, we can now look to the International Institute of Business Analysis, at www.iiba.com . It is being created and developed following the appropriate ISO standard for professional certification organizations and, much like the PMI, is developing a Body of Knowledge for Business Analysis and certification/testing based on that BOK. If you consider yourself a Business Analyst, it is imperative you seek out the IIBA, and highly recommended that you join.
So, Business Analysts deliver Information Systems Requirements; if you navigate back through this blog, you will see how it is done. (It is the accepted Blog format for entries to be LIFO, so I would recommendyou can make your way back to my first entry http://businessanalysis56.blogspot.com/2005/07/welcome-to-business-analysis.html and then work your way forward. I have recently learned about a website/service called squarepusher.com that may be useful in turning these blog entries into a standard website, so I will keep you all informed on my progress there...)
Tuesday, January 03, 2006
Thoughts for the New Year
In no particular order:
- I still have a ton of material from the Business Rules Forum, and I still have to figure what I want to say about it here, maybe some attributed highlights from the sessions?
- If you consider yourself a Business Analyst, you need to join the International Institute of Business Analysis, www.iiba.com ...don't wait any longer
- Process Models: how do they get so big? If you have one Role/Swimlane doing many sequential tasks, don't have one process model 'box' for each task, put them all in a single procedure document and refer to it from the Process Model.
- Why do some Business Analysts believe they also have to be Project Managers and Testers as well? I would assume it makes you more marketable, but they are very separate skillsets from Business Analysis... and if a lot of you keep doing it, then companies will still keep asking for them in Business Analyst job descriptions.
- Why don't IT/IS magazines really write about Business Analysis? Are we that un-sexy?
...more later.
Saturday, November 19, 2005
Business Rules Forum
I am back from the Business Rules Forum, last week in Orlando. I have a lot of material to make use of, so I thought I would start with giving an overview of the major points themes of the conference:
- Business Rules has its origins in Expert Systems as well as Data Modeling.
- Business Rules and Business Processes are becoming more integrated than ever. BR approaches can be used to manage the ‘decision diamonds’, and simplify the maps themselves.
- Most common questions: who should document Business Rules? Is it Business Analysts? What is a Business Analyst?... I met a few people who are founding the Jacksonville FL chapter of the IIBA, and mentioned the existence of the IIBA in a few sessions.
- Some participants were evangelists who see Business Rules as the center of business and systems; others see Business Rules as apart but integrated with all the other ‘artifacts’ of business requirements, especially as organized by the Zachman Framework.
- The Zachman Framework was itself a common subject across many presentations, capped by a closing presentation by John Zachman himself. While his framework is methodology and artifact independent, he does however see Business Rules as a valuable addition to the Business Model of Row 2 of the Framework, mainly in the Motivation Column.
To see the overall agenda for the forum, you can visit http://www.businessrulesforum.com/
- Business Rules has its origins in Expert Systems as well as Data Modeling.
- Business Rules and Business Processes are becoming more integrated than ever. BR approaches can be used to manage the ‘decision diamonds’, and simplify the maps themselves.
- Most common questions: who should document Business Rules? Is it Business Analysts? What is a Business Analyst?... I met a few people who are founding the Jacksonville FL chapter of the IIBA, and mentioned the existence of the IIBA in a few sessions.
- Some participants were evangelists who see Business Rules as the center of business and systems; others see Business Rules as apart but integrated with all the other ‘artifacts’ of business requirements, especially as organized by the Zachman Framework.
- The Zachman Framework was itself a common subject across many presentations, capped by a closing presentation by John Zachman himself. While his framework is methodology and artifact independent, he does however see Business Rules as a valuable addition to the Business Model of Row 2 of the Framework, mainly in the Motivation Column.
To see the overall agenda for the forum, you can visit http://www.businessrulesforum.com/
Wednesday, November 16, 2005
Requirements and Architecture
Are my Information System Deliverables equal to artifacts that that can be organized by the Zachman Framework?
Yes and No. For those of you unfamiliar with the Zachman Framework, visit its website… http://www.zachmanframework.com/
Let’s see what columns I have covered with my deliverables:
Data Model is “what”.
Business Process Model is “how”.
Use Cases may also be “how”, and also partially “who”.
Events of the Business Process Model are “when”.
Business Rules are “why”.
That leaves “where”, which may need to be stated explicitly when multiple business locations are involved; this may require a requirements deliverable for an information systems network.
From a Zachman perspective, my deliverables may be seen as weak in the “when” and “who” columns. I am usually comfortable with these areas as they are, as “when” and especially “who” are often found more in systems design then system requirements. Overall, if you have read my earlier posts, you will notice that the words “what” and “how” have a different meaning from Zachman when describing Information System Requirements (what), versus Information Systems Design (how).
You can also see that some of my deliverables would be considered as row 2 artifacts, while others are row 3. If you feel the need to provide artifacts for both rows, so much the better; if not, I think my deliverables, plus a location/network deliverable, will usually suffice for defining a complete set of Information System Requirements.
Now, I do say this in the context of being a Business Analyst responsible for defining Information Systems Requirements, without expecting there to be an overall Architecture in place. If you are lucky enough to be working in an environment that does provide an overall Architecture, I humbly submit my favourite deliverables as candidates for use as architectural artifacts.
Yes and No. For those of you unfamiliar with the Zachman Framework, visit its website… http://www.zachmanframework.com/
Let’s see what columns I have covered with my deliverables:
Data Model is “what”.
Business Process Model is “how”.
Use Cases may also be “how”, and also partially “who”.
Events of the Business Process Model are “when”.
Business Rules are “why”.
That leaves “where”, which may need to be stated explicitly when multiple business locations are involved; this may require a requirements deliverable for an information systems network.
From a Zachman perspective, my deliverables may be seen as weak in the “when” and “who” columns. I am usually comfortable with these areas as they are, as “when” and especially “who” are often found more in systems design then system requirements. Overall, if you have read my earlier posts, you will notice that the words “what” and “how” have a different meaning from Zachman when describing Information System Requirements (what), versus Information Systems Design (how).
You can also see that some of my deliverables would be considered as row 2 artifacts, while others are row 3. If you feel the need to provide artifacts for both rows, so much the better; if not, I think my deliverables, plus a location/network deliverable, will usually suffice for defining a complete set of Information System Requirements.
Now, I do say this in the context of being a Business Analyst responsible for defining Information Systems Requirements, without expecting there to be an overall Architecture in place. If you are lucky enough to be working in an environment that does provide an overall Architecture, I humbly submit my favourite deliverables as candidates for use as architectural artifacts.
Monday, October 31, 2005
Integrating Requirements Deliverables
Some of the requirement Deliverable integration possibilities have been touched on in the previous postings. Listed together, they are:
- Process Maps identify all steps of a process, and a Process Step can indicate when a Use Case is used in the Business.
- Use Cases can include the Declarative Requirements for the Information System/Solution.
- A Data Model will document all data items used within the scope of a set of Use Cases, and is cross-referenced in the Use Case for the data items used by the latter.
- Business Rules can also be documented across the scope of the Business being analyzed, including both the set of Use Case and the overall Process Map, as a Business Rule may be invoked at different points and times with the Business Operations. Use to date has shown they can then best cross-referenced in:
o In the Use Cases whose execution is impacted by one or more Business Rules
o In Process Maps at Decision Points, as Business Rules may play a role in deciding which path within a Map should be followed in any one execution of the Process
I have a diagram showing the relationships, but my blog site does not want to accept an upload of it. I will keep trying, but in the meantime, contact me at dwwright99@hotmail.com and I will send you the diagram (as a bmp file).
- Process Maps identify all steps of a process, and a Process Step can indicate when a Use Case is used in the Business.
- Use Cases can include the Declarative Requirements for the Information System/Solution.
- A Data Model will document all data items used within the scope of a set of Use Cases, and is cross-referenced in the Use Case for the data items used by the latter.
- Business Rules can also be documented across the scope of the Business being analyzed, including both the set of Use Case and the overall Process Map, as a Business Rule may be invoked at different points and times with the Business Operations. Use to date has shown they can then best cross-referenced in:
o In the Use Cases whose execution is impacted by one or more Business Rules
o In Process Maps at Decision Points, as Business Rules may play a role in deciding which path within a Map should be followed in any one execution of the Process
I have a diagram showing the relationships, but my blog site does not want to accept an upload of it. I will keep trying, but in the meantime, contact me at dwwright99@hotmail.com and I will send you the diagram (as a bmp file).
Thursday, October 27, 2005
Business Rules
As a concept, Business Rules are not new, to the Business or IT; what is new is the focus on separating them from other forms of documentation so they can better defined and managed. Business Rules are similar to Process Models/Maps in that they are subject to more frequent change than other aspects of the business, frequently enough that if rules are hard-coded in an Information System, the effort and elapsed time to change the system can be too large to be tolerated by the business over time.
So, just as generic Process ‘systems’ are emerging to support rapid process change, so are Business Rule Systems and Vendors that support Business Rule Management and Change independently of the information systems that uses them.
What is a Business Rule?
A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems) project are atomic – that is, they cannot be broken down further.
“Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group.
I would add the word ‘declarative’ to the definition, as in “a business rule is a declarative statement that defines…” emphasizing that Business Rules do not imply and process, procedure, flow or other ‘system’ structure. If Business Rules are separately defined and managed, they can then be used as needed by any process/procedure/flow that needs a rule’s guidance or constraint.
The paper with the above definition is available at http://www.businessrulesgroup.org/first_paper/br01ad.htm
It includes an example case study of a fictitious car rental company with many defined business rules; here is a sample:
Rental reservation acceptance
- If a rental request does not specify a particular car group or model, the default is group A (the lowest-cost group).
- Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up day.
- If the customer requesting the rental has been blacklisted, the rental must be refused.
- A customer may have multiple future reservations, but may have only one car at any time.
So, please go read that article at the Business Rules Group website (I want to avoid any charges of plagiarism of that site on my site).
To ensure that Business Rules are meaningful and clear, they are always based on a defined set of ‘Terms and Facts’, which are used as the language of the Rules. Terms from the above examples include rental request, car group, reservation, branch, and customer. An example of a fact would be "a customer may have multiple future reservations": it’s when you add the constraint "but may have only one car at any time" that you have a rule, using that fact and the relevant terms.
Defining terms and facts can also be seen as a role of an Entity-Relationship Data Model, such that the Entities/Attributes and Relationships of such a Data Model can readily be used as the Terms and Facts for defining Business Rules. The two types of models are different in some ways, but they are similar enough that if you have both, you can easily use one to drive the creation of the other.
So, now we have covered all the Requirements formats that I commonly use:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules
… and I have already touched on some aspects of how these formats can be inter-related and integrated. I will review all those and add some more aspects in my next post on Integrating Requirements Deliverables.
So, just as generic Process ‘systems’ are emerging to support rapid process change, so are Business Rule Systems and Vendors that support Business Rule Management and Change independently of the information systems that uses them.
What is a Business Rule?
A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. The business rules that concern (an Information Systems) project are atomic – that is, they cannot be broken down further.
“Defining Business Rules ~ What Are They Really?”, Copyright ©2001, the Business Rules Group.
I would add the word ‘declarative’ to the definition, as in “a business rule is a declarative statement that defines…” emphasizing that Business Rules do not imply and process, procedure, flow or other ‘system’ structure. If Business Rules are separately defined and managed, they can then be used as needed by any process/procedure/flow that needs a rule’s guidance or constraint.
The paper with the above definition is available at http://www.businessrulesgroup.org/first_paper/br01ad.htm
It includes an example case study of a fictitious car rental company with many defined business rules; here is a sample:
Rental reservation acceptance
- If a rental request does not specify a particular car group or model, the default is group A (the lowest-cost group).
- Reservations may be accepted only up to the capacity of the pick-up branch on the pick-up day.
- If the customer requesting the rental has been blacklisted, the rental must be refused.
- A customer may have multiple future reservations, but may have only one car at any time.
So, please go read that article at the Business Rules Group website (I want to avoid any charges of plagiarism of that site on my site).
To ensure that Business Rules are meaningful and clear, they are always based on a defined set of ‘Terms and Facts’, which are used as the language of the Rules. Terms from the above examples include rental request, car group, reservation, branch, and customer. An example of a fact would be "a customer may have multiple future reservations": it’s when you add the constraint "but may have only one car at any time" that you have a rule, using that fact and the relevant terms.
Defining terms and facts can also be seen as a role of an Entity-Relationship Data Model, such that the Entities/Attributes and Relationships of such a Data Model can readily be used as the Terms and Facts for defining Business Rules. The two types of models are different in some ways, but they are similar enough that if you have both, you can easily use one to drive the creation of the other.
So, now we have covered all the Requirements formats that I commonly use:
· Declarative Requirement Statements
· Use Cases
· Data Models
· Process Models
· Business Rules
… and I have already touched on some aspects of how these formats can be inter-related and integrated. I will review all those and add some more aspects in my next post on Integrating Requirements Deliverables.
Subscribe to:
Posts (Atom)