Agile introduction for dummies
Upcoming SlideShare
Loading in...5
×
 

Agile introduction for dummies

on

  • 755 views

 

Statistics

Views

Total Views
755
Views on SlideShare
755
Embed Views
0

Actions

Likes
1
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile introduction for dummies Agile introduction for dummies Document Transcript

  • Agile Introduction For Dummies – Part IWATERFALL vs. AGILE METHODOLOGYThere is no IT meeting that does not talk and debate endlessly about Waterfall vs. Agile developmentmethodologies. Feelings run strong on the subject with many considering Agile ‘so of the moment’, just soright, while Waterfall is thought to be passé! But, before deciding which is more appropriate, it is essentiallyimportant to provide a little background on both.WaterfallA classically linear and sequential approach to software design and systems development, each waterfall stageis assigned to a separate team to ensure greater project and deadline control, important for on-time projectdelivery. A linear approach means a stage by stage approach for product building, e.g.1. The project team first analyses, then determining and prioritising business requirements / needs.2. Next, in the design phase business requirements are translated into IT solutions, and a decision taken aboutwhich underlying technology i.e. COBOL, Java or Visual Basic, etc. etc. is to be used.3. Once processes are defined and online layouts built, code implementation takes place.4. The next stage of data conversion evolves into a fully tested solution for implementation and testing forevaluation by the end-user.5. The last & final stage involves evaluation & maintenance, with the latter ensuring everything runs smoothly.However, in case a glitch should result, changing the software is not only a practical impossibility, but meansone has to go right back to the beginning and start developing new code, all over again. That’s Waterfall foryou! Now, as for minimal risk Agile, it is a low over-head method that emphasizes values and principles ratherthan processes. Working in cycles i.e. a week, a month, etc., project priorities are re-evaluated and at the endof each cycle. Four principles that constitute Agile methods are:1. The reigning supreme of individuals and interactions over processes and tools.2. As does, working software over comprehensive documentation.3. Likewise, customer collaboration over contract negotiation.4. And again, responding to change over plan follow-throughs.To synopsise the difference between the two, one can say the classic waterfall method stands for predictability,while Agile methodology spells adaptability. Agile methods are good at reducing overheads, such as, rationale,justification, documentation and meetings, keeping them as low as is possible. And, that is why Agile methodsbenefit small teams with constantly changing requirements, rather more than larger projects.Agile, based on empirical rather than defined methods (Waterfall) is all about light maneuverability andsufficiency for facilitating future development. By defined methods what one means is that one plans first andthen enforces these plans. However, Agile methods involve planning what one wants and then adapting theseplans to the results. Extreme Programming (XP) is an excellent example of Agile methodology i.e.:1. Communication between customers and other team members;2. Simple, clean designs;3. Feedback given on Day 1 of software testing;4. Early delivery and implementation of suggested changes.Agile methodology means cutting down the big picture into puzzle size bits, fitting them together when thetime is right e.g. design, coding and testing bits. So, while there are reasons to support both the waterfall andagile methods, however, a closer look clarifies why many software and web design firms make the moreappropriate choice of employing Agile methodology. The following table enumerates the raison d’être forchoosing Agile methodology over the Waterfall method.1. Once a stage is completed in the Waterfall method, there is no going back, since mostsoftware designed and implemented under the waterfall method is hard to change according to timeand user needs. The problem can only be fixed by going back and designing an entirely new system, avery costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of eachstage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changesto be made easily. With Agile, changes can be made if necessary without getting the entire programmerewritten. This approach not only reduces overheads, it also helps in the upgrading of programmes.
  • 2. Another Agile method advantage is one has a launchable product at the end of each tested stage. Thisensures bugs are caught and eliminated in the development cycle, and the product is double testedagain after the first bug elimination. This is not possible for the Waterfall method, since the product istested only at the very end, which means any bugs found results in the entire programme having to bere-written.3. Agile’s modular nature means employing better suited object-oriented designs and programmes, whichmeans one always has a working model for timely release even when it does not always entirely matchcustomer specifications. Whereas, there is only one main release in the waterfall method and anyproblems or delays mean highly dissatisfied customers.4. Agile methods allow for specification changes as per end-user’s requirements, spelling customersatisfaction. As already mentioned, this is not possible when the waterfall method is employed, sinceany changes to be made means the project has to be started all over again.5. However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalizationis done at each stage. As for Agile, each coding module can be delegated to separate groups. Thisallows for several parts of the project to be done at the same time, though departmentalization is moreeffectively used in Agile methodologies.In conclusion, though on the plus side, waterfall’s defined stages allow for thorough planning, especially forlogical design, implementation and deployment, Agile methodology is a sound choice for softwaredevelopment and web design projects. More and more firms are becoming Agile!Agile Introduction For Dummies – Part IIn my previous post I wrote about Waterfall vs. Agile. This post is all about introducing Agile Methods topeople who know zilch about them.Creating a buzz in the software development community, Agile Methods have drawn their fair share ofadvocates and opponents, with some considering agile methods to be the best thing to happen, while othersare not so kind. Agile Methods are a reaction to traditional ways of developing software and acknowledging the“need for an alternative to documentation driven, heavyweight software development processes”.Traditional methods begin work by eliciting and documenting a ‘complete’ set of requirements, followed byarchitectural and high-level design, development, and inspection. Frustrating, as fast moving industry andtechnology requirements ‘change at rates that swamp traditional methods’, and customers are unable tostate their needs even while, they expect more from their software. As a result, several independent Agilemethods and practices have been developed, methods that are actually a collection of different techniques (orpractices) that share the same values and basic principles. As the development world changed and it becamemore and more obvious that traditional methods did not always work as intended, new people-oriented andflexible practices became necessary to cope with the changing requirements, such as:Customer satisfaction takes precedence over conforming to original plans.Change happens, instead of preventing it, far better to cope and reduce the cost of change throughout thedevelopment process.Change elimination means unresponsiveness to business conditions, quite simply it can spell businessfailure.The market demands and expects innovative, high quality software that meets its needs, and meets themsooner rather than later. Thus, a discussion of new software developments methods saw the emergence ofAgile methodology with representatives of Extreme Programming (XP), SCRUM, DSDM, Adaptive SoftwareDevelopment, Crystal, Feature-Driven Development, Pragmatic Programming, and others convening andputting together an Agile Manifesto dedicated to uncovering better ways of developing software throughvaluing:Individuals and interaction over process and tools: Traditional software engineering lays too muchemphasis on process, while it is already a known fact that people matter more than process.Working software over comprehensive documentation: While documentation is important, buildingsoftware is the ultimate goal.
  • Customer collaboration over contract negotiation: Contracts are important, however, customercollaboration is more so, and without which nothing goes well.Responding to change over following a plan: Customers and users do not always know what they want atthe outset of a software project, therefore it is essential they remain open to change during projectexecution.Agile Methods aim at allowing organizations to deliver quickly, change quickly and change often. While, Agiletechniques vary in practice and emphasis, they share common characteristics, including iterative developmentand a focus on inter-action and communication. Maintaining regularity allows development teams adaptrapidly to changing requirements, and working in close proximity, focusing on communication, means teamscan make decisions and act on them immediately, rather than wait on correspondence. It is also important toreduce non-value adding intermediate artefacts to allow more resources to be devoted to productdevelopment for early completion.Agile movement is all about programmers that add maneuoverability to the process, so that an Agile projectcan identify and respond to changes more quickly than one using a traditional approach. Agile Methods arenot about practices used, but about recognising people to be primary drivers behind project success, coupledwith intense focus on effective maneuverability. True agility is not just a collection of practices; but also aframe of mind, and while other processes may look Agile, they do not feel Agile.Agile Introduction For Dummies – Part IIThis is a continuation of Agile Introduction For Dummies – Part I.While, having much in common e.g. what they value, Agile Methods also differ in practices they suggest, suchas, Extreme Programming, Scrum, Crystal Methods, Feature Driven Development, Lean Development, andDynamic Systems Development Methodology.EXTREME PROGRAMMINGAnd, Extreme Programming is undoubtedly the hottest Agile Method to emerge in recent years. XP owes muchof its popularity to developers disenchanted with traditional methods and looking for something new,something extreme. The 12-rules of Extreme Programming, true to the nature of the method itself, are conciseand to the point.The planning game: Each iteration begins with customers, managers, and developers fleshing out,estimating, and prioritizing requirements or ‘user stories’ for the next release, capturing it in a languagethat everyone can understand.Small releases: An initial version of the system is put into production after the first few iterations.Subsequently, working versions are put into production anywhere from every few days to every few weeks.Metaphor: Customers, managers, and developers construct a metaphor, or set of metaphors after whichto model the system. Simple design: Developers are urged to keep design as simple as possible, sayeverything once and only once.Tests: Developers write acceptance tests for their code before they write the code itself, while customerswrite functional tests for each iteration, with tests being run at the end of each iteration.Re-factoring: As developers work, the design evolves and is kept as simple as possible.Pair programming: Two developers sit together at the same machine to write the code.Continuous integration: Developers integrate new code into the system, as often as possible and allfunctional tests must be passed code integration, or else the new code is discarded.Collective ownership: The code is owned by all developers, and they may make changes anywhere in thecode at anytime they feel necessary.On-site customer: A customer works with the development team at all times to answer questions, performacceptance tests, and ensure that development is progressing as expected.SCRUMScrum, along with XP, is one of the more widely used Agile Methods, it is a process that accepts thedevelopment process is unpredictable and formalising the do what it takes mentality has found success withnumerous independent software vendors. Scrum projects are split into iterations (sprints) consisting of thefollowing:
  • 1. Pre-sprint planning: All system work is kept in ‘release backlog’. During pre-sprint planning, features andfunctionality are selected from the release backlog and placed into the ‘sprint backlog’, or a prioritizedcollection of tasks to be completed during the next sprint.2. Sprint: Upon completion of pre-sprint planning, teams are handed their sprint backlog and told to sprint toachieve their objectives. The sprint backlog is frozen and remains unchangeable for the duration of thesprint. Team members choose the tasks they want to work on and begin development. Short dailymeetings are critical to the success of Scrum. Scrum meetings are held every morning to enhancecommunication and inform customers, developers, and managers on the status of the project, identify anyproblems encountered, and keep the entire team focused on a common goal.3. Post-sprint meeting: After every sprint, a post-sprint meeting is held to analyze project progress anddemonstrate the current system.CRYSTAL METHODSCrystal methods focus on people, inter-action, community, skills, talents, and communication as first ordereffects on performance. Process remains important, but secondary. All Crystal methods begin with a core setof roles, work products, techniques, and notations, and this initial set is expanded as the team grows or themethod hardens.FEATURE DRIVEN DEVELOPMENTThe Feature Driven Development method comprises of the following core values:1. Putting in place a system for building systems is necessary for successful scaling of larger projects.2. Putting together a simple, well-defined process that works best.3. Ensuring process steps are logical.4. Get rid of ‘Process pride’ as it keeps the real work from happening.5. Good processes are moved to the background to allow team members to focus on results.6. Short, iterative, feature-driven life cycles are considered the best.And, feature driven development begins by:1. Building a features list.2. Planning feature by feature.3. Designing by feature and building by feature.LEAN DEVELOPMENT: Lean Development Agile method focuses on twelve management strategies, as follows:1. Customer satisfaction is the highest priority.2. Always provide the best value for the money.3. Success depends on active customer participation.4. Every Lean Development project is a team effort.5. Everything is changeable.6. Domain is not the point, however solutions are.7. Complete, do not construct.8. An 80% solution today, instead of a 100% solution tomorrow.9. Minimalism is essential.10. Needs determine technology.11. Product growth is feature growth, not size growth.12. Never push Lean Development beyond its limits.DYNAMIC SYSTEMS DEVELOPMENT METHODDynamic Systems Development Method (DSDM) is not so much a method as it is a framework with a six stagelife cycle.1. Pre-project: The pre-project phase establishes that the project is ready to begin, funding is available, andeverything is in place to commence a successful project.2. Feasibility study: DSDM stresses that the feasibility study should be short, no more than a few weeks. Andalong with the usual feasibility activities, this phase should determine whether DSDM is the right approachfor the project.
  • 3. Business study: The business study phase is strongly collaborative, using a series of facilitated workshopsattended by knowledgeable staff, who are quickly able to pool their know-how and gain consensusregarding development priorities. This phase results in a Business Area Definition, identifying users,markets, and business processes affected by the system.4. Functional model iteration: Functional model iteration aims to build on high-level requirements identifiedin the business study. The DSDM framework works by building a number of proto-types based on risk,evolving these prototypes into the complete system. This phase and design and build phases have acommon process:o Identify what is to be produced.o Agree how and when to do it.o Create the product.o Check it has been correctly produced (by reviewing documents, demonstrating a proto-type or testing partof the system).5. Design and build iteration: The prototypes from the functional model iteration are completed, combined,and tested and a working system delivered to users.6. Implementation: During implementation, the system is transitioned into use by creating an IncrementReview Document that discusses the state of the system. Either the system meets all requirements and isconsidered complete, or there is a missing functionality (due to omission or time concerns). If, there is stillwork to be done on the system, the functional model design, build, and implementation phases arerepeated until the system is complete.7. Post-project: This phase includes normal post-project clean-up, as well as on going maintenance. And so,Agile Methods proving popular are here to stay. As seen, there are many Agile Methods to select from, butbefore an organization selects and implements an Agile Method, it should decide whether it is ready to goagile or not.it is essential to ensure that one understands the dynamics of Agile methodology clearly. So, here we go onceagain! The past few years have seen software methodology adopting a new style and going agile! Wellknownas Agile Methods, the style is adaptive; people oriented in nature and have stirred up a whole lot ofinterest. It is also seen as an antidote to bureaucracy or licence to hack. A reaction to engineering or plandriven methodologies, agile methods are an attempt at compromising between no process and too muchprocess, providing just enough process to gain a reasonable pay-off. As well, Agile Methods tend to be:1.Adaptive rather than predictive. Engineering methods mean a planned detailed software process covering along time span and a nature that resists change. Agile methods, however, welcome it, trying to be processesthat adapt and thrive on change, even to the point of changing themselves.2. People-oriented rather thanprocess-oriented. Engineering methods work at defining processes that will work for whoever uses them.Agile methods assert a process cannot match the skills of a development team, only playing a support role indevelopment team work. Exploration of the differences in detail makes it easier to understand what adaptiveor people-centred processes are about, their benefits, drawbacks, and usefulness if used by developer orsoftware customer.PREDICTIVE Vs ADAPTIVESeparating Design and ConstructionDesign and construction, two fundamentally different activities show that difficult to predict design requiresexpensively creative people, while construction is easier to predict, and only once design is in place, can easierto predict construction begin.Unpredictability of RequirementsIn every project, developers can be heard complaining that the problem with the particular project is thatrequirements are always changing. Not surprising, as in building business software requirements, changes arethe norm. The question is what is to be done as software development is a design activity that is hard to planfor and estimate the cost for, as basic materials change rapidly and much depends on which individual peopleare involved resulting in unpredictability.
  • Is Predictability Impossible?Generally speaking, one cannot say predictability is not predictable. While, it is very desirable, however lettingit go does not mean reverting to uncontrollable chaos. All one needs is a process that gives control overunpredictability, which easily explains what adaptability is all about.Iterations – Controlling an Unpredictable ProcessSo, what is the key to an unpredictable world? Is it iterative development or frequent production of the finalsystem working version with a sub-set of the required features? While iterative development is short onfunctionality, it is otherwise faithful to the demands of the final system; hence these features should be fullyintegrated and carefully tested as the final delivery for best results. A far better process than traditionalmethods where before doing anything else, the entire process is documented, and as one knows documentscan hide all sorts of flaws, as does untested code. However, sitting in front of a system and working with it,allows these flaws to become truly apparent, both in terms of bugs and misunderstood requirements. Agile, aniterative and incremental development process is adaptive in nature and can totally deal with changes inrequired features. This means fluid long term plans, as the only stable plans are short term plans made forsingle iterations. AS well, iterative development also gives a firm foundation to each iteration, which meanslater plans can be based around it. The key question is, how long should iteration be. Different Agile methodssuggest different time frames, e.g. XP suggests iterations of one or two weeks, SCRUM suggests a month,Crystal stretches it further. However, the tendency is to make each iteration, as short as can be got away with,as this not only provides more frequent feedback, but allows you to know where you are more often.Adaptive CustomersAn adaptive process requires adaptive customers, since it gives them much more control over softwaredevelopment processes. They, not only get to check progress made at every iteration, they can also alter thedirection of software development, which often results in a much closer relationship with the softwaredevelopers, a true business partnership. The customer benefits, as there are a number of advantages to usingagile methods, such as, much more responsive software development and an usable, although minimal systemthat goes into production early on. As well, the customer can change system capabilities according to changesin business, and is also able to learn how the system is used in reality allowing for risk control, which is indeed,a key advantage of iterative development. Further, keeping iteration lengths small means variations can beseen in different ways.PUTTING PEOPLE FIRSTAnother attraction of agile methods is that they put people first, since adaptive process execution is not easytask and requires a very effective team of developers i.e. effective both in quality of the individuals, as well as,team blending. Adaptivity requires a strong team and it bodes well for agile method application to a project,since it is a well known fact that most good developers prefer an adaptive process.People Oriented Process ManagementA people oriented process, agile process acceptance requires commitment and active involvement of all theteam, as these methods like Extreme Programming (XP) requires a lot of discipline to execute, with the lessdisciplined Crystal approach, far more suited to a wider audience. As well, developers are required to be able tomake all technical decisions, with XP getting to the heart by stating that only developers are allowed toestimate how much time it will take to do the work. This shift in technical leadership requires developers andmanagement to share responsibility and an equal place in project leadership. While, management still plays arole, it also recognizes the expertise of developers.The Role of Business LeadershipHowever, technical people cannot do the whole process themselves and require guidance in terms of what abusiness needs, which highlights another important adaptive processes aspect i.e. close contact with businessexpertise.AGILE DEVELOPMENTThe term agile refers to a philosophy of software development which includes many specific approaches underits broad umbrella, approaches, such as, Extreme Programming, SCRUM, Lean Development, etc., each of themhaving their own particular approach and own ideas..
  • Extreme Programming (XP)While, during the late 1990′ s, Extreme Programming got the lion’s share of attention, in many ways it still doesand it beings with five values (Communication, Feedback, Simplicity, Courage, and Respect). It furtherelaborates these into fourteen principles, and again into twenty-four practices, placing a strong emphasis ontesting. While, all processes mention testing, not much emphasis is placed on it. However, XP believes testingis the foundation of development and has every programmer writing tests and production code,simultaneously, which are then integrated into a continuous integration and build process, yielding a highlystable platform for future development.SCRUMIn the 1980’s and 1990′ s, Scrum also developed as a highly iterative development methodology thatconcentrates on the management aspects of software development, dividing development into thirty dayiterations (called ‘sprints’) and applying closer monitoring and control, by holding daily scrum meetings. Itplaces much less emphasis on engineering practices, with many people combining its project managementapproach with extreme programming engineering practices.CRYSTALThe Crystal family of software development methods approaches tailored to different size teams approach.Despite varying, all crystal approaches share common features and have the following priorities:Safety (in project outcome, efficiency, habitability.Frequent Delivery,Reflective Improvement, andClose Communication.Lean DevelopmentLean movement pioneered at Toyota was an inspiration to many of early agilists, but one should be wary of theengineering separation between design and construction. However, there are still interesting ideas to be gotfrom the lean direction.SHOULD YOU GO AGILE?Using an agile method is not for everyone. However, these methodologies are widely applicable their useshould be seriously considered. The most common methodology of code and fix often results in chaos,showing that the discipline and lightweight agile approach found missing in heavyweight methods is the bettermethod. Start by finding projects that agile methods can be tried on, and since methods are so fundamentallypeople-oriented, it is important to start with a team receptive to being agile. As well, you will also need to findsomeone experienced in agile methods, having learnt through making mistakes. And, then you may find outabout the many advantages of going agile!SCRUM – All About Commonsense and Chaos ControlWe take up from Taking Agile Mainstream and talk exclusively about a popular agile method i.e. SCRUM.SCRUM is an agile process that has proved useful in the management and control of complex software andproduct development, and has not only been successfully used in simple projects; it has also changed the wayentire enterprises do business, increasing productivity, while reducing time. Basically, it is an iterative,incremental process for developing products or managing work, producing a potentially shippable functionalityset at the end of every iteration, SCRUM attributes are as follows:It is an agile process for managing and controlling development work.It is the outside wrap for existing engineering practices.It is an iterative, incremental team-based approach to develop systems and products for rapidly changingbusiness requirements.It effectively controls the chaos resulting from conflicting interests and needs.It is a way to improve communications and maximize co-operation.It is useful in detecting and removing any issues that get in the way of product development and delivery.It maximizes productivity.
  • It can be scaled for single projects to entire organizations and can control and organize development andimplementation for multiple inter-related products and projects with over a thousand developers andimplementers.It gives everyone a feel good feeling about their job, their contributions, firm in the belief that they havedone their very best.Whether, implemented at the beginning or middle of a project, or when a development effort is in distress,SCRUM can if there are no major changes, help teams build and deliver demonstrable product functionalitywithin thirty days.A set of inter-related practices and rules, SCRUM optimizes the development environment, reducesorganizational overhead, and closely synchronizes market requirements with iterative proto-types. UsingSCRUM, one can construct the best possible software with available resources within required release dates,delivering useful product functionality every thirty days as requirements, architecture, and design emerge,even when using unstable technologies.Over 50-organizations have used it successfully, seeing significant improvement in productivity. SCRUM, notonly improves an organisation’s existing engineering practices; it delivers product increments to users and is adevelopment framework based on values, practices, and rules, quickly implemented and repeated.SCRUM can produce financial products, Internet products, and medical products by ADM, successfully breakingthe log jam where such organizations are unable to produce shippable products, causing great concern toengineers, management, and investors. However, SCRUM broke the log jam beginning incremental productdelivery, often the first shippable products being shipped within the same quarter.A respected agile method, Net Solutions, an offshore web design and development firm is a firm believer inSCRUM, using it to great success in its many projects.All About SCRUM – Part ITo make it easirer to understand SCRUM, we once again SCRUM out, reiterating what we said in SCRUM – AllAbout Commonsense And Chaos Control.An agile method, SCRUM is an enhancement of the commonly used iterative / incremental object-orienteddevelopment cycleThe SCRUM approach used at leading edge software companies with significant success has seen severalvariants of it in play for new product development, with high performance small teams at Fuji-Xerox, Canon,Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard, where it was first noticed.A management, enhancement and maintenance methodology for an existing system or production prototype,it plans software product releases based on the following variables:Customer requirements – how the current system needs enhancing.Time pressure – what time frame is required to gain competitive advantage.Competition – what competition is up to, and what is required to best them.Quality – what the required quality is, given the above variables.Vision – changes required to fulfil system vision.Resource – availability of staff and funding.Forming part of a software enhancement project’s initial plan, these variables can change during theproject. Therefore, any successful development methodology has to take these variables and theirevolutionary nature into account. The system development process being a complicated and complex onemeans, maximum flexibility and appropriate control is necessary.SCRUM Methodology Characteristics:Planning and Closure: The first and last phases consists of well-defined processes, inputs and outputs andunderstanding well how these processes are to be carried out.Sprint: This phase comprises of many unidentified or uncontrolled processes that require external controls.Accordingly, controls including risk management, are put on each iteration of the Sprint phase to avoidchaos while maximizing flexibility.Non-linear and flexible Sprint uses explicit process knowledge if available; tacit knowledge if not and relieson trial and error to build process knowledge, using sprints to evolve the final product.
  • Closure: This phase involves remaining open to environmental complexity, including competitive, time,quality, and financial pressures, throughout. Deliverables can be changed any time during the planning andSprint phases.The deliverable is determined during the project based on the environment.So, primary SCRUM characteristics can be identified as under:PROJECT STAGES SCRUMDefined processes Planning & Closure onlyFinal product Set during projectProject cost Set during projectCompletion Date Set during projectResponsiveness to environment ThroughoutTeam flexibility creativity Unlimited during iterationsKnowledge Transfer Teamwork during projectProbability of success HighPHASESSCRUM is made up of the following groups of phases and is all about:Pre-game:Planning: Defines a new release based on current backlog, together with schedule and cost estimate whichis considered limited analysis, while new system development is considered as conceptualization andanalysis.Architecture: Comprises of architecture modification and high level design, including designingimplementation of backlog items.GameDevelopment Sprints involve multiple, iterative development sprints, or cycles, used to evolve the system,developing development new release functionality, in respect to time, requirements, quality, cost, andcompetition variables. And, interaction with these variables defines end of the phase.PostgameClosure: This phase is all about preparing for release, including final documentation, pre-release staged testing,and release.Phase StepsEach phase follows the following steps:PlanningDeveloping a comprehensive backlog list.Defining delivery date and functionality releases.Selecting release of the most appropriate for immediate development.Mapping product packets (objects) for backlog items in selected release.Defining project team(s) for building the new release.Assessing risk and appropriate risk controls.Reviewing and adjusting backlog items and packets.Validating / re-selecting development tools and infrastructure.Estimating release cost, including development, collateral material, marketing, training, and rollout.Verifying management approval and funding.Architecture / High Level Design is about:Reviewing / assigning backlog items.Identifying necessary changes backlog items implementation.Performing domain analysis for building, enhancing, or updating necessary to reflect the new systemcontext and requirements.Refining system architecture.Identifying problems / issues in developing / implementing changes.Holding design review team meetings with re-assign changes as required.
  • Development (Sprint)This phase is an iterative cycle of development work, with the management determining time, competition,quality, or functionality are met, iterations are completed and the closure takes place. Also known as Con-current Engineering, development consists of:Meeting with teams to review release plans.Distribution, review and adjustment of product conforming standards.Iterative Sprints, until product is deemed ready for distribution.A Sprint is a set of development activities conducted over a pre-defined period, usually one to four weeks, withintervals based on product complexity and risk assessment. Each Sprint consists of one or more developing,wrapping i.e. creating an executable version of changes, reviewing and adjusting.Each Sprint is followed by a review, with the whole team and product management present and participating,and can include customers, sales, marketing and others, all together determining the next review based onprogress and complexity. These Sprints usually have 1 to 4 weeks duration.ClosureWhen the management team feels time, competition, requirements, cost, and quality variables concur on anew release, the release is declared closed and entering the closure phase, which prepares the developedproduct for general release. Closure tasks include integration, system test, user documentation, trainingmaterial preparation, and marketing material preparation.That’s for the day, next time, we’ll talk about SCRUM controls, deliverables and advantages.All About SCRUM – Part IIYesterday, we talked about SCRUM characteristics, phases and game plan, taking up from where we left off,today we discuss controls, deliverables and again characteristics.SCRUM ControlsPlaying constantly at the edge of chaos, complex, unpredictable projects make it necessary to institutemanagement controls to prevent the resultant mayhem. Actually embodying general, loose controls, SCRUMmethodology is the primary control that helps construct deliverables successfully. SCRUM methodologycontrols include:Product / Project Backlog, such as, bugs, defects, customer requested enhancements, competitiveproduct functionality, competitive edge functionality, and technology upgrades.Release / Enhancement, backlog items that represent viable release based on requirements, time,quality, and competition variables.Changing packets or product components / objects to implement new release of backlog items.Packet changes that occur to implement backlog items.Technical problems that must be solved to implement a change.Risks effecting project success are continuously assessed and responses planned.Solutions are found to resolve project risks and problems, and often lead to change.Issues Overall project and project issues that are not defined in terms of packets, changes andproblems.Jointly managing product / backlog backlog, issues, risks and solutions using these controls, management andteams review, modify and reconcile them at every Sprint review meeting.DELIVERABLESAs market intelligence, customer contact and developer skills are the key deliverable determinants, thedelivered product with its content determined by environmental variables, including time, competition, cost, orfunctionality, turns out to be completely flexible, and undergoing various environmental adjustments, it isdeliverable anytime during the project.Typically, new release SCRUM Project Team is made up of a small team of full time developers, documentersand quality control staff, including marketing, sales, and customers. All, not a normal part of any traditionalrelease process, as their unnecessary interference can lead to complications. A SCRUM approach, however,welcomes such controlled involvement, as it helps to increase the appropriateness, usefulness andmarketableness of released content and its timing.
  • A metaphor for the game of Rugby, SCRUM methodology and SCRUM projects are characterised as under:Flexible deliverables with environment dictated content.Flexible schedules, since deliverables may be required sooner or later than initially planned.Multiple team project comprising of no more than six members.Frequent team progress reviews of one to four week cycles.Intra and inter-collaboration.Object Oriented, as each team addresses a set of related objects.Flexible throughout, SCRUM methodology frees developers to devise ingenious solutions that adapt well toenvironment changes, while its controls deal with product backlogs efficiently and quicklyAgile MaintenanceIntroductionThe purpose of this document is to explore suitable maintenance metrics for agile methods. Softwaremaintenance defined as ‘the process of modifying a software system or component after delivery to correctfaults, improve performance or other attributes, or adapt to a changed environment’, comprises of four kinds ofsoftware maintenance, e.g.:1. Corrective maintenance corrects faults in hardware or software.2. Adaptive maintenance makes a computer programme usable in a changed environment.3. Perfective maintenance improves the performance, maintainability, or other attributes of a computerprogramme.4. Preventative maintenance prevents problems before they occur.Agile MethodsGeneralRelatively new, light weight software development methods and processes, Agile methods attempt to reducethe bureaucracy of the software development process, so as to minimize time to market.Adaptive rather than predictive, agile methods welcome change and are people-oriented rather than process-oriented engineering methods. The Agile model is about small projects, bug reports and story cards, developerestimate, customer prioritisation of bugs, bug tracking database, QA test and writing functional acceptance andfailing unit tests, fixing unit and functional tests, regression testing before release.MaintenanceDesigned to handle changing requirements, so that the product can be maintained right from the start, Agilemaintenance methods have been successfully used. Since, maintainability is dependent on productenvironment; both product and documentation need to be maintained. And, as product structure predicts theeffectiveness of a maintenance process, it proves itself to be a far more practical method, as internal measuresare available earlier than external process measures.Maintenance process is about making product changes i.e. to codes, documents, etc. whenever necessary, withmaintenance done using agile methods validated, based on the same measures as other processes.ConclusionsBeing less dependent on documentation processes, Agile methods usually produce less documentation, makingthe development process more dynamic, with product design evolving during implementation. Therefore, it isbut natural to doubt the maintainability of products produced using Agile methods. However, it has beenproved that it is possible by offshore firms like AgileCollab and XCbia. With sufficient experience in using Agilemethods in client projects, they know how to maintain end products these methods produce.Agile TestingAs new and better software development ways are being uncovered, the following holds much value i.e.:1. Individuals and interactions over processes and tools.2. Working software over comprehensive documentation.3. Customer collaboration over contract negotiation.4. Responding to change over following a plan.Two key imperatives underlying these values are:Work Code
  • A general thumb of rule is that programmers are more comfortable getting on the computer and getting it todo something, than writing documentation. Similarly, Agile believes in the Hands-On Imperative and extends iteven to users. Why? Because, most mental activities need external resources, with different resources makingus think in different ways. And, that is why people who document or design models, think differently fromthose working on software.Because, Agile projects understand that, they deliver working software (or perhaps executable proto-types) asquickly and as frequently as practical. Development is a rapid series of functionally complete releases the usercan try out. Each release being the first chance a user’s had to think about new features, means re-work on therelease is just part of the job, not a crisis.Open CommunicationWith little or no documentation, Agile projects keep everyone in synch due to increased human contact i.e.face-to-face conversation and collaboration. XP has people programming in pairs, with most often a customerrepresentative working most days in the bullpen with the developers. Scrum holds daily stand-up meetingsthat create and preserve group understanding. Crystal, perhaps the least dogmatic process conceivable,nevertheless insists on frequent retrospectives. All these techniques tend to foster communication thatdocuments cannot replace.And, since all Agile methods want a customer to be part of the team, with a suitable customer representativeon hand, one does not require a detailed requirements document. You have a question, simply turn aroundand ask it! Worried the right question won’t be asked? Well, you can implement something and show it toyour customer for a quick reaction. Without much ado about nothing, you’ll quickly learn if you’re going offtrack.Agile TestingThese same imperatives can also underlie Agile Testing, and most obviously apply to Agile developmentprojects. However, they work, though less well on conventional projects, as well.But, first abandon the idea that communication is about one party communicating with requirements anddesign documents, while the other comes back with test plans and bug reports. You know full well thatdocuments tests are based on are flawed i.e. incomplete, incorrect, and ambiguous and to be viewed only asinteresting texts, partly fictional, often useful.Agile testing communication should be all about joining in and encouraging ongoing project conversation.Testers and developers need to sit in the same bullpen or share offices. Testers should be made helpparticular developers, rather than just testing how pieces of the product work. ‘Drop-in meetings’, short,informal discussions, etc. help in test status reports via big, public, simple-to-read charts that answer specificdevelopment questions, such as, which product parts are working well.Communicating with the customer is as important as communicating with developers, as more often than not,the customer is trying to figure out what is needed, what they want, whether they are getting it. And, they canonly do this by testing the working code and talking to the developers and testers. Testers should sit downwith them as try out the product sample, as creating tests together is an excellent way for both to learn whatmatters.Hands On helps developers improve and complete the product and value tests they can run as they develop.While, Agile Testing may not be the answer to all projects, neither are any of the Agile Methods. Acutally, nosingle approach is, but experimenting with different project styles is essential if a standardised softwaredevelopment practice is to be arrived at.Agile software development is a group of software development methods based on iterative and incrementaldevelopment, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxediterative approach, and encourages rapid and flexible response to change. It is a conceptual framework thatpromotes foreseen interactions throughout the development cycle.We are uncovering better ways of developing software by doing it and helping others do it. Through this workwe have come to value:Individuals and interactions over processes and tools
  • Working software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.The meanings of the manifesto items on the left within the agile software development context are describedbelow:Individuals and Interactions – in agile development, self-organization and motivation are important, asare interactions like co-location and pair programming.Working software – working software will be more useful and welcome than just presenting documentsto clients in meetings.Customer collaboration – requirements cannot be fully collected at the beginning of the softwaredevelopment cycle, therefore continuous customer or stakeholder involvement is very important.Responding to change – agile development is focused on quick responses to change and continuousdevelopment.[7]Twelve principles underlie the Agile Manifesto, including:[8]Customer satisfaction by rapid delivery of useful softwareWelcome changing requirements, even late in developmentWorking software is delivered frequently (weeks rather than months)Working software is the principal measure of progressSustainable development, able to maintain a constant paceClose, daily co-operation between business people and developersFace-to-face conversation is the best form of communication (co-location)Projects are built around motivated individuals, who should be trustedContinuous attention to technical excellence and good designSimplicity- The art of maximizing the amount of work not done - is essentialSelf-organizing teamsRegular adaptation to changing circumstances
  • There are many specific agile development methods. Most promote development, teamwork, collaboration,and process adaptability throughout the life-cycle of the project.Agile methods break tasks into small increments with minimal planning and do not directly involve long-termplanning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iterationinvolves a team working through a full software development cycle, including planning, requirements analysis,design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders.This minimizes overall risk and allows the project to adapt to changes quickly. Stakeholders producedocumentation as required. An iteration might not add enough functionality to warrant a market release, butthe goal is to have an available release (with minimal bugs) at the end of each iteration.[10]Multiple iterationsmight be required to release a product or new features.Team composition in an agile project is usually cross-functional and self-organizing, without consideration forany existing corporate hierarchy or the corporate roles of team members. Team members normally takeresponsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meetan iterations requirements.Agile methods emphasize face-to-face communication over written documents when the team is all in thesame location. Most agile teams work in a single open office (called a bullpen), which facilitates suchcommunication. Team size is typically small (5-9 people) to simplify team communication and teamcollaboration. Larger development efforts can be delivered by multiple teams working toward a common goalor on different parts of an effort. This might require a coordination of priorities across teams. When a teamworks in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.No matter what development disciplines are required, each agile team will contain a customer representative.This person is appointed by stakeholders to act on their behalf[11]and makes a personal commitment to beingavailable for developers to answer mid-iteration problem-domain questions. At the end of each iteration,stakeholders and the customer representative review progress and re-evaluate priorities with a view tooptimizing the return on investment (ROI) and ensuring alignment with customer needs and company goals.Most agile implementations use a routine and formal daily face-to-face communication among team members.This specifically includes the customer representative and any interested stakeholders as observers. In a briefsession, team members report to each other what they did the previous day, what they intend to do today, andwhat their roadblocks are. This face-to-face communication exposes problems as they arise.Agile development emphasizes working software as the primary measure of progress. This, combined with thepreference for face-to-face communication, produces less written documentation than other methods. Theagile method encourages stakeholders to prioritize "wants" with other iteration outcomes, based exclusively onbusiness value perceived at the beginning of the iteration (also known as value-driven).[12]Specific tools and techniques, such as continuous integration, automated or xUnit test, pair programming, test-driven development, design patterns, domain-driven design, code refactoring and other techniques are oftenused to improve quality and enhance project agility.Advantages offered by Agile Methodology:The very first advantage that the company got to see with the Agile Methodology is the saving of time andmoney. There is less documentation required though documents help to a great deal in verifying and validatingthe requirements but considering the time frame of the project, this approach leads to focus more on theapplication rather than documenting the things. Since it is iterative in its form, it tends to have a regularfeedback from the end user so that the same can be implemented as soon as possible. And because all phasesof SDLC need to be completed very quickly, there is a transparency to each individual working on the projectwith the status of each phase.Another advantage that Agile Methodology offers to other approaches available is that in case there is anyChange request or enhancements come in between any phase, it can be implemented without any budgetconstraint though there needs to be some adjustment in the already allotted time frame which will not be adifficult task for the projects following Agile tactics. Though it is useful for any Programming language orTechnology around, it is advisable to make it employ for Web 2.0 or the projects which are new in media.
  • Daily meetings and discussions for the project following Agile approach can help to determine the issues well inadvance and work on it accordingly. Quick coding and Testing makes the management aware of the gapsexisting in either requirements or technology used and can try to find the workaround for the same.Hence, with the quicker development, testing and constant feedbacks from the user, the Agile methodologybecomes the appropriate approach for the projects to be delivered in a short span of time.The Scrum methodology of agile software development marks a dramatic departure from waterfallmanagement. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrummethodology emphasizes communication and collaboration, functioning software, and the flexibility to adaptto emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.Scrum MethodologyFor many developers in the software industry, the agile methodology is nothing new. Most folks know thatagile was a direct response to the dominant project management paradigm, waterfall, and borrows manyprinciples from lean manufacturing. In 2001, as this new management paradigm began to pick up momentum,agile was formalized when 17 pioneers of the agile methodology met at the Snowbird Ski Resort in Utah andissued the Agile Manifesto. Their manifesto is now considered the foundational text for agile practices andprinciples. Most importantly, the manifesto spelled out the philosophy behind agile, which places a newemphasis on communication and collaboration; functioning software; and the flexibility to adapt to emergingbusiness realities.But for all of the strides the Agile Manifesto made in revising a philosophical approach to softwaredevelopment, it didn’t provide the concrete processes that development teams depend on when deadlines —and stakeholders — start applying pressure. As a result, when it comes to the nuts and bolts of running a teamwith agile every day, organizations turn to particular subsets of the agile methodology. These include CrystalClear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM),Scrum, and others. At my organization, we use Scrum and I’ve found it to be an incredibly effectivemanagement methodology for everyone involved, including developers and stakeholders. If you’re interestedin learning about the other agile methodologies, there are plenty of resources out there. This blog is designedto provide some essential background for those who are new to Scrum.What’s Unique about Scrum?Of all the agile methodologies, Scrum is unique because it introduced the idea of “empirical process control.”That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to planand schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which aretypically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and teammembers meet to assess the progress of a project and plan its next steps. This allows a project’s direction to beadjusted or reoriented based on completed work, not speculation or predictions.Philosophically, this emphasis on an ongoing assessment of completed work is largely responsible for itspopularity with managers and developers alike. But what allows the Scrum methodology to really work is a setof roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makesit an appealing option, the stability of its practices give teams something to lean on when development getschaotic.The Roles of ScrumScrum has three fundamental roles: Product Owner, ScrumMaster, and team member.Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product tothe development team. He or she must also represent the customer’s interests through requirements andprioritization. Because the Product Owner has the most authority of the three roles, it’s also the role withthe most responsibility. In other words, the Product Owner is the single individual who must face the musicwhen a project goes awry.The tension between authority and responsibility means that it’s hard for Product Owners to strike the rightbalance of involvement. Because Scrum values self-organization among teams, a Product Owner must fightthe urge to micro-manage. At the same time, Product Owners must be available to answer questions fromthe team.
  • ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. TheScrumMaster does not manage the team. Instead, he or she works to remove any impediments that areobstructing the team from achieving its sprint goals. In short, this role helps the team remain creative andproductive, while making sure its successes are visible to the Product Owner. The ScrumMaster also worksto advise the Product Owner about how to maximize ROI for the team.Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teamsconsist of seven cross-functional members, plus or minus two individuals. For software projects, a typicalteam includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UIdesigners. Each sprint, the team is responsible for determining how it will accomplish the work to becompleted. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, thatfreedom is accompanied by a responsibility to meet the goals of the sprint.Data GatheringBusiness Analysis Methods and TechniquesThere are many different approaches that can be used to gather information about a business. They includethe following:1. Review business plans, existing business models and other documentation2. Interview subject area experts3. Conduct fact-finding meetings4. Analyze application systems, forms, artifacts, reports, etc.The business analyst should use one-on-one interviews early in the business analysis project to gage thestrengths and weaknesses of potential project participants and to obtain basic information about thebusiness. Large meetings are not a good use of time for data gathering. Facilitated work sessions are a goodmechanism for validating and refining “draft” requirements and also to prioritize final business requirements.Group dynamics can generate even better ideas. The business analyst should ensure that all business analysismeetings are well planned and productive. It is important that the meeting goals and objectives are clear, thatan agenda is prepared and distributed prior to the meeting, that the meeting room is suitably set up.Following the meeting, meeting notes or minutes should be produced and are distributed to participants andother stakeholders. The meeting notes should summarize the key topics covered, the important decisionsmade and any "action items" that resulted from the meeting. If a scribe it to be used for note taking, he/shemust be knowledgeable with the subject matter. Where possible, the business analyst should ideally, take themeeting notes and prepare the minutes. This helps ensure that all important points are captured and clearlystated. There is a significant amount of preparatory and follow-up work required for any formal meeting. Thiswork takes time and effort and needs to be factored into the project plan. The role of the business analyst is tounderstand the business goals, objectives and strategies of an organization and to use that knowledge to helpdesign and implement new business systems that align with the business vision. Using a variety ofcommunication skills (e.g. interviews, meetings, and facilitated sessions) and by analyzing business processes,data and systems, the business analyst develops a series of business and system “models” that are used by thebusiness to better understand itself and to plan and design a future state business model. The business modelsthat are produced by a business analyst describes the business from very different but related perspectives:1. Planning Perspective – depicts an “executive summary” of the business vision2. Business Perspective – depicts a detailed, conceptual understanding of the business3. Design Perspective – depicts a non-technical design for the future state business model4. Builder Perspective – depicts a technical solution for achieving that visionAlthough, in general, the business analyst takes a “top-down” approach that helps ensure that he/she is inalignment with the business vision, goals and objectives, there is sometimes a need for “bottom-up” analysis tobetter understand problems areas and areas of particular complexity.A "business analyst" is a role that can mean different things to different people. In some organizations, thebusiness analyst plays a narrow, technically oriented role and has very little "business" knowledge. In otherorganizations, business analysts have an intimate understanding of the business but a limited knowledge of
  • computer systems and application system architectures. The business analyst of greatest value to anorganization, however, is a generalist who can function competently in many diverse roles. Such individualstypically have a broad educational background, a diverse skill set and a wide range of work experience indifferent jobs and industries. They are able to see “the big picture” as well as the technological andarchitectural barriers and enablers. Business analysts must be comfortable working with "specialists" in diverseroles and to understand the business from many diverse perspectives.avoid falling prey to four common misconceptions that limit effectiveness of many business analysts (BAs).First, rather than merely passively gathering requirements, an effective BA actively gathers data and thenanalyzes the data to discover the requirements.Second, much of the data gathering actually involves digging—way beyond mere gathering--not only to find thefrequently hidden data but more importantly to find out what data you need to collect. Far more commonlythan recognized, BAs often unwittingly head down wrong paths gathering wrong data due to overly relying on(managements) inadvertently incorrect assumptions about what the project requires.Third, users are only one of many sources of requirements. All users are customers, which can be internal orexternal; and there can be customers who are not users. All customers are stakeholders, and there can bestakeholders who are not customers. Contrary to another common misconception, users are not different fromstakeholders-instead users are one of many types of stakeholders. Stakeholders, the all-inclusive category, arethe source of requirements. You need to identify which stakeholders are likely to have data you need and thendig it out. The most fundamental method for gathering data to aid in discovering requirements involvesindividually interviewing the various stakeholders. Techniques such as requirements workshops (also calledJoint Application Development—or Design—JAD) and focus groups gather data from groups of stakeholders,which can be efficient to an extent but dont provide sufficient data to be relied upon as the only datagathering technique. Additional data can be gathered by reviewing relevant documents and researchingliterature, observing operations, and learning to do the work involved.Fourth, theres one additional frequently-overlooked step between requirements and design of the softwarethat will be developed. Software designs are not based directly on real, business requirements. Instead,software designs are based on creating a product that will satisfy the real business requirements. Therefore,after discovering the real, business requirements, the BA must define a product that presumably will meetthem; and its that product that software is designed and developed for. This critical but frequentlymisunderstood distinction is made more confusing because what BAs and others commonly refer to as"requirements" actually are requirements of the product, system, or software they intend to create. For furtherProjectManagerSystemsAnalystBusinessPlannerData AnalystFinancialAnalystProcessAnalystApplicationArchitectTechnologyArchitectApplicationDesignerSubject AreaExpertOrganizationAnalystBusiness Analyst Skills
  • description of the difference between real, business requirements and product/system/software requirements,see " Problem Pyramid discovering REAL software requirements."Prototyping, visualization, user interface mock ups, walkthroughs, and most use cases are often touted asrequirements definition techniques but in fact all are ways of examining the prospective products ability tosatisfy the (too-often-presumed rather than defined adequately) real, business requirements. Such methodsindeed are helpful in the development process but do little to help discover the real business requirements theproduct must satisfy.IntroductionA Standish CHAOS Chronicles report states that only 28% of software projects were expected to finish on timeand on budget. Only 52% of completed projects met their proposed functionality. Based on a study of morethan 13,000 U.S. projects, the Standish Group reported that successful projects made up “just over a third or 34percent of all projects….” Estimates of the lost value for these projects in 2002 was $38 billion, with another$17 billion in cost overruns, for a total project waste of $55 billion against $255 billion total in project spending.Unfortunately, poor project performance has become a way of life. Failure statistics like those above haveceased to even shock us. Most organizations have come to accept project failure—along with a loss of money,time and functionality—as a given. With constantly improving technology, exponential resources and aconcrete project management methodology, how does this continue to happen? It’s time for our questioningto go beyond, “Are projects failing?” Now it’s time to ask why.Why Are Projects Failing?The data in Figure 1 was collected in an online poll of 2,000 business professionals. It asked the question,“What are the key challenges in translating user needs into systems specifications for mission critical projects?”If a project fails, it’s often assumed to be the project manager’s fault. More and more, however, research isshowing that this is not the case. In the survey mentioned on page 4, an overwhelming 50% of respondentscited poor requirements definition as their biggest challenge, thus raising a new question. When projects fail,most organizations are quick to blame the project manager. But what about the business analysts? What roledo they play? More importantly, what role should they play?
  • The Role of the Business AnalystIn many organizations, the competencies necessary for a successful business analyst simply haven’t beendifferentiated from those of a subject matter expert (SME) or a project manager. And yet each of these threepositions have very distinct responsibilities during the project life cycle. It’s no wonder so many projects arefailing. How can a business analyst—or anyone in any job—be expected to perform at a top level when his orher required competencies have not been clearly defined?The answer is simple: They can’t. Yet organizations worldwide are operating without defined competencies fortheir business analysts. For many organizations, in fact, even the title of the person performing “businessanalysis duties” can vary widely. According to a recent poll, there are several titles used for those performingthe “business analyst” role, as illustrated in Figure 2.We know what business analysts do—essentially. At the most basic level, a business analyst acts as a translatoror liaison between the customer or user and the IT person or group attempting to meet this user’s needs. Butwhat about the specifics? According to the International Institute of Business Analysis, business analysts are“responsible for identifying the business needs of their clients and stakeholders, to determine solutions tobusiness problems.” As a translator, he or she “elicits, analyzes, validates and documents business,organizational and/ or operational requirements”. Additionally, what processes are business analysts using toelicit, analyze, validate and document these requirements? Most organizations do not have set processes inplace. And if they do, one needs to ask, “What competencies does a business analyst need to accomplish thesetasks successfully?”Defining CompetenciesThere are generally two distinct types of competencies. Both categories should describe employees’behaviors—descriptions of how they might be expected to perform given a particular task at hand. First, thereare those competencies that address organizational success. Such competencies are common across many jobsand demonstrate the key behaviors required for success regardless of position within the organization. Forexample, leadership, communication skills, vision, innovation and collaboration might be consideredorganizational competencies. All employees, regardless of function or role, must be accomplished in theseareas in order to contribute to the success of the overall organization.
  • Second, there are those competencies that address success for a certain job. Functional competencies refer toan individual’s ability to perform a given set of activities based on their particular job. These functionalcompetencies are specific and necessary to an individual’s success. For instance, functional competencies for anetwork administrator might include the ability to install a new server or troubleshoot network performanceissues. These competencies are required for successful performance.Setting Concrete CompetenciesTo combat this substantial issue of the undefined business analysis role, eight essential competencies havebeen determined. Additionally, to aid in the organizational implementation of these competencies, this paperintroduces the “Business Analyst Competency Model” as illustrated in Figure 3. This model, which breaks downeach competency as conceptual, logical, physical or contextual, takes into consideration all tasks and activitiesperformed by a business analyst. The model takes a fairly traditional approach, basing divisions on researchconducted in countless organizations. The competency model is a practical and straightforward aid to applysolid guidelines for the business analysts in your organization—at all levels. The model is, fundamentally, adescription of a competent business analyst. By definition, a competency is made up of three components:knowledge, skill and ability. Knowledge considers “what is being measured?” Skill looks at “how is it done?”Ability, lastly, examines “to what degree can it be done?” Each of the competencies outlined in this paper isbroken down into these three components.Clearly there are different responsibilities during each stage of a business analyst’s career. For each of the eightcompetencies, this paper designates the specific tasks a competent business analyst should perform at thesenior, intermediate and junior levels. For the purpose of this paper, we have defined typical levels of ability asfollows: Additionally, it is important to take into consideration the level of ability to which each businessanalyst performs. Very often it is assumed that all business analysts—junior, intermediate or senior—should beperforming at 100 percent accuracy. Very rarely is this the case.
  • To combat this misconception, we have included an “ability” column for each competency. This simply sets aguideline for those in each role to strive for in terms of accuracy.Competency #1: Eliciting RequirementsOn the most basic level, we know that a big part of a business analyst’s job is to gather and document userrequirements. Requirements can be conditions, functionality, products or services for internal or external use.They are needed by a user or client to solve a business problem or achieve a business activity, and they are tiedto the needs of business, rather than the constraints imposed by technology. This means that the businessanalyst’s job has more to do with identifying the desired results than the actions or resources required to reachthese results—that’s someone else’s job. The purpose of gathering requirements is to provide anunderstanding of the problem or opportunity before trying to propose the solution. The techniques necessaryto capture requirements are often referred to as elicitation. Depending on the level of competency anindividual demonstrates, the types of techniques should be considered carefully when applying them to anygiven situation. Table 2 illustrates the ideal knowledge, skill and ability levels of business analysts for thisparticular competency.
  • Competency #2: Creating the Business - Requirements DocumentA business requirements document (BRD) is an exhaustive written study of all facets of regulatory, business,user, functional or non-functional requirements and provides insight into both the as-is and to-be states of thebusiness area. It is a detailed profile of primary and secondary user communities. It comes directly from therequirements the business analyst has already gathered. It only makes sense, then, that the BRD should bewritten by the business analyst. After the document is completed, the business analyst and the client or usermeet for a formal review and for approval of the BRD. The document is then shared with the rest of thedevelopment team, including the project manager. In creating the BRD, it is very likely that a senior businessanalyst would be largely responsible for defining not only the various sources for requirements, but also theplacement and relevancy of these requirements. For example, senior business analysts may identify such itemsas the project charter and vision, business case, requirements work plan, vendor request documents and,potentially, business contract documents. They may also work with the project manager to define the projectand product scope. Any requested changes to any area of the BRD—before or after work has begun—must becarefully reviewed by the senior business analyst. An intermediate business analyst, however, might work withthe client or user, discussing changes necessary to gain approval. When it comes to the BRD, the juniorbusiness analyst is expected to assist the intermediate and senior business analysts with the organization andthe actual documentation.Competency #3: Structured AnalysisStructured analysis refers to the art of modeling. In business analysis, modeling is used to support and enhancetext-based requirements, help identify and validate requirements, document and communicate requirementsand, finally, organize information into coherent ideas. The most common types of business analysis modelsinclude business models, process models, data models and workflow models. When it comes to the modelingcompetency, junior business analysts should be able to easily identify a variety of modeling techniques. Theyshould also be able to create simple models based on information given to them by their intermediate or senior
  • counterparts. For example, a junior business analyst might be expected to create such diagrams asorganizational charts or business interaction models. An intermediate business analyst may begin to developsuch models as entity relationship diagrams, functional decomposition diagrams and the ever popular use casemodels. The senior business analyst takes the models from the junior and intermediate business analysts andexamines the as-is state in order to create the ideal to-be state. When looking at models created by theintermediate business analyst, the senior team member is looking to find problems and opportunities that willchange the process or the deliverable.Competency #4: Object-Oriented AnalysisWithin a business context, an object model is an abstract representation of the process and data requirementsof a system, based on decomposing the system into units called objects. Each object encompasses the data andoperational characteristics of one business item. Object-oriented analysis is particularly important to businessanalysts as a business planning tool to depict the hierarchy of business functions, processes and sub-processeswithin an organization. Generally speaking, individuals embarking on the quest to master object-orientedanalysis should be competent in structured analysis. Object-oriented analysis requires a clear understanding ofboth the process and data modeling techniques, including functional decomposition. It’s likely that juniorbusiness analysts may get involved in the functional decomposition of the as-is state of a project, including,perhaps, forming a simple model of this state. From this model, an intermediate business analyst may considerdeveloping activity diagrams to further clarify requirements. With diagrams in hand, a senior business analyst islikely to begin designing the to-be state during one-on-one interviews, group interviews and thedocumentation process. Essentially, each of these processes involved in object-oriented modeling ensures thatthe requirements are properly communicated to the developers and administrators.
  • Competency #5: TestingWhen it comes to testing in business analysis, the first thing to understand is that the term applies to severaldifferent levels of work. First, business analysts are looking to test the products to validate whether therequirements have been met. They develop test scripts, test plans and test scenarios based on the as-is state aswell as the to-be models. Testing requirements should be done in iterative stages to ensure that, by followingthe requirements, the desired deliverables will be met. The second level of testing is more familiar. This istesting the functionality of the physical product—testing lines of code and user testing of graphical appeal,speed and functionality. Black box testing and glassbox testing fall into this category. As with the first type oftesting, this testing also makes sure we reach the desired state, but it is based on user acceptance. In a testingsituation, junior business analysts may not always be heavily involved. Their role is often to assist. Theintermediate business analyst might take on the role of designing test cases and reviewing some or all of theresults from these scenarios. The senior business analyst acts as an overseer in the testing phase. His or her jobis to see the project to fruition and manage quality.
  • Competency #6: End-User SupportIt’s a common misconception among project teams that the project ends when the deliverable is completed.Not so. Business analysts, specifically, should be aware that end-user support after the product is delivered isalmost as important. It should be stated, too, that the role of the business analyst is not to act on behalf of thetraining team, but to complement the training team’s efforts with their knowledge of the businessrequirements. Much of the documentation created in the process of identifying the deliverables is invaluable tothe development of training needs and end user support, including user manuals and reference materials.Ideally, a junior business analyst may work with end-users in the post-deployment phase to clarify any high-level questions that need to be addressed. An intermediate business analyst would work closely with trainingmanagers and facilitators to define requirements to deliver the training supporting the business needs. A seniorbusiness analyst would assess and evaluate all feedback from his or her team members, those individualsinvolved in the deployment of the product and any pilot or “test” groups to ensure that the requirementsnecessary to correct any issues are addressed in future releases, iterations or versions of the product.
  • Competency #7: IT FluencyHow much knowledge is enough for a business analyst? With regards to IT knowledge, this has been a long-standing debate. In reality, the answer is as varied as it would be for any other professional. The amount ofnecessary IT knowledge is truly based on the project. The IT background for a competent business analystdepends entirely on the environment and possibly the industry vertical he or she works within. It’s important toremember that IT fluency is just one of eight competencies that a successful business analyst must have. Also,just because an individual is fluent in a given technology does not automatically qualify him or her as a businessanalyst. This is a mistake many organizations are guilty of making. In theory, a great business analyst shouldhave the wherewithal to understand which resources would be appropriate to help define and validate bothrequirements and specifications within a given project and product scope. In examining the different stages ofa business analyst, a person at the junior level would need to have a clear understanding of the IT products andtools necessary for the business to function. An intermediate business analyst may understandinterconnectivity and relationships between the tools, and perhaps, system architecture and informationarchitecture. A senior business analyst will demonstrate his or her IT fluency across an industry vertical. He orshe may also have a very clear understanding of how different IT products are related, interface with andconnect to each other, as well as the positive or negative impact they may have in a given situation.Competency #8: Business Process Re-EngineeringConsidered the “big-picture thinking” of business analysis, business process re-engineering (BPR) is a rapidlygrowing part of business analysis. In fact, lately many companies have been grouping business analysts aroundthis specialty and developing teams of process analysts. This is the phase in which business analysts seek outboth problems and opportunities. BPR uses a variety of modeling techniques in order to look at the biggerpicture, but still think tactically. BPR is a competency in which all levels of business analysts must be highlyskilled. The junior business analyst’s responsibility is often to identify, using various modeling techniques,possible areas of improvement. The intermediate business analyst might have the job of walking the client or
  • user through each step of the process, examining individual tasks that could potentially be improved. Thesenior business analyst begins to actually make suggestions for improvements.Developing the Eight Competencies to Improve Your OrganizationIn the beginning of this paper (Figure 1), we discussed the key challenges organizations face in translating userneeds into systems specifications. Any of these challenges can ultimately lead to project failure. After outliningthe eight critical business analysis competencies, however, we can begin to see how these challenges can becombated. As your business analysts become more and more capable in well-defined roles, they are betterarmed to overcome such recurring challenges. For instance, poor requirements (50%) were cited as the biggestchallenge to organizations. As business analysts at the junior, intermediate and senior levels begin tounderstand their role in the elicitation process, the work performed is inevitably more centered and accurate.Inadequate risk management (17%) was cited as the second most-common challenge. Several competencies—creating the BRD, object-oriented analysis and structured analysis—will help business analysts perform moreeffective risk management. IT fluency and business-process re-engineering can help improved project scopecontrol, which was cited by 15% of respondents as a key challenge. The challenges associated withcommunication problems (14%) and the lack of qualified resources (3%) will also lessen once the businessanalysts in your organization are better versed in the standards and best practices of their specific jobfunctions. Ultimately, all of these challenges become, simply, daily tasks that your business analysts areprepared to handle as experts in their field. Though comprehensive, the competency model alone is notenough to improve business analysis practices within your organization. Implementing these competencies asorganizational guidelines is essential. Once this is accomplished, organizations must then develop thecompetencies in their individual business analysts. The first step in ensuring that your organization’s businessanalysts have the knowledge, skills and abilities necessary for success is to develop job functions and detaileddescriptions based on this competency model. After these have been determined and approved, it’s essentialthat organizations “take inventory,” so to speak, of the competencies their business analysts already possess.There are specific assessments to test these competencies. Such tools will establish the knowledge level ofindividuals in each competency area and of the team as a whole. If knowledge isn’t baselined, improvementwill be virtually impossible to track. The competency model is an ideal reference point for such an assessment.
  • After you have established the business analysis knowledge and ability levels within your organization, youmust implement training to improve any competencies that may be lacking. The competency model can alsoserve as a validation tool for such training. It can be used to ensure that the performance improvementprogram is comprehensive, and that no behaviors or competencies are missed. However, until business analysiscompetencies are dramatically improved within organizations, we will continue to see the same problemswe’ve grown so accustomed to seeing. Keeping in mind the eight competencies, as well as all of the people,processes, tools and technology available to your organization, will put you on the path to better businessanalysis and, ultimately, more successful projects.