Agile Project Management Simplified
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile Project Management Simplified

on

  • 1,010 views

Learn about Agile Principles, concepts, techniques.

Learn about Agile Principles, concepts, techniques.

Statistics

Views

Total Views
1,010
Views on SlideShare
1,010
Embed Views
0

Actions

Likes
0
Downloads
43
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

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 Project Management Simplified Document Transcript

  • 1. 2013 Jaiveer Singh 7/21/2013 Agile Project Management
  • 2. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Contents Traditional vs. Agile Project Management ................................................................................................................3 Agile Philosophy.........................................................................................................................................................4 Agile Manifesto......................................................................................................................................................4 Agile Principles.......................................................................................................................................................4 Principles of System Thinking (Complex Adaptive Systems) ......................................................................................5 Building High Performance Agile...............................................................................................................................5 Emotional Intelligence and its role in project management......................................................................................6 Agile Teams Communication & Collaboration...........................................................................................................7 Servant & Adaptive Leadership Styles .......................................................................................................................8 Introduction to Agile Methodologies.........................................................................................................................9 Scrum.....................................................................................................................................................................9 XP Programming....................................................................................................................................................9 Kanban...................................................................................................................................................................9 Agile Estimations .....................................................................................................................................................10 Relative Sizing, Story Points.................................................................................................................................10 Wide band Delphi Estimation Technique.............................................................................................................11 Planning poker (Scrum poker) Estimation Technique..........................................................................................11 Affinity Estimation Technique..............................................................................................................................11 User Stories..........................................................................................................................................................12 Agile Planning, Monitoring & Adapting...................................................................................................................12 Product in a Box...................................................................................................................................................12 Iteration & Release Planning, Time Boxing..........................................................................................................13 Information Radiators .........................................................................................................................................14 Kanban Board , WIP Limits ..................................................................................................................................14 Cumulative Flow Diagrams, Burn down charts....................................................................................................15 Retrospective .......................................................................................................................................................16 Agile Analysis & Design............................................................................................................................................16 Product Roadmap, Backlogs................................................................................................................................16 Progressive Elaboration.......................................................................................................................................16 Personas ..............................................................................................................................................................17 Product Quality........................................................................................................................................................17 Pair Programming................................................................................................................................................17
  • 3. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Definition of Done................................................................................................................................................17 Continuous Integration........................................................................................................................................18 Agile Management & Development Tools...............................................................................................................18 Agile Management Adoption...................................................................................................................................18
  • 4. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Traditional vs. Agile Project Management Project management is the discipline of planning, organizing, motivating, and controlling resources to achieve specific goals. A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverable) undertaken to meet unique goals and objectives. A traditional phased approach identifies a sequence of steps to be completed. In the "traditional approach", five developmental components of a project can be distinguished (four stages plus control): Typical development phases of an engineering project 1. initiation 2. planning and design 3. execution and construction 4. monitoring and controlling systems 5. completion In software development, this approach is often known as the waterfall model, i.e., one series of tasks after another in linear sequence. Agile project management approaches based on the principles of human interaction management are founded on a process view of human collaboration. It is "most typically used in software, website, technology, creative and marketing industries.” This contrasts sharply with the traditional approach. In the agile software development or flexible product development approach, the project is seen as a series of relatively small tasks conceived and executed as the situation demands in an adaptive manner, rather than as a completely pre-planned process. It is the most consistent project management technique since it involves frequent testing of the project under development. It is the only technique in which the client will be actively involved in the project development. But the only disadvantage with this technique is that it should be used only if the client has enough time to be actively involved in the project every now and then.
  • 5. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Agile Philosophy Agile Manifesto The agile manifesto is the most important statement which really pitch forked this methodology to a different level. It proclaims “We are uncovering better ways of developing software by doing it and helping others to 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 “While there is value in the items on the right, We Value the items on the left more” Agile Principles 1. Satisfy customer through early and continuous delivery 2. Welcome changing requirements, even late in development 3. Deliver working software frequently 4. Business and developers must work together daily 5. Build projects around motivated individuals 6. Face-to-face conversation is the most efficient and effective method of collaboration 7. Working software is the primary measure of progress 8. Agile processes promote sustainable development 9. Continuous attention to technical excellence and good design enhances agility 10. Maximizing the amount of work not done 11. The best results emerge from self-organizing teams 12. At regular intervals, the team reflects and adjusts its behavior accordingly
  • 6. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Principles of System Thinking (Complex Adaptive Systems) Systems thinking are a management discipline that concerns an understanding of a system by examining the linkages and interactions between the components that comprise the entirety of that defined system. The whole system is a systems thinking view of the complete organisation in relation to its environment. It provides a means of understanding, analysing and talking about the design and construction of the organisation as an integrated, complex composition of many interconnected systems (human and non-human) that need to work together for the whole to function successfully. Complex adaptive systems are special cases of complex systems, often defined as a 'complex macroscopic collection' of relatively 'similar and partially connected micro-structures' – formed in order to adapt to the changing environment, and increase its survivability as a macro-structure. They are complex in that they are dynamic networks of interactions, and their relationships are not aggregations of the individual static entities. They are adaptive; in that the individual and collective behavior mutate and self-organize corresponding to the change-initiating micro-event or collection of events. Building High Performance Agile A high performance Agile team is a committed team that has the right people, has been effectively empowered, has established trust, adheres to an effective process, works at a sustainable pace to deliver quality software of a quantity that reflects a consistent high velocity and factors in influences like capacity and support. Agile teams are the building block to any successful agile transformation. Without strong, self- sustaining agile teams, any change as a result of an agile transformation is very likely temporary. An agile team (preferably 6-9 team members) is: • Cross-functional - the team includes all roles necessary to deliver the work (at minimum Dev and QA), and dependencies outside the team (e.g. UX) are understood and available as needed • Dedicated - team members are dedicated, with any non-sprint work transparently tracked on the task board and the potential impact (decreased priority) agreed with non-sprint stakeholders • Co-located (preferably) - defined as sitting in the same space. Where distributed teams are necessary, ensure strong ties are created through virtual tooling and regular communication
  • 7. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com • Working from a single backlog - the team has a single product backlog, containing items prioritized by the business and ready for the team to work on, from which to pull work • Managing unplanned work - agree with the PO an agreed contingency or bug capacity to be removed from the sprint; manage this contingency to avoid impacting the sprint commitment Three stages of an agile team Stage 1 - Predictable Delivery Start by creating a habit of finishing work requests within the team. Many teams or developers working in a traditional environment quickly lose the habit of finishing a feature completely, perhaps as a result of silo’d delivery or high interruption levels. Quickly reintroduce this habit, before focusing on other agile behaviors. Without the habit of getting to done, a team will never progress. Stage 2 - Build Quality In Once a team has the habit of predictable delivery, the team turns their attention to quality. While learning to deliver predictably, the team has become more and more aware of technical ownership. Stage 3 - Sustainable Delivery Finally, once a team has mastered completing the stories they commit to while building quality in, they turn their attention to improving throughput. This is a delicate step because a traditional mindset might set velocity goals to increase productivity. But velocity is a lagging indicator, telling a team after they have reached a sustainable pace, rather than a leading indicator telling the team what more needs to be done. Emotional Intelligence and its role in project management Many studies have shown that emotional intelligence is a key determinant of success in the workplace. Working well with people—direct reports, peers, customers and management—is just as crucial to success. Emotional intelligence may indeed be the reason that some project managers are more skilled at managing relationships in projects. Emotional intelligence (EI) is the ability to identify, assess, and control the emotions of oneself, of others, and of groups. It is the ability to identify and manage your own emotions and the emotions of others. It is generally said to include three skills: 1. Emotional awareness, including the ability to identify your own emotions and those of others;
  • 8. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com 2. The ability to harness emotions and apply them to tasks like thinking and problems solving; 3. The ability to manage emotions, including the ability to regulate your own emotions, and the ability to cheer up or calm down another person. Agile Teams Communication & Collaboration Effective communication is a fundamental requirement for agile modeling. Teams that pair together stay together. Face-to-face conversations are the heart and soul of agile projects. Agile meetings provide a format for communicating in a face-to-face environment. Meetings on agile projects have a specific purpose and a specific amount of time in order to allow the development team the time to work, rather than spend time in meetings. Agile artifacts provide a format for written communication that is structured, but not cumbersome or unnecessary. The table provides a view of the different communication channels on an agile project. Agile Project Communication Channels Channel Type Role in Communication Project planning, release planning, and sprint planning Meetings Communicate the details of the project, the release, and the sprint to the scrum team. Product vision statement Artifact Communicates the end goal of the project to the project team and the organization. Product roadmap Artifact Communicates a long-term view of the features that support the product vision and are likely to be part of the project. Product backlog Artifact Communicates the scope of the project as a whole to the project team. Release plan Artifact Communicates the goals for a specific release. Sprint backlog Artifact Updated daily, it provides immediate sprint and project status to anyone who needs that information. The burndown chart on the sprint backlog provides a quick visual of the sprint status. Task board Artifact Visually radiates out status of the current sprint or release to anyone who walks by the scrum team's work area.
  • 9. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Daily scrum Meeting Provides the scrum team with a verbal, face-to-face opportunity to coordinate the priorities of the day and identify any challenges. Face-to-face conversations Informal The most important mode of communication on an agile project. Sprint review Meeting The embodiment of the “show, don't tell” philosophy. Displaying working product to the entire project team conveys project progress in a more meaningful way than a report ever could. Sprint retrospective Meeting Allows the scrum team to communicate with one another specifically for improvement. Meeting notes Informal These are an optional, informal communication method. Meeting notes can capture action items from a meeting to ensure people on the scrum team remember them for later. Notes from a sprint review can record new features for the product backlog. Notes from a sprint retrospective can remind the scrum team of commitments for improvement. Collaborative solutions Informal White boards, sticky notes, and electronic collaboration tools all help the scrum team communicate. Ensure that these tools augment, rather than replace, face-to-face conversations. Servant & Adaptive Leadership Styles Servant leadership is a philosophy and set of practices that enriches the lives of individuals, builds better organizations and ultimately creates a more just and caring world. While servant leadership is a timeless concept, the phrase “servant leadership” was coined by Robert K. Greenleaf. A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong. While traditional leadership generally involves the accumulation and exercise of power by one at the “top of the pyramid,” servant leadership is different. The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible.
  • 10. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Adaptive LeadershipTM, described by Ron Heifetz in his classic book Leadership Without Easy Answers, is a set of strategies and practices that can help organizations and the people in them break through gridlocks, accomplish deep change and develop the adaptability to thrive in complex, competitive, and challenging environments. Leadership like this can be learned. And anyone, anywhere within the organization, can do it. Adaptive leadership recognizes there are basically two kinds of problems that people confuse when trying to find solutions. First, there are “technical problems” where an adequate response has been developed; there are one or more experts with general credibility and an established procedure will suffice. The second kind of problems are “adaptive problems” where there are no set procedures, no recognized experts, and no adequate responses developed. When problem definition is not clear cut and technical fixes are unavailable. It calls for adaptive leadership where the leader does not have the answers. Instead, the leader has to orient people to their places and roles, control conflict, and establish and maintain norms in order to orchestrate people working together to find new solutions that will succeed. Introduction to Agile Methodologies Scrum Scrum project management is a software agile development process. Scrum models allow projects to progress via a series of iterations called agile sprints. Each sprint is typically two to four weeks, and sprint planning in the agile methodology and Scrum process is essential. While the agile Scrum methodology can be used for managing any project, the Scrum agile process is ideally suited for projects with rapidly changing or highly emergent requirements like software. The agile sprint itself is the main activity of Scrum project management. The agile methodology and Scrum process is iterative and incremental, so the project is split into a series of consecutive sprints. Each is timeboxed, usually to between one week and a calendar month. XP Programming Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation. In Extreme Programming, every contributor to the project is an integral part of the “Whole Team“. The team forms around a business representative called “the Customer”, who sits with the team and works with them daily. Kanban
  • 11. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Kanban is a new technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied. In Japanese, the word “Kan” means "visual" and "ban" means "card," so Kanban refers to visual cards. Lean uses visual cards as a signaling system that triggers an action to supply the process with its needs either from an external supplier or from a warehouse. A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end. Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we'll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works. A pull system is where processes are based on customer demand. The concept is that each process manufactures each component in line with another department to build a final part to the exact expectation of delivery from the customer. Because your production process is designed to produce only what is deliverable, your business becomes leaner as a result of not holding excessive stock levels of raw, partly-finished, or finished materials. Just-in-time is a “pull” system of production, so actual orders provide a signal for when a product should be manufactured. Next stage of software development can pull next batch of work once they have capacity to process more. Agile Estimations There are three main concepts you need to understand to do agile estimation. 1. Estimation of Size gives a high-level estimate for the work item, typically measured using a neutral unit such as points 2. Velocity tells us how many points this project team can deliver within an iteration; 3. Estimation of Effort translates the size (measured in points) to a detailed estimate of effort typically using the units of Actual Days or Actual Hours. The estimation of effort indicates how long it will take the team member(s) to complete the assigned work item(s). Relative Sizing, Story Points Relative estimation applies the principle that ‘comparing’ is much quicker and more accurate than ‘breaking down’. Relative story point estimation is a type of delphi estimation method that is applied at the product backlog level. In a nutshell, this means that it relies on the simultaneous input of a cross-functional team to ‘triangulate’ in on a common estimate for a user story, or other product backlog item.
  • 12. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Unlike traditional estimation units such as ‘ideal days’, the measurement unit utilized during relative estimation is not time based but rather, size based. Size in this case does not have a direct relationship to a specific time duration but instead, it is a function of three factors: effort, complexity and risk. These sizes are measured in units that we call ‘story points’ and typically, a slightly altered Fibonacci sequence is used as the point system: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞ The reason for using the Fibonacci sequence is to reflect the inherent uncertainty when estimating larger items. The team ‘velocity’ metric is then used to determine how many points can be completed on average per sprint and this value is then applied to the product backlog to determine how long the entire backlog will take. Wide band Delphi Estimation Technique • It is a consensus based estimation approach wherein the team agrees on a final number after few deliberations • A moderator is identified. A team of 3-7 good estimators are selected and provide them the work item to estimate. • A kickoff meeting is called wherein team first creates work break structure (WBS) of the tasks/activities involved and discuss the assumptions. • After which each team member provides their individual estimates separately and a second meeting is called to arrive at the consensus on the differing items. • The final number submitted is reviewed by the Project manager and agreed as basis for baseline plan. • This method is for detailed effort estimates Planning poker (Scrum poker) Estimation Technique • It is a consensus based estimation approach and it is a variant of wide band Delphi • After a moderator or Product manager explains the story, the team discusses the assumptions or risks and gets clarifications • They select a number from a deck of cards given to them and simultaneously turn up their number to indicate their number. • People with the lower and higher estimates are given a soap box to offer their estimation. • The discussion continues until consensus is reached • This method avoid anchorage by the influential members of the team Affinity Estimation Technique Affinity Estimating is a technique many Agile teams use to quickly and easily estimate a large number of user stories in story points.
  • 13. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com • This is a great technique if you’re just starting a project and have a backlog that hasn’t been estimated yet, or in preparation for release planning. • In this technique stories are read out to the whole team and then the team is asked to arrange the stories on horizontally on a wall in order of size, without talking. • Present a set of reference stories the team has done in the past, i.e. good examples of a point 1, 2, 3, 5, 8, etc. stories. • It is a high level estimating technique User Stories In agile development, the user story is a lightweight and more nimble substitute for what has been our traditional means of specifying software requirements - software requirements specifications, use case specifications, and the like. Indeed, an argument can be made that the user story is the most important artifact in agile development, because it is the container that primarily carries the value stream to the user and agile development is all about rapid value delivery. User Story • A High-level definition of a requirement, containing enough information for estimation and implementation. • Focus on “What” not on “How” • Well-written user story to follow INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) model. Mike Cohn suggests a more formal approach to writing user stories. He suggests the format: As a (role) I want (something) so that (benefit). Formal • Theme: Theme is collection of User stories • Epic: Epics are larger user stories, typically ones which are too big to implement in a single iteration and therefore they need to be disaggregated into smaller user stories at some point. Agile Planning, Monitoring & Adapting Product in a Box
  • 14. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Before you begin, focus on the end. In this exercise, teams create the physical “box” that sells their idea—whether that idea will ultimately become a tangible product or not. By imagining the package for their idea, the teams make decisions about important features and other aspects of their vision that are more difficult to articulate. This game is popular among software developers when setting out to capture the customer’s view of a new application, but its use doesn’t stop there. The game can help facilitate any vision- oriented discussion, and has been used to describe topics ranging from “our future methodology” to “the ideal hire.” Iteration & Release Planning, Time Boxing Product Roadmap It is a high level understanding of the increments (themes) that you're going to take on in the next few releases to accomplish those strategies. These themes are very high level (giving you plenty of room to react to what you learn along the way). It gives your customers a feel for what you're about and where you're going. Release Planning Release planning is all about understanding what you're going to do towards those themes in the next release. It is setting a common understanding amongst the teams on what the release will likely look like. It is not a commitment, rather a projection. It helps to establish a common baseline across the teams. Iteration Planning This is the first level where you actually commit (at the team level). You plan out what you're going to accomplish in the next iteration (a matter of weeks). You get a clear understanding on what done is (acceptance criteria). Daily Stand-up This is the level at which individuals commit to what they're going to get done in the next day. It helps to ensure that the team is communicating. It encourages collaboration and highlights issues which are blocking the team. Time boxing
  • 15. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com • The time boxing is the method where the time is fixed for an iteration, say 1-4 weeks and the story points /stories will be fitted into the iteration based on the velocity of the team or capacity to deliver. • The time boxing duration is decided by the stage of the project and the type of the project and the experience of the team. • The thumb rule is to fix one week as the iteration during the beginning so that team will slowly pickup speed and once after 2-3 iterations when velocity is stable, switch to a typical 2-3 weeks mode. • Time boxing applies for release also and it varies from 1-3 months in duration. • Fundamentally, it is designed to establish a sense of urgency and coerce the team to focus their effort on getting something done. Information Radiators Information radiator • Information Radiator is popular term invented by Alistair Cockburn. • It is publicly posted displays that shows anyone walking about an idea of what’s going on in the team. It will be mostly the Big visible charts, Graphs, Release/Iteration plans or “stick it” index or story cards. • What information needs to be displayed is entirely up to the project team and they also decide how often this information need to be tracked or updated. • Information radiator are also good ways to remind team of critical items, risks, issues that need to be addressed. Kanban Board , WIP Limits Task/Kanban boards • Kanban is a scheduling system that helps to determine what to produce, when to produce and how much produce. • A new card is “pulled” into the system only when “in progress” card is complete. • This will give a clear idea of where the bottleneck is their in an iteration if the WIP items/cards are getting increased. WIP limits
  • 16. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com • One of the goal in agile process is to reduce Work in progress (WIP) items as much as possible in an iteration so that wastage and bottlenecks are avoided. WIP limit is a way of eliminating bottlenecks and the subsequent wastage/issues. • This is applicable to a task/story in an iteration • WIP limit does not allow more cards into a development queue unless there is a capacity to limit the WIP of stories. Typical limit is 2-3 cards • Some agile processes in manufacturing like Just in time (JIT) will strive to reduce WIP as low as possible so that wastage is eliminated e.g. Toyota Cumulative Flow Diagrams, Burn down charts Cumulative Flow Diagram – CFD A Cumulative Flow Diagram (CFD) is an area chart that shows the various statuses of work items for a product, version, or sprint. The horizontal x-axis in a CFD indicates time, and the vertical y-axis indicates cards (issues). Each coloured area of the chart equates to a workflow status (i.e. a column on your board). A CFD can be useful for identifying bottlenecks. If your chart contains an area that is widening vertically over time, the column that equates to the widening area will generally be a bottleneck. Burn down Charts • Burn-down chart tracks how much work remains on the project against the iteration. • At the end of each iteration mark the progress and you can project forward to see whether or not you’ll hit your target end date • A sudden increase or decrease in the number of story points in a graph is clear indication that customer requirement changed. Burn down Charts • Burn-up chart tracks how much work is done. • It shows more information than burn-down chart as it indicates a line showing how much work in the project is planned. • In Burn-up chart bottom line is the work done and top line is the scope.
  • 17. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Retrospective Retrospectives • This is a post iteration demo/review meeting to discuss and understand what went right, wrong and needs improvement in an iteration/sprint on each story • It is a lessons learnt meeting to understand the issues, analyze root cause and to learn from that. The idea is to come up with proper preventive measures in future • This session also helps to understand any changes in scope during the iteration (any stories added/modified or deleted from the list) and what is the impact of that on the system and future iterations. • Without the participation from all team members, Preparation and commitment the retrospective will not be successful Agile Analysis & Design Product Roadmap, Backlogs In general the product roadmap is a long term business planning and communication tool, however in agile world it is used in short term product planning perspective, but it is still required. It is usually maintained by Agile Product managers In roadmap the approximate release dates are calculated based on the product backlog and the team’s velocity. It is the output from release planning process and consists of a series of planned release dates including the theme and prioritized feature set. In commitment on schedule beyond next release and so roadmap is a plan of intent. Progressive Elaboration This concept focus on detailing upcoming requirement/ next scheduled items as one moves forward in time while more details gets available with better clarity. Progressive Elaboration means that over time we elaborate the work packages in greater detail. Progressive Elaboration refers to the fact that as the weeks and months pass we have planned to provide that missing, more elaborated detail for the work packages as they now appear on the horizon. Generally in development projects the scope progressively elaborates, this poses a great risk to schedule/cost as the estimation is usually done during the start of the project and not all elaborations are considered as changes.
  • 18. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Personas Personas define an archetypical user of a system. They are fictitious people which are based on your knowledge of real users of the system. Personas are incredibly useful when you don’t have easy access to real users because they act as “user stand-ins”, helping to guide your decisions about functionality and design. Personas are formed based on the stakeholder analysis and the knowledge of key users, their behavior and expectations. A system can have one or many personas. The main persona is the primary persona and we may have negative persona also. Product Quality Pair Programming Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer (or navigator), reviews each line of code as it is typed in. The two programmers switch roles frequently. Definition of Done Definition of done • The definition of done is important as each team/team member, customer may have different understanding and interpretation of done. • A proper definition of done will avoid half tested, half documented, half optimized, half refactored and eventually half ready software to be released. • A typical “Done Done” means implemented, reviewed, unit tested, but not necessarily documented. • Make definition of done more comprehensive to build high value, high quality software and to avoid future technical debt. • A potentially shippable product may or may not have adhered to proper done definition.
  • 19. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com Continuous Integration Continuous integration Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed as part of extreme programming (XP). Continuous integration (CI) is used to improve the quality of software and reduce time taken to deliver it. Principles of continuous integration include • Maintain a code repository in a proper version control tool • Automate the build (Make, Ant, Maven, MS build, IBM rational build forge) • Make build self testing • All commits to baseline everyday • Every commit should be built • Keep the build fast (10 minute builds) • Test in a clone of production environment (Integration server) • Make the builds available to customers and testers on timely basis • Automate deployment(Installation) Agile Management & Development Tools Agile Tools used The most common software tools used continue to be standard office productivity tools such as Excel (61%), Version one (37%), Microsoft Project (36%) and JIRA (35%). Few other widely used tools for continuous integration are CruiseControl & Jenkins. Agile Management Adoption According to the 2012 CHAOS report, Agile succeeds three times more often than waterfall. Because the use of Agile methodologies helps companies work more efficiently and deliver winning results, Agile adoption is constantly increasing. Ahmed Sidky and James D. Arthur has developed an Agile Adoption Framework providing a structured, repeatable framework for adopting Agile processes in a development organization. The framework uses a four staged approach for assessing the organization's ability to adopt agile
  • 20. Agile Project Management www.singhjaiveer.blogspot.com www.project-management-practice.blogspot.com practices, cascading down through project suitability and aims to reconcile the findings in a set of agile processes to adopt: Sidky Agile Measurement Index (SAMI), which proposes the agile potential (i.e., the degree to which that entity can adopt agile practices). This consists of four components: 1. Agile Levels - a set of agile practices that are related and, when adopted collectively, would make significant improvements in the software development process, thereby leading to the realization of a core value of agility. 2. Agile Principles - guidelines that need to be employed to ensure that the development process is agile. 3. Agile Practices and Concepts - concrete activities and practical techniques used to develop and manage software projects in a manner consistent with the agile principles. 4. Indicators - questions the assessor uses to assess certain characteristics of an organization or project, such as its people, culture, and environment, in order to determine assess the readiness of the organization or project to adopt an agile practice. Web References for further study on Agile Management. • www.AgileAlliance.org • www.AgileManifesto.org • www.AgileBok.org • www.AgileModeling.com • www.Agile-Process.org • http://www.mountaingoatsoftware.com Useful Books on this subject • Agile Development by James Shore • Agile Estimating & Planning by Mike Cohn • Agile Retrospectives by Esther Derby • Managing Agile Projects by Sanjiv Augustine • The Software Project Managers’ Bridge to Agility • Disciplined Agile Delivery by Scott W. Ambler