• Like

Introduction to Agile Development

  • 507 views
Uploaded on

Welcome to Whizlabs’ PMI-ACP® Certification Self Study Training. In this chapter we are covering the second module of PMI-ACP® e-Book which deals with Agile Movement, variants and other Agile related …

Welcome to Whizlabs’ PMI-ACP® Certification Self Study Training. In this chapter we are covering the second module of PMI-ACP® e-Book which deals with Agile Movement, variants and other Agile related concepts. Our Self Study Training comprises of downloadable eBook, practice tests, module end tests, Tips & Tricks and study notes. To know more please visit http://www.whizlabs.com/pmi-agile-certification-professional/acp-self-study-training.html

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
507
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
17
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. www.whizlabs.com | ©Copyright 2013 Page 1 Module 2: Introduction to Agile Development
  • 2. www.whizlabs.com | ©Copyright 2013 Page 2 Table of Contents Module 2: Introduction to Agile Development.............................................................................................3 Agile Movement........................................................................................................................................3 Agile variants.............................................................................................................................................4 Iterative and incremental .........................................................................................................................5 Agility ........................................................................................................................................................6 Agile Manifesto.........................................................................................................................................7 The Twelve Principles of Agile Manifesto.............................................................................................8 Declaration of Independence .............................................................................................................12 Agile project management vs. Tradition project management..............................................................13 Myths and concerns about Agile approaches.........................................................................................15 When to use and when not to use agile.................................................................................................16 Module Revision .....................................................................................................................................17 Case Study...........................................................................................................................................17
  • 3. www.whizlabs.com | ©Copyright 2013 Page 3 Module 2: Introduction to Agile Development Agile Movement Traditional software development methodologies believe in up front planning. In waterfall model, we first gather all the requirements and then move to design and build phase. Some of the key assumptions in traditional approaches are:  Project management is a predictable & repeatable process.  We can accurately estimate the efforts and resources requirement well in advance.  We can actually create a plan up front that would almost remain intact in the course of project.  Requirements can be completely specified in the beginning of project.  Users can explain the requirements and know exactly what they need, without seeing a working product  Requirements will hardly change This all worked well in simple projects wherein uncertainties were limited. However, these assumptions were heavily challenged in complex and innovative projects. Over the years, in spite of heavy process centric methodologies, large number of IT project failed. In response to these challenges & failures, agile methods were developed, which were largely based on empirical process control i.e. an adaptive rather than prescriptive development approach. Iterative development and continuous delivery of working products or prototypes (incremental) was the key change.
  • 4. www.whizlabs.com | ©Copyright 2013 Page 4 Agile variants In 90’s number of agile methodologies became popular and successful. Some of the examples are:  Extreme Programming (XP)  SCRUM  Lean Software development – Inspired from Lean manufacturing concepts.  DSDM  Feature Driven Development  Crystal Methods  Unified Process (UP) XP, SCRUM and Lean are considered as lightweight agile approaches and that’s where ACP exam seem to have most focus. Some of the differences between these frameworks are quite minor. For e.g. SCRUM calls iteration as sprint while others prefer to use word iteration itself. SCRUM typically recommends 30 days iteration while XP prefer to 1-2 week long iterations. In overall agile framework, these variants complement each other. While most of the basic principles remain same, each framework offers some unique good practices for e.g. XP is quite famous for its engineering practices such as pair programming, test driven development etc. Lean is quite famous for managing wastes. Towards the end (Module 13), we will discuss more about these various variants. More specifically, we will cover XP, SCRUM and Lean as ACP exam seem to focus more on these three.
  • 5. www.whizlabs.com | ©Copyright 2013 Page 5 Iterative and incremental Most of the agile methodologies such as scrum and XP are iterative and incremental. Let’s understand what iterative and incremental mean as we will be using these terms very often. Iterative process is all about successive refinements. For e.g. if we need to draw a painting, we will first create a base, then will draw the picture, after that we will color the picture. In the end, we will make minor tweaks (finishing touch) to make it look nice. This is a kind of iterative process as there are successive refinements. On the other hand, incremental process is about building and delivering in pieces. In above example, the painting might be delivered in few parts. Each part will go through complete process i.e. base creation, drawing, coloring, refinements. See below diagrams to understand more:
  • 6. www.whizlabs.com | ©Copyright 2013 Page 6 Agility As defined by John Highsmith, one of the originator of Agile Methods. "Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.” “Agility is the ability to balance flexibility and stability." While, responding to change guards against competitive thrusts, creating change require innovation: Developing new products or enhance existing, creating new sales channels and improving product development time. However, when we are creating something innovative or complex, we can’t fully anticipate. That’s why process centric metrologies often fail in such cases. Agility doesn’t mean lack of structure. It’s a just a right balance between order and chaos; flexibility and stability.
  • 7. www.whizlabs.com | ©Copyright 2013 Page 7 Agile Manifesto In 2001, representatives from various agile methodologies came together and formed Agile Alliance. They authored Agile Manifesto and Agile Principles, keeping software development in mind. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Top Tip – Remember all four values and understand meaning of these. It’s quite likely to have few questions around these in ACP exam A deep understanding of each and every word of Agile Manifesto is not only required for ACP exam but also required for real life implementation of agile concepts. A common misconception is that agile philosophy is against plan, processes and documentation. However, if you read carefully, it only tells what should be focused more. Let’s have a close look at each statement. a) Individual and Interactions over processes and tools  Processes are tools are certainly important but its individuals who choose, what would be the appropriate processes & tools for given project.  It’s the individuals who follow these processes and make right use of these tools. If processes are too heavy to follow or individuals are not engaged enough to follow these, processes would simply fail to work.  Without much of processes and tools, there is a good possibility that a group of skilled and motivated individuals will deliver the successful project. However, vice-versa is not true. For e.g. we may have a robust review process but imagine what would happen to the quality, if one novice is reviewing the work of other novice. Or, reviewer is not motivated to do a critical review and doing it casually just for the sake of process compliance. b) Working software over comprehensive documentation  Software without good documentation is problematic from maintenance & support point of view. However, comprehensive documentation without software has no business value. [Given a choice, would you pick a primitive video game or a detailed user guide for an advance video game?]  User would be in much better position to provide feedback on working software even with less number of features, than with large document detailing all the features & usage scenarios.  Documentation is to help driving common understanding and assist in the process of developing working software. However, primary goal is still to develop working software.
  • 8. www.whizlabs.com | ©Copyright 2013 Page 8 c) Customer Collaboration over contract negotiation  Our sole purpose of doing the project is so that customer can realize business value. Only customer can tell what they want then isn’t it fair to listen to them and be flexible about their needs [How would you feel if you have ordered furniture but then realized that size isn’t good as per your room measurements and shop keeper doesn’t let you modify the order].  It’s difficult for customer to define an upfront and unchanging view of what should be built. It’s likely that customer won’t get it right the first time. It’s likely that they would change their mind.  Successful developers work closely with their customers, they invest the effort to discover what their customers need, and they educate their customers along the way. d) Responding to change over following a plan  Changes can come from various factors. Customer priorities may change or customer may just get a better idea to improve ROI. Market/Business may change. Technology can change. It could just be a result of improved understanding of problem domain.  Rather than sticking to the original plan, we should respond to the inevitable changes. Moreover, we should be flexible about changes, which help in reducing the risk and maximizing ROI.  This doesn’t mean we should not have a plan. Instead of suppressing changes and sticking to a static plan, we need to acknowledge that things will change. We need to accommodate the changes, which help in meeting key project & business objectives. The Twelve Principles of Agile Manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face‐to‐face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self‐organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly Top Tip – Remember all twelve principles and more importantly the intent behind writing these as explained below. It’s quite likely to have few questions around these in ACP exam
  • 9. www.whizlabs.com | ©Copyright 2013 Page 9 Let’s understand more about these 12 principles a) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.  Many people within IT seem to do the project keeping the technology management layer in mind rather than end customer. This principle reminds that most important sign for a successful project is customer satisfaction.  Valuable software here means working product or prototype - something that customer can easily understand & appreciate. Deliverables such as design document or software code have no meaning for customer. The focus is on the end goal, which is working product.  Early and continuous delivery of valuable software not only gives confidence to the customer but also provides opportunity to receive customer feedback so that we build what is right for the customer rather than what was specified initially. b) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.  Let’s take an example. We are building a product and then realize competitors have launched a product with similar features. Unless we add some other exciting features in the product, launching that product would be just waste of time and money.  Traditional change management processes were designed to prevent/reduce scope creep. But nowadays these processes are generally so rigid that these actually tend to suppress changes.  Agile processes acknowledge the fact that change will happen and provides an effective way to deal with them by using a value driven iterative development approach. c) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.  If you read carefully, it doesn’t prescribe any specific duration for iteration. It just state the preference for more frequent delivery of working software so that there are more opportunities for stakeholders to provide feedback, which reduces the risk of going too far down the wrong track.  More frequent delivery improves customer’s confidence. Often in a demo meeting, team learns of new requirements or changes in business priorities, which are important for improved ROI. d) Business people and developers must work together daily throughout the project.  When team works closing with business, team understands the business in a way that is far beyond the typical requirement collection mechanisms. Scope creep due to missing requirements and incorrect interpretation of requirement reduces drastically.  Frequent demos to business people are another example of close working together.  In some cases it’s not really feasible to have business people literally available daily. But agile methods try to get as close collaboration as possible.  Some teams use an experienced business domain expert as “proxy customer”. While this can help development but this should not be a replacement of customer interaction.
  • 10. www.whizlabs.com | ©Copyright 2013 Page 10 e) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.  There are numerous industry examples wherein a team of skilled and motivated individuals could achieve the goal while a much larger team failed to achieve similar goal.  Too many organizations just hire hordes of people and think that these would make build successful software with help of heavy process framework. This doesn't seem to work all that well in practice.  While we don’t have the choice to choose our dream team and most skilled people. At least we can do our bits to motivate them to get best out of them.  A team of motivated individuals doesn’t require micro-management and project manager can focus on removing impediments rather than doing day to day task management.  Agile teams, realize that you need to build teams from people who are willing to work together collaboratively and learn from each other. In these kinds of teams, continuous improvement never stops. f) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.  Exchange of information through e-mails or by sharing information is slow and effort consuming mechanism. Still the interpretation may go wrong. A quick talk over the phone can achieve results much faster and better.  Face to face talk is even better as along with information, emotions, body language can also be conveyed, which not only makes the information exchange even quicker & better but also helps in reducing conflicts.  In face to face conversation, you can quickly draw diagrams and have wide range of techniques to express complex ideas. g) Working software is the primary measure of progress. Traditional approaches use documents or other forms of intermediate deliverables as measure of progress. There are following issues with that:-  Focus gets shifted from working software which is ultimate goal, to these intermediate deliverables.  We might show percentage completion or Earned value by measuring progress in terms of intermediate deliverables but until we show the working software to business and confirm that it meets the customer requirement, there are chances that we are just going on wrong track.  What if project has to be stopped in the middle, we might have a high earned value and x% of work completion but without any working product, is there any value for customer? In case of working software, customer may still make some use of features delivered till then.
  • 11. www.whizlabs.com | ©Copyright 2013 Page 11 h) Agile processes promote sustainable development.  Agile believes in a sustainable work pace rather working long hours just before key milestones. XP recommends 40-hours work week.  A sustainable work pace is better for team members for their work-life balance. It also benefits the business because un-necessary stretch reduces the motivation levels and increases the risk of people resigning. Hiring and training the people is a very costly affair.  8 hours work with full focus and attention is better than 12 hours of mediocre work. There are chances of poor quality and rework later on, which will actually reduce the overall output. i) Continuous attention to technical excellence and good design enhances agility.  It's much easier to understand, maintain, and evolve high-quality source code and a good scalable design, than it is to work with rigid design & low-quality code.  Agilists recommend a range of design & code development principles & practices for technical excellence. j) Simplicity – the art of maximizing the amount of work not done – is essential.  Agile developers ask themselves “what is the simplest thing that could possibly work”.  Rather than anticipating changes and adding numerous additional features or extensibility hooks, agile developers create a simple and clean design. Un-intuitively, this results in designs that are ready for any change, anticipated or not.  Agile developers have strong focus on automation and reusability. k) The best architectures, requirements, and designs emerge from self-organizing teams.  Essentially it is saying getting the best from the people. A self organizing team is naturally motivated to continuously find better solutions and improve ways of working.  We may get number of ideas from experts outside the team but unless ideas are well understood and well implemented by the team, purpose is defeated. Team is closed to technical details and can choose which idea would actually work in project. l) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.  Gathering lesson learnt at the end of project might add to organization’s lesson learnt / best practices repository but it’s too late for the project. In fact, these lessons learnt are rarely being used much in practice – one because every project is different and second because people tend to learn more from their own experiences than someone else’s experiences.  Agile projects often conducts sessions (called as retrospectives), typically after every iteration to learn from past and adapt.  The beauty of iterative development is there are ample opportunities to learn from previous experiences and continuously improve. The key is to have that focus on reflection and taking concrete actions from learning. The Agile Manifesto provides a philosophical foundation for effective software development. This doesn’t prescribe any particular methodology.
  • 12. www.whizlabs.com | ©Copyright 2013 Page 12 Declaration of Independence In 2005, a group headed by Alistair Cockburn and Jim Highsmith wrote an addendum of project management principles, the Declaration of Interdependence, to guide software project management according to agile development methods. The principles of declaration of independence are:  Increase return on investment by making continuous flow of value our focus.  Deliver reliable results by engaging customers in frequent interactions and shared ownership.  Expect uncertainty and manage for it through iterations, anticipation and adaptation.  Unleash creativity and innovation by recognizing that individuals are the ultimate source of value and creating an environment where they can make a difference.  Boost performance through group accountability for results and shared responsibility for team effectiveness.  Improve effectiveness and reliability through situationally specific strategies, processes and practices. Key Points To Remember - Agile manifesto was written keeping software developers in mind while declaration of independence was written keeping project lead/managers in mind. - Agile movement has greater influence on software as many of the agile methodologies were invented by software professionals. However, most of the concepts are so generic that these can be used across industries. - While Agile manifesto is written keeping software developers in mind, this can very well be used for other industries. To make it clearer, some people prefer to replace word ‘software’ with ‘product’. - There are many generated accepted standard practices, which people see as part of integral part of agile for e.g. user story. But the fact is as long as basic principles are being followed, the methodology can still be called agile.
  • 13. www.whizlabs.com | ©Copyright 2013 Page 13 Agile project management vs. Tradition project management Based on what we learnt as part of Agile Manifesto discussion, let’s summarize the key differences between Agile and traditional project management Traditional Project Management Agile Project Management Focus is on plans and triple constraints Focus is on customer satisfaction and customer value. See refined triple constraint diagram mentioned below. Breaking the work in activities and tasks and managing activities/tasks. Breaking the work based on features Top down command and control Participative culture. Empowered, self organizing team Prescriptive heavy process framework Lean, light weight and adaptive processes Measurement & reporting is largely based on non- value items for e.g. % completion of activities or deliverables Value focused measurement for e.g. number of completed features (Working s/w is primary measure of progress) Typically Scope based delivery Time boxed (fixed time duration) delivery. Scope changes based on customer priorities Up front planning and requirement gathering. In other words Plan what you expect will happen Progressive elaboration. Multiple levels of planning. Plan what you expect to happen with detail appropriate to the planning horizon Enforce that what happens is the same as what you planned Inspection and adaptation (review and retrospectives) Discourage changes late in the lifecycle – heavy change management processes Flexible about changes. Use agile practices to manage change - continuous feedback loops between team and customer - Prioritized backlogs Documentation as key medium to exchange information More focus on face to face conversation and close collaboration Please note that this table is slight exaggeration of traditional project management. In reality most of the experienced project managers do practice some or other practices recommended in Agile Manifesto as lot of it is pure common sense.
  • 14. www.whizlabs.com | ©Copyright 2013 Page 14 In agile, scope is fixed so traditional triangle of triple constraints is viewed as inverted. A more advanced view of agile triage is:
  • 15. www.whizlabs.com | ©Copyright 2013 Page 15 Myths and concerns about Agile approaches While we clarified most of the agile concept, let’s understand some of the common misconceptions about Agile approach. Myths Facts Agile can be used only for small projects and small teams  There are various agile scaling models.  There are examples wherein agile were successfully used for more than hundred member’s team. Of course, there were sub teams each having roughly 8-10 team members. For Agile team must be collocated While there is strong preference about co-location, there have been multiple models developed as guidance to use agile development with distributed teams. Though it requires extra focus on communication & collaboration. Agile methods conflict with PMI PMBOK  PMBOK doesn’t recommend waterfall or any specific processes. It says – for any given project, the project manager is responsible for determining appropriate processes.  PMBOK does focus on continuous planning and talk about progressive elaboration.  In summary, knowledge of PMBOK would actually help in better management of any project be it agile or non-agile. Agile practitioner does not plan Plan is nothing, planning is everything. In agile approach, rather than initial up front planning, planning happens at multiple levels. Agile practitioners conduct planning meeting at the beginning of each iteration. Agile practitioners just jump on the code. Approach that would fail for complex requirements or complex systems. Absence of heavy requirement or design document doesn’t mean that agile practitioner do not do enough ground work. If systems are complex, there could be an iteration zero to lay the basic foundation. Other than what has been mentioned above, a typical question that people ask – if Agile methods are so wonderful why do agile projects fail. Typically there are following reasons: 1) Agile methods are no silver bullet if there are fundamental issues such as problem with knowledge and skills of the team. Agile would still help as it would fail fast. Issues which you may typically realize many months down the line, you may realize after first iteration itself. 2) Lack of support from customer or management of performing organization. 3) People call the projects as agile but do not understand agile concepts. Many of them run mini- waterfalls (phased approach) and think that they are using agile methods. Poor implementation of any framework doesn’t prove that framework is faulty. 4) Agile gives flexibility of scope changes but if on the name of agile, most of the requirements keep on changing all the time, team will just end up doing rework and even agile can’t help.
  • 16. www.whizlabs.com | ©Copyright 2013 Page 16 When to use and when not to use agile Agile methods are useful when :- a) Developing innovative products b) Changing market/economic conditions c) Complex product d) Customer requirements are changing In summary, if there are lot many uncertainties about scope, market conditions, and productivity assumptions etc, agile through its adaptive style of working and continuous risk management would work much better than a typical waterfall model. It requires: a) Skilled and motivated individuals. b) Sufficient customer support and close customer collaboration. c) Support from management of performing environment. Usage of agile methods should be carefully considered when: a) Simple & straightforward project. There is little unknown. Iterative development will be costly as each of the iterations will have some overheads involved. b) Organizations with rigid process framework and slow decision making. c) Limited involvement form customer/users. d) Heavy on back-end changes – if nature of project is such that user can’t easily see and understand the changes. e) Heavy legacy tightly coupled system and slow development. Typical issues could be a. Development of any functionality that user can see & appreciate would take quite long b. It would be difficult to break the scope into features which can be independently developed, tested and demonstrated to customer. f) Team having all novice team members – Idea of self organization will be defeated. g) High-regulatory compliance requirements or areas wherein there is no room for error. For e.g. pharmaceuticals. If no room for errors then experimentation and adaptation process may not work.
  • 17. www.whizlabs.com | ©Copyright 2013 Page 17 Module Revision Case Study ABC Ltd. was quite popular for its accounting product. To increase revenue with existing customer and gain new customers, ABC was planning major enhancements in its accounting product. Company’s CEO John was quite interested in this project. Neo was selected as project manager for this project. Initiation Neo was quite experienced. He quickly identified key stakeholders. Sales & marketing department was the key stakeholder and there few senior marketing managers acting as customers. These business stakeholders were conducting various focus groups, surveys etc to identify potential end customer requirements. With help of subject matter experts, within a week he got order of magnitude estimate and high level plan. As per plan, this was 7-9 month long project, with roughly 1 month to gather detailed requirements for all 10-15 proposed features. Requirements Neo started working with business stakeholders and scheduled multiple workshops to understand detailed requirements & have functional specification ready. The key challenges were:  For some of the proposed enhancements, when asked about detailed business rules, business stakeholders were clueless.  For some of enhancements, there was lack of consensus between various business stakeholders. In spite of all effort put in by Neo and his domain/technical experts, it took almost 3 months to have functional specification ready, which was more than 100 pages document. As this was two months late, plan was broke in the beginning itself. CEO John wasn’t very happy but he provided his approval for Neo’s revised plan. Risks Neo’s plan was having two key risks identified, one around changes in scope and other around testing productivity assumptions. Neo & team had assumed roughly 2000 scripts/cases in testing with roughly 50 scripts a day execution rate. With few days slack, Neo had assumed 9 weeks testing duration. These assumptions were based on available history data. However, few features needed integration with new technologies for which there was no history data so Neo decided to raise a risk up front. Design & Build In spite of huge detailed functional specification, there were confusions. When clarifications were sought with business, it resulted into rework. It took almost a month for team to produce a design specs. Team was now in build (coding and unit testing) phase and all the while Neo was closely tracking the status and reporting to senior stakeholders using earned value management. He was using a robust work authorization system to assign activities/tasks to the team. He somehow felt lack of task ownership in team members. No activity ever finished before time. Due to this he ended up doing more and more close status tracking. He was also trying hard to minimize the deviation from original cost baseline and milestone agreed.
  • 18. www.whizlabs.com | ©Copyright 2013 Page 18 Change Request 1 One fine day, a change request was raised. After impact assessment it was clear that accepting this CR (change request) is surely going to impact the timelines but management wasn’t happy with that. Neo added extra resources. He applied schedule compression techniques such as crashing & fast tracking to accommodate this extra scope. New resources had learning curve and in spite of all planning, team had to work weekends. Change Request 2 When build was about to finish, one of the customer raised another change request for an additional feature. This change request was based on latest marketing research of competitor’s product and this was really something high value for business. Neo had already used all possible slack and he had to clearly state that adding this feature at this stage would mean delaying the entire project by a month. After much deliberation, CEO John decided one month delay to the project and rework was substantial. Testing Finally, build got over and testing started. The risk which Neo identified earlier did occur and testing team was hardly able to finish 30 scripts per day. Large numbers of defects were adding further to the problem. Neo was under tremendous pressure. His half of the time was going in clearing up the testing mess and other half in managing stakeholders who were demanding more & more regular progress reports. Even after taking risk based testing approach and deferring a good number of test scripts/cases, it took almost 3 months to finish the testing. UAT/Business Demo Product was now ready and a demo was planned, calling all key stakeholders. Everyone was quite excited about seeing the working new product first time. Neo was expecting a good outcome. After all this was the outcome of year long hard work. However, he was astonished to hear when sales & marketing manager said, I don’t think we can launch this in current form. This requires number of changes. Neo wanted to say that we built based on requirements given by your department only but preferred not to argue with senior managers. This was really frustrating for Neo and soon he heard that he would be moved to a new assignment and someone else will take over his current project. In the evening deeply frustrated Neo was sitting in a pub, where he met his old friend Kane who was working as agile coach. He told him the whole story and asked what he could have done better. Kane: I will tell you my views but first tell me how do you define a successful Project? Neo: Delivering the scope, on time and within budget. Kane: That means if everything would have gone as per plan till your business demo, you would call that as success. Even though your customer didn’t see value in the final product, can you really call the project as really successful? Neo: I never thought this way. Anyways, do you think I could have done anything differently? I did identify the right risks and was constantly monitoring the risks. Kane: Identifying risk & monitoring the risk is fine but doing something concrete about it early makes
  • 19. www.whizlabs.com | ©Copyright 2013 Page 19 the real difference. Neo: I didn’t get you. Kane: Let’s take help of our scientist friend who has developed a time machine to go back in past. We can fix the things just like movie “19 Again” or “Action Replay”. When we go back in time, you just need to do as I advise. Agreed? Action Replay With help of time machine Neo & Kane went back the time when Neo was just appointed as project manager for Accounting product Enhancement project. Considering the amount of uncertainty involved, Kane advised Neo to do development in small iteration of 4 weeks, while each of the iteration will deliver some useful working functionality. Iteration duration will be timeboxed i.e. fixed duration though scope delivered in iteration can vary. Neo explained CEO John about iterative development approach. John said – “I don’t care what approach you follow. As long as I get the project delivered in time and value from money, I don’t care. Tell me what do you need from me?” Neo requested CEO John to appoint someone in business community as single point of contact – someone who has right amount of knowledge, authority and influence so that he can help in getting support from all key business stakeholders. John appointed one of his senior managers, Peter as product owner. Feature Priority List With help of Peter, Neo was quickly able to put the various proposed features in priority order. They called this list as “product backlog”. Kane asked him to just pick top few for further detailing rather than focusing on everything. Within a week Neo & team was able to break these top priority features into smaller chunks so that each small feature was a fairly independent piece of functionality and was just few days’ worth development effort. Planning Meeting A planning meeting was called out, in which Peter, Neo and rest of team, walked through the Product Backlog i.e. list of features. Together they put the features into a prioritized list using three factors: a. What generates most business value b. What is the right logical sequence - Technical, functional interdependencies c. What is the risk involved. Kane’s logic was to pick High Value and High risk items first so that not only they could deliver business value early but also reduce the risk early on. Once they had the prioritized list of features, it was time for team to decide what they could deliver in first iteration. Team committed to deliver 5 features. Rest of the time of the meeting, team spent in coming up with initial list of tasks needed. Iteration Neo had an urge to put together a plan with key SDLC phases and deliverables defined. He also wanted to use work authorization system for task assignment and status tracking. However, Kane said – “It’s only 4 weeks long iteration so there is no point of creating a detailed plan for that. There is no need of work authorization system as well. We can just have a simple task board / excel in which team members
  • 20. www.whizlabs.com | ©Copyright 2013 Page 20 can add tasks and sign-up for tasks. Your focus should be on ensuring collaboration and removing blockers.” Kane was also against the idea of heavy document deliverables. His focus was more on verbal discussions with business and then documenting what was really necessary. He also suggested colocation (if feasible) and daily morning 15 minutes huddle for better collaboration. Problem As it happened last time, testing turned out to be more complicated than team members thought. Team realized that they wouldn’t be able to delivery everything in time. The options were:- 1) Postpone the iteration review i.e. demo meeting. 2) Deliver everything but few features would be untested. 3) Drop at least one of the features completely and deliver rest. However, Kane was against the idea of even discussing first two options with product owner. He said, we have to deliver on time and working software means thoroughly tested code. Understanding the situation Product owner agreed to defer one of the features to next iteration. Review/Demo Meeting The room was full as everyone was quite excited to see working software so early in the project. Team presented completed features (working software) to product owner and other business stakeholders. In general, everyone liked the product. There were few suggestions. Neo duly noted all the suggestions and demands for new features etc. All of these got added to the backlog (prioritized list of features). Further Iterations While working on first iteration, domain expert was spending some time in further detailing of other top priority features in product backlog. There was a separate meeting held to reflect back at iteration experiences and learnings. Next iteration planning was easy as everyone had better idea about what they can commit. Also some of the inefficiencies were addressed based on lesson learnt (retrospective) meeting after 1st iteration. After 3rd iteration, team was quite comfortable in predicting what they can deliver in each iteration, end date, end budget etc. Business was quite happy with the flexibility to make scope changes and had more confidence after seeing working product. Early feedback and close customer collaboration helped in delivering faster and better. After five iterations, customers got most of key features developed so it was decided to drop the stop the project and launch the product in market. Overall, it all turned out to be major success.
  • 21. www.whizlabs.com | ©Copyright 2013 Page 21 Exercise 1: What were the key changes in approach which made the project successful second time and how? Answer: 1) Working software after each iteration - Helped in getting early feedback. After seeing working software customer can better formulate requirement and might come up with more ideas to maximize business value. 2) Flexibility for the customer to drive the sequence of delivery based on business value and get high value changes delivered even late. 3) Better risk management – most of the uncertainties were known early and there was opportunity to adapt. 4) Team empowerment and buy in from team – Realistic commitments, Empowered team is more motivated & productive. Project manager can focus on removing blockers rather than activity/task management. 5) Single point of contact from business helped in scope prioritization and decision making. 6) By delivering in the sequence of business value, business realized the optimum value much ahead and ROI was improved. 7) Multiple levels of planning – Initial planning and then planning for each and every iteration. Instead of plan, focus here is on planning. 8) Early start as there was no need to wait for complete requirements. Exercise 2: Tick what all the Agile Menifesto values and principles were touched in this case study. Answer: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. [Iterative development was chosen delivering working software in each iteration.] 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. [In review / Demo meeting changes in backlog were welcome.] 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. [Team worked in 4 weeks long iterations.] 4. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.[No work authorization system, concept of team signing up for the work] 5. Working software is the primary measure of progress. [When there was a problem the option chosen was to deliver less but deliver working software] 6. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. [There is mention of lesson learnt meeting after 1st iteration.]