Re-introducing Business Analysis into the Agile Stream
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 150 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51425 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Streaming mediaMathematical analysisHypermediaRadical (chemistry)Repeating decimalReliefClient (computing)Process (computing)Pay televisionCapability Maturity ModelSoftwareMathematicsLine (geometry)Basis <Mathematik>Projective planeDivisorPhysical systemSign (mathematics)Term (mathematics)Multiplication signReliefType theoryCovering spaceObservational studyBitQuicksortResultantCapability Maturity ModelMathematical analysisProcess (computing)CodeClient (computing)TelecommunicationComputer reservations systemWordDifferent (Kate Ryan album)Pairwise comparisonWave packetCASE <Informatik>Military baseBenchmarkAnalytic setSelf-organizationPosition operatorPlastikkartePay televisionDialectCartesian coordinate systemData miningRight angleAuthorizationLevel (video gaming)Internet service providerPerspective (visual)Mixture modelComplex analysisSystem callGoodness of fitEmailWritingInheritance (object-oriented programming)Link (knot theory)Software developerReal numberMetropolitan area networkState of matterDataflowInformation technology consultingSpeech synthesisDampingAddressing modeOnline helpNatural numberLatent heatJSONXMLUMLComputer animation
08:42
Process (computing)Capability Maturity ModelSoftwareView (database)Execution unitSoftware developerMoving averageMaxima and minimaTelephone number mappingMenu (computing)Gamma functionVelocityDependent and independent variablesElectronic program guideRevision controlWeb pageMathematical analysisOpen sourceSelf-organizationData structureOperations researchTask (computing)IntranetSelf-organizationObservational studyBitProjective planeData conversionPhysical systemFunktionalanalysisGoodness of fitMatching (graph theory)Decision theoryResultantMultiplication signTerm (mathematics)Process (computing)Mainframe computerQuicksortSoftwareSound effectType theoryData structureComputer fileMoment (mathematics)Computer programmingWritingSoftware developerDifferent (Kate Ryan album)Right angleComputerParameter (computer programming)NumberLetterpress printingExpressionTwitterOffice suiteMathematical analysisOnlinecommunityComputer architectureVelocityArithmetic meanIterationPoint (geometry)WordDampingCapability Maturity ModelVideo gameSoftware testingSuite (music)Integrated development environmentTouchscreenWater vaporShared memoryInternetworkingFilesharing-SystemDivisorView (database)Insertion lossTransformation (genetics)Computer animation
17:20
Revision controlElectronic program guideWeb pageOpen sourceMathematical analysisSelf-organizationOperations researchData structureTask (computing)Function (mathematics)Focus (optics)Software frameworkInformationStrategy gameProcess (computing)Product (business)Decision theorySoftware developerLevel (video gaming)Digital rights managementCausalityTable (information)RootPublic domainProcess (computing)Parameter (computer programming)Phase transitionLattice (order)TelecommunicationComputerDigital rights managementSimulationComputer programmingContext awarenessGame theoryView (database)Projective planeDecision theoryIntegrated development environmentSoftware developerMassMereologyTask (computing)Term (mathematics)Dynamical systemSystems analysisTable (information)Class diagramRelational databaseData conversionFocus (optics)CodeBitWritingProduct (business)Mathematical analysisCASE <Informatik>FlowchartPoint (geometry)Physical systemDiagramPlanningClient (computing)Computer programMultiplication signMobile appArithmetic meanAcoustic shadowLevel (video gaming)Closed setQuicksortSet (mathematics)Slide ruleWebsiteGeometryRule of inferenceSelf-organizationSummierbarkeitStrategy gameFunktionalanalysisSoftware testingAtomic numberWordRight angleComplex analysisReading (process)Cone penetration testFood energySoftwareLogicSign (mathematics)Insertion lossObservational studyGoodness of fitComputer animation
25:58
Machine visionEnterprise architectureMathematicsStatement (computer science)Focus (optics)Strategy gameCASE <Informatik>Physical systemLevel (video gaming)Function (mathematics)Perspective (visual)SoftwareProduct (business)Special unitary groupData structureComputer configurationCondition numberPiPlastikkarteSimilarity (geometry)Decision tree learningSoftware testingDifferent (Kate Ryan album)Video trackingTexture mappingPersonal digital assistantCalculus of variationsOrder (biology)Mechanism designStreaming mediaImplementationPhysical systemMereologyTable (information)Point (geometry)Software testingEnterprise architectureParameter (computer programming)Arithmetic meanPlastikkarteMappingMathematicsGraphical user interfaceProjective planeCASE <Informatik>Order (biology)Fiber bundleTrailProcess (computing)DataflowMeasurementDifferent (Kate Ryan album)Field (computer science)Strategy gameData conversionClient (computing)Multiplication signRight angleView (database)Group actionLevel (video gaming)Task (computing)Computer configurationSet (mathematics)Type theoryConfiguration spaceDivisorDigital rights managementQuicksortFunktionalanalysisBijectionConfiguration managementHelmholtz decompositionMoment (mathematics)IterationSpreadsheetDatabaseStatement (computer science)Basis <Mathematik>Video game consoleDirection (geometry)RootRoutingSoftware developerComputer programInternetworkingSeries (mathematics)INTEGRALData storage deviceSlide ruleMachine visionSpacetimeSoftwareCorrespondence (mathematics)Graph coloringGreatest elementStructural loadComputer animation
34:36
Mechanism designStreaming mediaImplementationMereologyMathematical analysisStatement (computer science)Dependent and independent variablesMachine visionService (economics)Strategy gameDiagramMaxima and minimaProcess (computing)Algebraic closureDependent and independent variablesKey (cryptography)RootProcess (computing)MultilaterationFocus (optics)DiagramTrailAxiom of choice1 (number)Statement (computer science)Goodness of fitClient (computing)Strategy gameCausalityDegree (graph theory)Software developerWordResponse time (technology)Service (economics)Projective planeMachine visionFrequencyReduction of orderDivisorNumberLattice (order)Decision theoryDigital rights managementExecution unitOnline helpSound effectCollaborationismDifferent (Kate Ryan album)QuicksortVideo gameDatabase transactionINTEGRALCASE <Informatik>Mathematical analysisFunktionalanalysisIntegrated development environmentMultiplication signSigma-algebraLevel (video gaming)MeasurementPoint (geometry)Observational studyScheduling (computing)Semantics (computer science)Real-time operating systemRoutingMereologyTerm (mathematics)TheoryProper mapRight angleAlgebraic closureMathematicsCovering spaceSoftware testingPhysical systemCore dumpComputer animation
43:13
Process (computing)Dependent and independent variablesStatement (computer science)Algebraic closureService (economics)DiagramCASE <Informatik>Cone penetration testMoving averagePlot (narrative)Number theorySharewareCircleFigurate numberPhysical systemClient (computing)DiagramWater vaporTheoryType theoryProjective planeDivisorAnalytic setNumberTerm (mathematics)Process (computing)Goodness of fitImplementationGroup actionMoving averageCartesian coordinate systemGame theoryElectronic mailing listMultiplication signDigital rights managementWordAlgebraic closureInteractive televisionBitMathematicsVideoconferencingCASE <Informatik>Integrated development environmentPoint (geometry)Computer reservations systemIdeal (ethics)Statement (computer science)InformationProduct (business)Different (Kate Ryan album)Service (economics)Sinc functionRepetitionBoolean algebraRhombusView (database)Query languageRight angleDecision theoryDenial-of-service attackMereologyLevel (video gaming)GodCountingSoftware developerReal numberHecke operatorRow (database)HypermediaFunktionalanalysisReduction of orderData conversionTheory of relativityLattice (order)WebsiteSoftwareComputer animation
51:51
Process (computing)Physical systemPersonal digital assistantSingle-precision floating-point formatIterationContext awarenessDiagramCASE <Informatik>Dependent and independent variablesQuery languageMatrix (mathematics)Digital rights managementRule of inferenceTable (information)Decision theoryWebDAVTrailInformationPublic domainProduct (business)CASE <Informatik>Formal verificationNumberRepetitionRule of inferenceService (economics)Computer configurationHecke operatorDigital rights managementTask (computing)MereologyDecision theoryLevel (video gaming)Different (Kate Ryan album)BitMultiplication signOrder (biology)Data conversionPhysical systemSoftware developerIncidence algebraSystem callDivisorExecution unitKey (cryptography)Menu (computing)Database transactionStapeldateiWater vaporProcess (computing)CircleFigurate numberDependent and independent variablesMathematical analysisSoftwareDecision tableClass diagramRight angleCodeType theoryInformationPublic domainClient (computing)ResultantPointer (computer programming)Expert systemInformation technology consultingMatrix (mathematics)Element (mathematics)Group actionMathematicsProjective planePoint (geometry)Sign (mathematics)WordProduct (business)Fiber bundleTable (information)LogicExpected value2 (number)View (database)WebsiteComputer programDiagramFrequencySoftware testingSocial classComputer animation
01:00:29
JSONXMLUML
Transcript: English(auto-generated)
00:04
Hi, everybody. Thanks for coming here. How do I sound? I'm not used to talking out of a microphone. I'm Howard Padeswa. I'm a business analyst, which I'm almost afraid to say here in this conference. I hope none of you brought any tomatoes or any eggs. The reason I mention that is I've been sitting around in some of the talks here,
00:24
and very, very code heavy. So I want to warn you, first of all, I'm not going to write a line of code here. It's actually not going to be from that perspective. I come from that world, but many moons ago. I actually haven't written code for quite a few years. What I'm going to talk about is business analysis, and I want to put it one way.
00:41
It's about, let's see, why do businesses hire us? It's to protect businesses from the guys and gals who typically come to this conference. They actually feel a little bit nervous about developers, and sometimes they've been burned by it. I've been on the other side, and I've been the person who sometimes has been burning them, and I've actually crossed lines, I guess, and moved over on the business side.
01:04
So I want to talk to you a little bit about today, what this business analysis role is all about, and why we've actually been asked, my own company often, to go into shops, which are often doing a mixture of agile and non-agile projects,
01:20
and why they feel they need some BAs, BAs is short for business analysts for those of you who haven't initiated, why they need them on the team. So I guess it's a little bit of a sales job. By the way, a little disclosure right away is, yes, I do have a vested interest in this. My whole business is Noble, Inc., and we're about training business analysts and providing BA consultants,
01:40
and obviously without any BAs, we don't have any work. But I want to declare that right away so you know where I'm coming from. I've also written a couple of books. Those are them down there. So I'm going to sort of divide this talk up into two halves, and first I guess talk in general about what the role is all about and how it may or may not fit into an agile project,
02:00
and then actually just walk you through a theoretical project and where a BA would fit in and what kind of work they would do and how they would use the techniques. In other words, I'm going to go broad and then I'm going to go deep. As to why I am here in the first place and why I'm speaking about this, this all came really about from some work that my company did with Statoil
02:21
about two or maybe three years ago, and they actually brought us in to speak about the role of a BA in Agile, so it was an obvious thing to talk about when I got invited to speak here. But it's also because as I was really thinking about what to talk about, this question kept coming up. I know things are a little bit different here. What I understand here is that if you guys want training,
02:42
you just go to the company and your company signs off and says, yes, you can get training. In Canada, where I come from, it doesn't work that way. The VP level of your company has to okay training with X company. So because it works that way, I talk to a lot of VPs just by its very nature. I'm the CEO of my company, so it's sort of a level-to-level thing.
03:03
I'm dealing with large companies usually, so a lot of what I say is not a strong issue for small projects and for smaller companies. But it has become at least where I come from, and I'd be interested to see how this relates over here, with large organizations. And I don't want to say company, necessarily, because a lot of our clients,
03:21
people who ask for business analysis, are government, the federal level, or the provincial, state. I'm not sure what's the level below federal here in Norway. They divided them up into regions. I don't know what you'd call it here, but at every level of government, basically, you've got a very large IT organization.
03:41
If you're a bank, if you're an insurance company, if you're a telephone company, we deal with companies of all those types, you're often in a position where you need some IT help. Either it's software that's going to be written from scratch, in-house, or frequently today, that type of software goes overseas.
04:01
Or you're going to be buying a software solution, and I say you don't really want to get screwed by the vendors. You want to make sure that whatever you've asked them for covers all of the bases. And really the role of a BA, of a business analyst, is to make sure that that happens. That's often why they call us in. Often the company has been screwed before. I hope I can say these words here.
04:21
And this happened recently with a large telecom company that we're working with now, and they just want to make sure that the next time they go out, that's not going to happen to them. So we're working with them on a couple of projects. An example of the type of a project, one is a GIS system that we're working with right now, Geospatial Informational System. It's used by telephone companies.
04:42
Another is behavioral analytics that's being thrown into credit card applications. So that's the one side. The other side of the reason I'm here is because as an author of those books that flew by you before, they're about business analysis, I get a lot of emails from BAs, and they're worried like hell that if this agile thing catches on,
05:02
they're out of a job. And my answer to them, of course, is it's too late. The agile thing has caught on. But maybe, if you're lucky, you won't be out of a job. So these are the problems that bring people to, bring companies to guys like me. They find that, as they put to me, we're at the mercy of the solution providers.
05:22
A real story that I heard at the VP level just recently was we went out to buy a large system. We tried to identify all the gaps between their system and our system, and we thought we did a good job, and we signed off, everything looked good. When we actually got the system,
05:40
there were many gaps that weren't accounted for, and the result was lots of CRs. You have that acronym here? Change requests. And guess who has to pay for those change requests? It's the company that just took on the vendor. How do they feel that we might be able to help them? They felt that if we could actually write our requirements, the things that we needed,
06:00
in a way that was solution neutral, solution agnostic, then we could present that in an RFP, request for proposal, to various vendors, and we'd have some kind of basis of comparison. But because we're not doing that well, and the requirements, I had a look at what the requirements that they were writing are very, very solution specific, very technical, then we have really no basis
06:22
to compare what one vendor is saying versus another. The solution to them would be, what if you were to model your workflows of your business processes, and these are complex business processes that they're looking at, and show them to the vendor and have the vendor sign off that either my solution, I promise you,
06:40
will fit your workflow, and if it doesn't, these are the gaps, and this is what we'll have to do to deal with it. Then you have a basis for comparison. You can start to say, okay, I can live with your solution, or you have to bend, or I have to bend, but the onus is now on the developer, on the vendor, to find those gaps, and it's not on the business side to find them.
07:01
So this is where a business analyst comes in. We'll get into the roles very specific. We have to help ensure that happens, and to help the client, the business side, come up with requirements that are solution agnostic. Sometimes they get great solutions, but to the wrong problem. Sometimes, as I say, the requirements are written that are solution specific,
07:23
that they run to the problems that I've talked about. Now, this is my own experience of it through the clients that I deal with. This is what, what you're seeing up here, is what the literature says. The literature being the only really good study I know on is there a business case for doing business analysis,
07:42
is a business analysis benchmark done in 2008. The author of that is Keith Ellis, another full disclosure, a good friend of mine. So I'm, on one hand, more disposed to believe, but on the other hand, I also have access to ask him a lot of tough questions about, is this study really legit? Because I'm a skeptic, and I'm sure many of you are as well,
08:02
but this is what his study did fine. And I have to say, I haven't seen one that has been quite as solid as this one. If you look at a company that has a good, a mature requirements process versus one that doesn't, there is a premium of 60% paid in terms of time and in terms of budget for not being good at doing that job. Well, my next question to Keith is,
08:21
and Keith, if you're listening to this somewhere in the world, sorry for bringing your own aim up here, my next question to him was, okay, but maybe you're not talking about Agile projects because there's so much close communication with the customer. Surely, even if you don't have a full mature requirements process, it won't matter. His answer to me was no, our study was methodology agnostic,
08:41
and we controlled for these factors. And what this chart shows, and I know the writing is very tiny there, even when it's a little bit blown up than what I've got on my screen, but it breaks down project success by every one of those rows, represents a different type of methodology, and Agile's in there as well. And the trend, although the numbers may differ,
09:02
the trend is still the same. Better requirements, better maturity in the requirements process means a better result in terms of project success. So that's a sales job, folks. You may or may not believe in studies, I don't know, but that's the best study I know out there right now. Now, by the way, there were a few caveats on that study,
09:21
and it may be why it doesn't match everything that you may have seen, and explain this to me as well. One of the caveats is if it's a small project, the study didn't look at it. We're only looking at transformational projects. At least $250,000 is one of the criteria for the projects they were looking at. Secondly, an organization, even if it's dealing with large projects,
09:41
but if it always deals with projects of about the same size, it eventually finds a good way to deal with it, whether they've got formally a good methodology or not. The trouble happens with, particularly happens in organizations where their projects vary, and then when you're looking at transformational projects in that type of environment, this is where the effect is the most pronounced.
10:00
So if there seems to be an argument for business analysis, so why is it not well understood that there should be people like this around, particularly in an agile world? By the way, I hope, I'm assuming everybody knows what I mean when I say agile, I don't have to go through all of that, but I guess this is, if you don't, then look at the fine print here. One of the basis behind agile has been around for a very long time.
10:23
It's the concept of iterative development, that you do a little bit of analysis, a little bit of programming, a little bit of design, a little bit of programming, a little bit of testing, put something out to the user community that they can use, and then iterate, right? Like they say in the shampoo bottles, and repeat. That goes against any kind of idea of full upfront requirements.
10:42
For those who have thought of the job of a BA, as it is in traditional waterfall projects, which is to find out everything the business could possibly need, put in an enormous big document, the business requirements document, and throw it over the fence to developers and say, hey, this is what I want you to do for me, that certainly does not apply to an agile project.
11:03
Working software over comprehensive documentation, much greater interest in putting your effort in something that's going to show you a result. Secondly, in a waterfall, and when I say waterfall, I'm talking about the exact opposite of an agile project, the way things used to be before agile.
11:21
Although I should say, before agile was waterfall, before waterfall, in my view, actually was agile. When I got into programming, you can tell by my gray hairs, it was quite a few years ago, 25, something like that, maybe a little bit more even. All the teams that I worked on, we were paired developers.
11:43
I was working with maybe two or three other developers on projects. I would go in one day, and I would be talking to the customer to find out what they wanted. Another day I'd be designing, another day I'd be doing a bit of writing. I'd go out and test, and I would actually have to teach the customer how to do what it is that I wrote. Everything about that is agile.
12:02
A lot of discipline was thrown on later on to say, no, we can't work that way. One of the reasons was that budgets got overstretched, projects tended to run away from themselves, and so a tremendous structure was put on things. Now we've moved the other way, and so that's too much structure. We have to find some way to work in an agile way,
12:21
but make it work, and so you have methodologies like Scrum trying to do it. In this world that we are in today, business people and developers are working very closely together. If you view the job of a business analyst as someone who runs to the business and keeps the IT people at bay, business people are very afraid of IT people. They feel they're going to be snowed by them.
12:41
To be snowed is a Canadian expression. I'm not sure exactly how to... Are you going to be cheated by them? It's not hard to find the right word for that. Even today we're finding this quite a bit in many large shops. They're going to work. They feel, okay, I'm going to talk to somebody who can understand me, and that becomes the BA, the business analyst,
13:01
and I'm going to send that person out, and they'll talk to the developers. The business analyst then is sort of like Kissinger used to be in the old days, a subtle diplomacy running back and forth between these two warring parties. In an agile world that doesn't happen. We actually want to bring developers, and we're bringing the business people in the same room. So it doesn't seem then that there's a job for the BA,
13:21
and this is why my friends in the BA community are very worried about what's going on here in the agile world. To this I would say, just because you're having lots of conversations with the business side does not mean that those are going to be useful and meaningful conversations. What does that mean? It means that there is a danger that if you're not good at having a,
13:41
if you don't know how to structure those conversations, you're going to be wasting the stakeholder's time a lot of the time. And yes, you can go back and back and back, but the result is reduced velocity. Velocity is the way that we measure in a Scrum project, how many points, story points, in other words, how much functionality can you get through one iteration, through one sprint.
14:03
You start to accumulate technical debt. I remember a project that I worked on back in my programming days, and again, I haven't programmed in many years, so I'm not up on it anymore, but many of the issues are still the same. I was working on a system that was really as architectural and away from the user as you could imagine.
14:21
It was early days, so I had to do some of the stuff that is very, you know, it's already there today, write an intranet package from scratch, write a file sharing package which did file locking and so on from scratch, write a Kix, I actually wrote the first Kix pseudo-conversational system in COBOL,
14:42
that really dates me there, from scratch and actually work out the architecture for how does the mainframe actually know where it is in a conversation when you're doing something like that. To me, those are the really fun days because the big problems were not solved yet. So I wrote a system like that, and this one had to do with intranet and file sharing, but I didn't understand all the ways in which that system was going to be used,
15:02
so I made some design decisions along the way. A few months in, as we kept working and working on this thing, when I really started, you know, I started to learn a bit more and more and more about what the actual business community wanted to do with it, but it happened to be an automotive manufacturing, a manufacture of automotive parts,
15:21
so the reason they needed an intranet is they needed to send stuff from the office computers to the computers that were actually in the shop where the stuff was actually made and back and forth again. When I found out all the needs, I had to redesign everything. The whole thing was this. It got exponentially harder and harder to add pieces. Had I known from the beginning that that's what they would have wanted,
15:41
I would have designed everything differently right from the start. So I accumulated technical debt. Technical debt means there's something not quite right in the software and you're going to have to change it later. So yes, it's okay to have some technical debt, but not if it remains for a long time because it gets more and more expensive over time. So if we're talking then about trying to fix some of this,
16:04
what I'm talking about is having somebody, a business analyst, and this is my pet chair, who has got a foot in both worlds, possibly somebody like me or somebody like you who maybe was very heavy on the development side at one point in their life and now is stepping over into the business side.
16:21
It doesn't mean you have to be like me and give up the development side. As you get older, by the way, you probably will. Those sleepless nights don't seem as attractive anymore. But it also can be that you're staying in there. You're somebody who people within your organization realize is good at this, good at talking to the business side. So what is this person?
16:43
It's a profession that actually really got its foothold in the country where I come from, Canada. The IIBA is the International Institute for Business Analysis and they're actually housed in, they're centered in Toronto, the city that I come from as well. I know a lot of people actually put this thing together. One of the only things that we're good for, other than Canadian beer, we're known for,
17:01
and hockey, but we're not even good at that anymore because we get slaughtered by the Americans all the time. But this one is still our baby at the moment and now we have members all over the world. This is a quote that you have up there from the IIBA's business analysis body of knowledge, referred to as the BABA. It's a practitioner of business analysis.
17:21
That's a Weasley term for a job because it doesn't, it says, what am I? I'm somebody who does what I do. It's a very circular definition. But I found it weird at first. Now I see the wisdom in it because it's not specifically talking about a role, it's talking about a job that you do. And what the job is all about is accumulating some skills, tasks and techniques
17:41
that allow you to work as that liaison. Somebody can help interpret the IT side to the business side and the other way around as well. Now in an agile environment, what does that actually mean? I talked about what it meant in a waterfall environment and why there is a feeling sometimes that we don't need a business analyst in the agile world.
18:04
Well in agile world we're talking about a function, not a role. Because on agile projects we expect everybody to be able to take on whatever aspects of a job that they want, that they're able to do. We're talking about a function. When you're doing business analysis, you are the business analyst. I heard Mike Cohen was here last year speaking,
18:23
speaker on agile. I read his books. He talks about the product owner, part of their role is business analysis. On the other hand, I've looked at DSDM, another approach. The product owner is very distinct from the business analyst on an agile project.
18:41
To me that's an uninteresting argument either way. Whoever is liaising between business and IT, at that point in time in the project is performing business analysis, so it's a function. It may not be a job title. The job is to be a facilitator, not a messenger, which means that in an agile world, yes,
19:00
everybody's in the room at the same time, but for those conversations to be meaningful conversations, it's helpful to have somebody who is good at doing that. And the focus of what you're doing is on structuring that conversation, not on structuring the documentation, because we're not so interested in so much informal documentation in an agile world. We don't get it all up front. It's constantly changing anyway as we go.
19:20
However, there is a value in structuring that conversation. In case you think that's only me that's talking about it, I've mentioned Mike Cohen also, who talks very specifically about a BA, a business analyst, within Scrum Projects. This is from DSDM. That's the dynamic system development model.
19:42
And their current model is called a TURN, and it's an agile model, and there we find the BA smack there in the middle of this snowman, as it's often referred to. The BA is there in blue, meaning that their focus is really on the process. Are we actually doing a process right? And just to go back to that again,
20:00
this is a quote from them. It really sums up the role. What is the BA? Facilitates communication between the solution developers, the testers, and the business roles, and in particular the product owner. Why the product owner? Because many product owners who find themselves in that job, ideally they come from the business side. Coming from the business side, that does not mean they actually know how to put together requirements.
20:22
User stories in a Scrum world have to end up in a product backlog, but how do you know what the user stories are supposed to be? It's not always that simple. It's simple if you're writing a simple app or a very small application, but if you're trying to automate a business process that's complex, it's not a simple thing
20:40
to work out what the user stories ought to be that should go into that product backlog. So that's why they speak about that. But in a higher view, I guess, a higher sense of the world, ensures that business implications of day-to-day decisions are properly thought through. It's very easy, as you're going through the details of a project, to forget what the whole rationale for the project was.
21:00
In other words, you can do all the details right, but in the end, you lost the view of why did the business go in, want to initiate this IT project in the first place. And so you need somebody there often who is going to keep the focus back on does this actually help the business? It may be a beautiful bit of programming there, but does it actually help the business?
21:21
Does it align with business strategy? So what the business analyst then brings to the table are a set of skills, and I'm going to go through these in upcoming slides so we won't pause over there. The first set of them is the soft skills, and this is the side, actually, probably one of the most important, but the hardest to talk about because you really need to experience them. So I'm not going to talk about them for too long,
21:41
but I also, I don't want to ignore them. I mentioned that I started my days as a coder. When I, and I'm sure many of you can relate to this, I didn't get in there because I wanted to talk to the business side. I didn't get in there because I was interested in accounts payable and general ledger. I would have been an accountant if that's what I wanted to do. I wanted to sit in front of the computer and do fun stuff, right?
22:01
To me, it was like a game that I was getting paid to do. By the way, I slipped into the programming. I was never supposed to do it. I'm supposed to be a nuclear engineer working on power plants. And the way I got into it was only by accident. My first job was for Atomic Energy of Canada, and I worked on a simulation program. Let's simulate on the computer what would happen if there was a loss of coolant accident
22:21
and see what would happen, right? So that was, I got in there really because of heat and mass transfer, but what I was working on day to day was the programming. I loved it so much that I just said, to hell with the engineering side. I never liked chemistry anyway. I'm going to become a programmer. And so I continued doing that and getting deeper and deeper into the code until one day I found myself working for a smaller company
22:41
and it was all about this GL, AP, AR stuff. And to be honest with you, I didn't know what even those letters meant. I had to learn as I was on my way out to the client that GL stands for General Ledger. And suddenly I found myself on almost day one of my job there talking with the client about GL and AP and AR
23:01
and not having a clue what it was they were talking about. Yet I had to get the requirements for it because I was going to have to modify a system that wasn't working properly for them. The first thing I did with them was I thought, okay, I'm going to cheat. I'm going to get them to teach me. So I'm going to stand behind them and I'm just going to ask them, why don't you just pretend I'm your grandmother and why don't you just explain to me
23:22
step by step what it is you're doing when you're doing something on this GL package. And so they did. And I said, it's not because I don't know, but I have to make sure the programmers get it right because they don't know what your business is. Of course, what they didn't know is I was the programmer who was going to go back and actually have to code all that stuff up. I had chanced upon a technique that's in the Babak
23:40
in this business analysis book. It's called, some of our clients refer to it as close to the customer. They refer to it there as job shadowing. Very useful technique, but it's one of many that if it's not pointed out to you, it may not be something that you think of right away. Stakeholder analysis, planning and running of meetings. If this was not an issue,
24:01
I would not have this on the slide, but when I go in and speak to banks and those sorts of organizations, they tell me that when their developers go and have meetings with stakeholders over large projects, they think that every meeting has to be a very large meeting, and the meetings get out of hand. And what they don't really understand
24:21
is how to actually plan for these meetings, how to size them, who to invite to which meeting at the early phase of a project, in the middle of a project, and later on in the project. Those are basic facilitation skills that if you're a good facilitator, you know how to do. But it's not necessarily something that you come by automatically just because you're a good coder.
24:41
And so hence the need for somebody who is good at that side of the story. And what I'm going to focus on though is another aspect of business analysis, which is what goes on once you're actually inside that meeting. Aside from the soft skills of making sure your meeting stays on time, you know, you do all those things well. Well, interestingly enough, what I found out is that
25:01
a lot of the techniques that I used to use as a developer are very, very useful if I actually pull them up front and I use them right there in the conversation with the stakeholder. I'm not talking about writing code in front of them, as many people have been doing here at NDC. Very impressive, by the way, watching people write code in front of everybody and even have people in the audience
25:21
correct them when they make a mistake. But I'm talking about a little bit of a higher level. If any of you work on the systems analysis side, you'll be used to diagrams like class diagrams for RDBMS, relational database management systems using ERDs. Almost everybody at some point looks at a flow chart as a way to work out,
25:40
sketch out the logic. A lot of these techniques have immense value, not just for planning and designing software, but also for understanding the business environment. And so what the BA is often doing is taking technical techniques and actually applying them in a totally different context. And I'm going to walk you through a case study, as long as I don't run out of time here,
26:01
where I'm going to show you how to do that, or illustrate how to do it. Maybe you already know how to do it. This is a quote from DSDM at turn. Any project must be aligned to clearly define strategic goals. And so how do you actually make sure that that happens? The business analyst is the person on the team
26:22
who's very aware of what the real deal is at the executive level, all the way down into business. The business side is what I'm showing there on the left in blue. An enterprise has a mission statement, basically how they view themselves, a vision, how they'd like to be in the future,
26:40
where they see themselves being a few years hence, goals that they would want to reach. These are measurable goals. We want to be a Fortune 500 company that makes so much and so much money. The strategy for getting there. So that's sitting there in the background, and that's the strategic goals side of what DSDM talks about. On the right-hand side of what you're looking at there is what happens at the project level.
27:01
Somebody notices an opportunity or a problem and wants to solve it. From that they drive down business requirements, which are measurable factors for success. Then from there we get into stakeholder requirements, what does each type of stakeholder want to see from this IT system, and eventually get down into the weeds of the detailed requirements.
27:22
When I was a programmer, my fault was going down to the weeds right away. I didn't have much interest in working my way through. Sometimes it takes a little nudge to get you looking at that other side. So we're talking about sort of a top-down view, starting from the business level and working your way down to the details. And the reason I've got this funny little animation going
27:41
is it's top-down-ish. By ish I mean you have to have a broad and shallow view of where we want to go from requirements point of view. That's the kind of thing that if I had that, I wouldn't have made the mistake I made that I talked about when I worked on that intranet system. But it doesn't necessarily mean you're going to work out everything down to the details
28:00
before anybody starts coding. That's exactly the opposite of what Agile is all about. You pick some of them. You'll pick, for example, an epic, which would be a very long story, and then break it down into, decompose it into individual user stories. These are smaller tasks. And then with those, as you go through an iterative approach,
28:20
work down the details of what it is the user needs to happen in those cases. Now, I've discussed it for user stories on this slide. They've now disappeared, mind you. And just to the right of it is the use case approach. There are two styles of working out there, user stories and use cases. Both of them are quite popular,
28:40
and both of them apply to Agile. Use cases applies to both Agile and Waterfall. User story is not that applicable to Waterfall approaches because there's not enough detail and too much reliance on conversation to make a Waterfall person comfortable. So, as I mentioned them, I just wanted to take a moment just to talk about those two approaches because I've seen a lot of argumentation out there about,
29:03
is a user story a use case? Is a use case a user story? Are they entirely different worlds? Are they apples and oranges? I'd like to just point out here the definitions for anybody who's wondering about that issue. They're about 90% the same. They're definitely, to me, not apples and oranges. User story is functionality. A use case, if you look at Martin Fowler's definition at the bottom,
29:22
I've color-coded them so you can see, is a visible function. Both of them provide value to the end user. Both of them are design agnostic. There should be nothing that even talks about what the GUI design is going to look like in either of them. So, just by definition, they're certainly very similar. And if you actually look at the documentation that is provided,
29:43
at a high level, it's very much the same. You've got on the left-hand side a user story. On the right-hand side is a use case. It's almost a one-to-one correspondence. The top part of the user stories will be, if you're writing them on cards, what you would write at the top, the front of the card and the back of it. You know, a user story also goes with the three Cs.
30:02
It's got to be also conversation and confirmation. The card is the first C. Well, on the back is confirmation, means test cases. And really, everything that shows up in a user story also shows up in a use case. We just call it something different. So it's not a really huge deal. The difference happens in a couple of issues.
30:22
One is, there is the option with use cases to put lots of other stuff afterwards. In a user story, that happens through conversation. But it doesn't mean with a use case, you can't do it through conversation as well. So I don't see a huge difference there. I would say in general, every use case is a user story, but not every user story is a use case. The use case is a more restrictive definition,
30:43
if you want to say so. Here's an example of one reason, and why it might even make sense in a project that you're working on, to use both techniques together. Better together. You can have user stories and often, and I don't know what we're finding, is people are often writing them in a very feature-like way.
31:01
As a field agent, I want to add copper wire tracking to a mapping system. This is actually the kind of thing that we're seeing in one of the projects we're dealing with right today with one of our clients. That's really interesting, but what is it you are doing when this copper wire tracking is going on? It's not clear exactly from what you're doing.
31:23
You could actually use this as a basis for development, but it's quite useful to be able to map that to the actual task that the user is doing at the time. A use case is a set of actions. That's one of the differences between the two. It's not just anything that a user needs. It actually is a series of steps.
31:42
When I asked this question to our client, I found out, what are you doing with this thing? Why are you switching systems? What they actually want to do, by the way, is consolidate different GIS systems across the country into one. What are you doing with this damn thing? We're designing and building outside plants.
32:01
This is what they're actually doing. We're mapping roots, and when we map roots, we would like to know what kind of resources are actually under the ground. Maybe we'd be able to tap into that. That's why we need to add copper wire because some of our systems are older and they don't have this ability right now. That really becomes useful because then, for example,
32:24
at some point I want to do an integration test. I need to know whether or not this new system is going to work for me. In fact, even better, I should specify what those tests are going to be before I go ahead and go with the vendor because I want the vendor to commit that this will work. To be able to do that, I need to know what it is the users are going to be doing with that feature.
32:42
The other use for use cases in conjunction with user stories is that a user story could be, and I'll give you three examples here. As a customer, I would like to be able to place an order. It could be for food, it could be for Amazon. Another user story might be, I would like to have fast checkout,
33:01
a quick way to get through that order. That's a separate user story. Another user story might be, and while I'm doing that, I've accumulated rewards points. I want to be able to use those as well. Trouble is, all of those user stories relate to the same user goal. I would like to place an order. In the use case approach, they would be separated out
33:22
just as they are in user stories, but they would all be bundled together under one thing called the placing of an order. That's the name of the use case, and these different user stories show up in a use case as different flows within the use case. So it gives us a way to bundle different user stories that actually relate to the same goal from the user's point of view.
33:42
Finally, what a BA brings to the table is traceability. Some discipline with regards to tracing, and this gets to the issue within a previous slide, although I didn't voice it, dependencies. So, for example, if somebody comes to you as a developer and says, we're making a change in the way
34:01
a particular business process works, what's the IT implications? If you have traced that business process down into something in the requirements and then from that all the way through to configuration items, to items that make up the software, to design items, you could answer that question
34:21
because it's there in a table, and I'm talking about something as simple as it could be an Excel spreadsheet, or it could be as sophisticated as a configuration management database, which is used within the ITIL approaches, or something in between a requirements management tool that does that for you. Similarly, going in the opposite direction, what I just gave you was a downstream dependency.
34:41
Upstream dependencies are, if I change this piece of coding here, or I change this unit or this system, which business processes are going to be affected? I need to know that because I want to make sure that it's going to be aligned well, I need to be able to do an integration test, I want to make sure that the business stakeholders who use those processes have been consulted before we go ahead and do this.
35:01
You could answer that as well if you've done this kind of traceability that I'm talking about. Yes? Yes? Oh, yes, yes.
35:20
Actually, it's the two working together. It's not a fight. Aspects of the project, which have to do with scope, which is a big issue with the project manager, they're relying on the business analyst to alert them to that fact. The BA is not going to make a decision should it be in or out. You know, if somebody did something that's out of scope, for example,
35:40
but they're going to alert them to it. And they don't often want to get into those details about keeping track of all these dependencies, but they do rely on somebody to do it for them. So it's a collaboration between the two. The last one is also, by the way, important as well. We've talked to clients that come to us because they need help on their requirements and requirements traceability. And why? Because a new project comes up.
36:00
This happened with a large insurance company that we were dealing with not too long ago. And now the project is in, business managers suddenly realize, oh, I've been waiting for this excuse all my life. I'm going to put in everything that I want. And they start slipping in extra functionality. That's really lovely, but it wasn't budgeted for. So somebody's got to actually slap the hand and say, hang on a second.
36:21
I'm not saying you can't do it, but I've got to alert the project manager. This thing is going to be out of scope. And then you can make an intelligent decision and not let it slip away. So now what I want to do is run through and literally run through, based on the time I've got here, is run through a case study with you and look at how a, and it's very simplified,
36:41
so forgive me for that. I've got to do it in the time available. Look at how a BA will take, and again, I'm not talking about something necessarily with this job title, but the person who's taking on this function within your team, would take something all the way down from a business issue, a business problem, all the way and drive it all the way through to an IT solution,
37:01
or at least to the requirements for that IT solution, because once you actually start coding, you're not doing business analysis anymore. So let's take a theoretical case here, ABC Insurance, and let's look at the business environment. And why is this important? Because the BA is supposed to always keep a focus on this thing. So we would like to delight our customers through fast, seamless response to customers' needs.
37:22
These kind of crazy mission statements are par for the course on the business side. Our vision is to be a leader in customer service and experience in the insurance industry. What are we getting from this? Very customer-focused insurance company. Not all insurance companies are, right? They just want to be able to use insurance as an excuse to pull in money, and then invest it and make their money that way,
37:41
and insurance is almost an excuse to get there. Perhaps they don't actually ever want to pay out a claim if it's possible. I've seen the movies, probably have as well, where that's the case. But this company's different. This company knows that if they can actually provide a good experience for their customers, they're going to get more customers, good word of mouth, and that's actually what's going to bring those funds in. Now that's important.
38:01
The BA's going to keep their eye on that. We're going to see why that actually might be important when IT development happens. Business goal has to be something very specific. I've actually taken this one because it's something that a lot of our clients are really into right now. Decrease voluntary churn by X percent. Are you familiar with that term? It's from the business side. Churn means the degree to which they lose customers.
38:21
They spend a lot of money pulling in every customer, and they'd rather retain a customer. It's much cheaper to put an effort in retaining that customer than it is to actually get a new one. So they don't like this churn, and there are two kinds. Involuntary churn is when we kick the customer out because they're not paying their bills. Voluntary churn is when the customer, on their own,
38:40
made a decision that they want to get out. We want to reduce that. We've also, by the way, got customers who want to decrease involuntary churn, but that's a whole other discussion. So maybe one of their strategies for getting there is that whenever there's a choice to be made, they're going to value quick response, a good experience for the customer over service center cost reductions. It might cost us a little more to make the customer happy,
39:03
but our goal is not to cut costs, not to cut the number of FTEs, full-time employment on the customer service side. Our goal is actually just to retain that customer. So as a BA, you might begin by having a brainstorming session. If you're really a high-level BA working at that high level with a customer,
39:20
with your business, and you might use a tool, one of the tools that comes from Six Sigma, the Ishikawa diagram, also known as the fishbone diagram, and goes by many other names as well. Cause and effect diagram is another name for it. By the way, the reason I've gone low tech here, it's actually sort of high low tech, is why am I doing this as a sketch? I want to get across the idea.
39:41
This is not documentation that you do after the fact. It's done in real time. If you don't do it properly, especially in an agile environment, during the actual meeting. So you might begin by saying, you know, tell me, what is your problem? Our problem is we've got this high churn, high voluntary churn. Am I asking the five whys? If you've heard of that, it comes from Six Sigma.
40:02
It really just means something fancy. Ask why five times, and eventually you're going to get to the root cause of the problem. A way to track all the answers to those whys is to do a diagram like this. So the first why is, well, you've got a high churn because people are complaining about poor service. They don't like the service they're getting. That's the reason they're quitting. Other reasons might come up as well.
40:21
I just didn't want to, didn't have time to sketch them all in there, but it might be we don't have the same kind of offerings as other people have, or our price is bad, right? So these could be other reasons. For each one of those, we keep asking why, why, why. So I followed one of them through. Poor service, why poor service? Because we're getting poor response time on claims. Takes too long to answer a claim,
40:41
and maybe the, what's the reason why it's taking so long for the claim? It might have something to do with the actual process that inherent in the process that we're using to handle claims where there's long turnaround, and specifically we've also had particular complaints about bottlenecks in that process.
41:00
So if we were to, we're using, if you're familiar, another technique is the Pareto analysis that a BA would use at this point. If we pull together lots of root causes, we then may say, hey, let's focus on the ones that give us 80%, will give us 80% benefit if we could just solve those, and the 20%, you know, we'll deal with later.
41:21
We're not going to get as much bang for our buck. Suppose we find out that these two issues of long turnaround and bottleneck are core issues, that we could actually solve most of this churn if we could just go into that, if we just deal with that issue. So the next step is, okay, let's take that, and let's put together a problem statement to understand what the real problem is.
41:43
Going back again to Six Sigma, to put together a good problem statement, you should answer the W questions. Who is affected by this problem? What is the problem? Who is affected by it? That's the next W. Where does this problem actually occur? Why is it a problem for us?
42:02
And then the other one, I'm not sure if it's a W or not, but what does the solution actually look like? Without saying what the solution is, but let me put it another way, what are the KSFs, the key success factors for that solution? So in this case it might be the problem of long turnaround and process bottlenecks. This focuses on what the real issue actually was. This was the root cause of the root problem.
42:24
Who does it affect? It affects policyholders. Is this something that only happens in one region of the country? No, it's a national problem. When does it occur? It happens when people submit claims. That's important to know as well because I can start to look at the frequency in which this transaction happens. And why do we care? Who cares? So what if it's a long turnaround?
42:41
Well we care because we've got a 35% voluntary churn. I just made that number up, but 35% of our customers leave every year. So what would we, without presupposing what the solution should be, how would we measure success? I don't know how many of you work, I've worked on many projects back in my development, so I didn't really know
43:00
what measure of success actually means to the business. Who cares about the business? Well this is why we care. A success solution would guarantee an initial response regarding claim eligibility within four hours. We want any customer who submits a claim to at least get an initial answer whether or not they're going to be eligible or not, and that should happen within four hours of the claim.
43:21
Number two, closure of the claim within five days. They should get paid within five days. What a great insurance company that within five days you actually get a check. Again, this is a theoretical example of course. I don't think that would ever happen. And reduce voluntary churn to 25%. Remember what we were worried about. We were worried about the fact that we're losing customers. You can do all of the details right on an IT system
43:41
and it'll work really well, process claims, and yet if we do not actually reduce churn, there was no business value in the company for doing it. And there's the BA. Focusing, putting together this statement helps focus the minds of everybody on the team as to what it is we're really trying to accomplish, not just on the technical level,
44:00
but also from a higher business strategic level as well. So the next step after that, when I get somebody telling me, well, we want to consolidate our GIS systems, or I get another one, here's a case where the solution is actually being presupposed. I'm about to discuss this with a client right now.
44:21
Their problem to them is we want to include behavioral analytics in our collections policy. I don't know if any of you are working on this, but the idea is that rather than just look at a person's credit history and other very easy to ascertain factors like that
44:42
to decide whether or not we should sick the bad boys after the customers who aren't paying us, instead we'll use behavioral analytics. We'll actually look at their behavior. Have they been lazy payers, for example, over time? Are they high-value customers? We don't want to piss them off, right? So we're going to use this behavioral analytics,
45:02
and there are companies out there who are producing software like this, and we're going to plug it in to our collections and credit applications. To me, that's already the answer. The problem actually was they're getting involuntary churn. They're actually kicking too many people out, and this company's actually a good company. They don't want to kick so many people off the rolls.
45:23
Maybe that person eventually always pays. They just tend to be always late. So if you look at their behavior, maybe we could avoid that. But perhaps the way to get about that is actually to work another way. My son works in the company. He works at HootSuite, and their approach is always to run experiments. So they actually would take a group of their customers
45:42
and run a little experiment. Let's take this approach with them and see how many people leave the company. Let's take another approach with them and see how many leave there, and we'll actually base our decisions on actual experimentation on real, live customers. To me, then, the other company who's not doing this is already presupposing that the answer to their problem is behavioral analytics.
46:00
Well, this is a case where someone is selling them a bill of goods, and maybe it's a good bill of goods. There's some kind of magic mathematics behind it that will ensure that everything's going to work well. But I'm not so sure. I'm always a little bit of a skeptic. So my first question that I ask people when they're about to put in something new is going back to that original question,
46:21
what is it you are trying to do with this thing? Well, here it's a very simple business process. I'm trying to process a claim. I use a diagram like this in that discussion because it is so simple. And I know as developers, we've seen all the complicated stuff, it's easy to scoff at something that is too easy. But what's nice about these easy things
46:41
is that they focus the mind on what's important to the business and what's important to the project at that point in time. You want a GIS system, what are you doing with it? You want a behavioral analytics, what is actually the business process that you're doing at the time? And who are the stakeholders? I've seen lists and lists of requirements. They could be user stories in a product backlog, they could be formally in some other way,
47:01
and it's very hard for me to see who the business stakeholders are there and what the business processes are. I'm not seeing the business environment at all in those requirements. So this type of diagram focuses on that. It said the stakeholders are all these little stick figures. The poor stick figures that have a circle around them, they're referred to as workers in this approach.
47:20
They are people who work within the company to implement business processes, and the stick figures that don't have a circle around them, they're on the outside. They're outside of the, in this case, if we think of the business area of claims as being our world, then anybody outside of that would be these stick figures without a circle. Technical terms for this, this is a business use case model. A business use case is
47:42
any use case is an interaction with a system. When that system is actually the real world business we refer to as a business use case, when that system is a IT system, we refer to it either as a use case or a system use case. I like to use the word system use case because it gets the idea across better. So what this actually does, it just shows me for every business process
48:01
who the players are. And that's actually a very useful thing to get early on in the game. Next step after that is to work through with my stakeholders what the business process actually is. I might start with the external process, the public process sometimes referred to, and then I work my way through to the internal one. Why is that important? If my client is going to a vendor solution,
48:25
it's safer for my client to show this diagram to the vendor and say, it's up to you to support this, and if your solution does not support this particular process, you better tell me, right, and you better show me the gaps, and then we can have a discussion about how we're going to deal with those gaps.
48:41
It's much safer than saying, you tell me what your process is, dear vendor, and I'll try to figure out where it doesn't seem to fit, and hopefully I'll get it wrong and I won't get burned by those CRs. The other reason as well is that even if we're developing it internally, we're going to develop little pieces, and we have to make sure at some point that all those little pieces are going to fit together. Some is going to have to fit together with other systems
49:02
and also with manual processes that are going on, and this puts the whole picture together. So it's a simple swim lane workflow diagram. How do I actually use this in a conversation? If it's a cross-functional workflow process, and if it was a process that involves many different people in many different roles, I invite them in.
49:21
I know who to invite in because I've already done the business use case modeling. So for every process, I've already had those stick figures. They tell me who it is. So everybody that showed up before shows up as a... Here it says a role. Could be a column if I like to flip it. My customer, my policy management, and accounts payable, these are outside of the claims business area.
49:41
And then within claims, I've got my service rep, my manager, and my adjuster. I invite them all to the meeting, ideally. If I can't get them all in and I can't even do it through video conferencing, then I shop it around. I go around to different people and I build together a comprehensive view. So here, I hear that a customer begins by identifying a policy as they call up a service rep.
50:00
This might be what's going on today. The service rep verifies the status of the policy. Do you have a policy with us, and have you paid for it? However, since we're claims, we don't really have that information available. And even if we're talking about systems, our system doesn't have it available. However, there is a policy management business area and possibly a policy management system
50:20
which manages actual policies. We can query that one. Next step is all going well, and I haven't put in the diamonds to say, what if things aren't going okay? So I'm assuming it's all, this is a claim it's going to go through, just to simplify things. The customer now provides the claim information. The service rep enters into some kind of a system. And now wants to verify that this kind of damage,
50:42
maybe it's damage to my house, would actually be covered under the kind of policy that I have. I need to do that, but that's a policy management issue. The details of what's covered under what policy is a factor of the policy itself. So again, we have to do a query.
51:01
In the old days, this would be really old days, a little note gets sent down a tube off to the people in policy management, and they'll answer that. They'll look it up and answer that question for me. If it's IT-enabled, which of course it will be, this happens through messaging to an IT system. All going well, then the next step is for a manager to assign an adjuster. The adjuster then goes out to the site, adjusts the claim.
51:21
Manager then, all going well, approves that claim, and finally payment gets issued. But claims doesn't issue the payment. Claims asks accounts payable to do that. Now, I've actually, as a customer of insurance companies, I've seen this not happen well. This workflow is extremely important. This is why I say you can get the IT part right, but miss the business side. I actually had an adjuster come out to my home
51:43
after there was a flood in my basement, only to tell me two things. Number one, the policy that I had would not cover this because the water came from the outside, and they only cover it if it bubbles up from the drain. I mean, God, what a horrible thing. What a restriction.
52:01
And number two, by the way, you forgot to pay your policy. I actually was out of date. Now, as a BA, I'm thinking, why the heck did they ever get that far to send somebody out and pay all that money when, shouldn't they just have checked to see whether I paid my policy first? Well, nobody actually really spent the time to look at what the workflow should be to make sure that everything really fits.
52:22
So this is to make sure that doesn't happen. The next step after we've got this workflow together, if we're working on it, I'm talking about the extreme case of a transformational project where you're really going to be changing the way things are done, is to look at, okay, so what are the individual IT requirements? Something around the level of what are the user stories,
52:40
but I like to use the use case approach here. Now, well, in other words, how do we clump these tasks together into requirements that make sense? Well, one rule you get out of Scrum is that little clump of requirements, that little piece, that user story, should be something that's doable in one sprint. So I can give this to the team
53:00
and they can do it all in one sprint. The use case terminology would be a use case flow, where a scenario of a use case should be doable in one sprint. So that's one way to get the size. If it's too complicated, you can't do it in there, then split it up. The use case approach would say a little bit more, though. It adds more restrictions, as I said. So it says, as well, we should clump them together so that all the tasks that a user normally does together
53:22
should be one clump of requirements. If we bundle things right in the requirements phase, hopefully the developers will also put those tasks together. Lest you think that this always happens, our company is a IBM something-or-other partner. And in order to become this partner,
53:41
after we've gotten through all the requirements that they have for it, we had to sign on to their system. I had to go to one system and do something else, get out of that, go to another menu item from another system and do something else, get out of that and go into another one. I don't want to slag the company. Maybe I shouldn't have mentioned them here. But they had, it was so complicated to do, they had advisors that they gave me the number for
54:01
that I could call that would help walk me through their process of becoming a partner. What a lousy system, and you're supposed to be the consultants to the world about, you know, had they followed this simple principle of just clumping those tasks together, this would never have happened. Secondly, this should be something that I do at the same point in time. If I'm a manager,
54:21
I do a little bit of work here and then a little bit of work there, then that's really two different use cases. And so here are two options. One kind of clumping would be this. The X is, first of all, is I've knocked out of the workflow anything that happens that's offline because IT people don't need to know about that when they're developing. I need to know what does it be to make sure things work, but this will not end up in any code.
54:40
So let's forget about that. Any time I cross a swim lane, it's usually a different user. The general rule is one user, one session, one IT session. So if I go from service rep to manager to adjuster, these are different use cases, and think about it, they really would have different menu options. So I'm already looking ahead to what the menu options, how the menus would be organized.
55:02
But the question is, do I put verify policy status and enter claim and verify coverage as one use case, or are they two? Being a BA, I'm very focused always on the business. So I say, well, what would it mean? What would it mean to the business? And the BA is helping to explain business implications of an IT decision. What it means is the service rep
55:22
gets off the phone really quickly, right? I get the policy information, I check it very quickly, I put the claim information, I say, we'll get back to you, hang up the phone, pick up the next phone call. If my goal is increased throughput, more phone calls per minute or per unit time, I'm going to go with that approach.
55:42
But remember what the goal was of this company? Very customer focused, and one of the key success factors is going to be how long it actually takes to get a response. The fastest response I would actually get if I did this one over here. Right when I'm on the phone, I'm going to spend a little extra time with my client
56:01
and verify that that incident would actually be covered. And not only that, I'm going to automate the job of the manager, and our system is actually going to assign that adjuster right there, and I can tell that person right on the phone, on Tuesday, somebody's going to be out and they're going to visit your home. Customer feels so much better now. I actually talked when I was presenting this exact example.
56:21
One of the guys said, oh, that actually happened to me, both cases. One company came back after a few days, and in the meantime, the damage was so great as the water had spread, the water damage had spread, that it cost me a fortune to fix it. The other one came back to me immediately and gave me all this information that I'm just talking about here. That's the one that I stuck with.
56:40
Based upon that, we now know what each user needs from the system, and we can summarize that very cleanly in a system use case diagram. The stick figures are the users. It looks like the one we saw before, but now these are actual users of a system. Not customers, not people who interact with the business as a whole. Each of these tasks is an IT task
57:00
that happens in one session. In other words, it's a system use case. I'm going to flip through quickly because I've only got three minutes. This is an example of a traceability matrix. This issue of being able to look at the dependencies, you can put whatever you want to trace against what goes in here. It can be a simple table, as I've shown here, or a more sophisticated requirements management tool.
57:20
The second-to-last technique I want to show you here is a decision table. At some point, I get into a situation with my clients where they've got a very complicated business decision to make where what the business does depends on many factors, and I want to get this across to the developers. I've found these to be very hard discussions to have sometimes
57:40
as they run me around in circles. So what I now do is I use a technique of a decision table which I first encountered many, many moons ago as a coder. I could code this thing up and actually get code automatically generated to support this. So I don't even need the programmers, really. We skipped them. But it's actually most useful as an interview tool.
58:01
So what I now do is I say, hey, can you just tell me what you base your decision on? That's part one of the conversation. I talked about this all being about structuring the conversation. So yeah, it depends on making this up here for illustration purposes. This might be something where an adjuster decides how they're going to treat this insurance claim.
58:21
I need to know what kind of an incident type it is, whether it's weather-related or not, whether the damage began externally from the house or bubbled up from the inside, and whether or not there's a structural element. And I don't, if they start to ask, explain to me under what circumstance, I stop right there, you're confusing me, I don't care about your logic,
58:40
just tell me what it is you need to know. Next I ask them, what is the final result of what you're going to do? They say, okay, well, I'm going to either pay them, decide to pay them right away, or it's too complicated, I'm going to have to refer it to have another expert visit the site, or I can reject them out of hand. Next issue comes up is, how do you know when you're sitting down with a client that you actually got all the requirements before you leave?
59:01
Well, in this case, it's simple mathematics. It's the number of answers up to the first question times the next times the next. Two times two times two is eight. Eight cases. And all I need now is some way to make sure that these eight columns, these eight scenarios represent different situations. If I have more time, I can talk about a methodology, but you're all very clever there.
59:21
I'm sure you can figure that out pretty quickly. Every one of these eight columns is unique. What I now do is I now walk through this whole thing with my stakeholders and say, can you now tell me what you do, which actions you take for every one of these things? And so that's probably the last thing I can talk about. Do I have another minute? I'm not sure. Or do we have to stop immediately?
59:41
One last technique. If we have it, I don't know. We'll see. I get kicked out of here. The last thing I want to show you is a business domain model. This is a class diagram which developers use to decide, if you're working at the analysis level, use it for two reasons. What are the software classes, and how do they connect with each other? What kind of pointers do they need? And what are the tables?
01:00:00
What do they need? I use this now for a different reason, to find out what the business rules are. So, for example, I recently had a conversation with the Ministry of Government Services in Canada, and they talked to me about something called a netting batch. I didn't know what the heck that was, but very quickly in the conversation I found out what it was.
01:00:20
And I did it by drawing this sketch. It was a collection of transactions. What kind of transactions? Payable and receivable. For those of you who know the UML, these are...