fullpacforkids

• Agile Project Management Methodology
• Agile Methodology
• Training For Agile Project Management Pdf

Since its inception, the Agile methodology has come a long way to become a popular approach among a wide variety of organizations. For those unfamiliar with the term, Agile is a method of project management where projects are organized into epics then broken down into small manageable sections via chapters and sprints. Master of Project Academy is a relatively new training firm, and they offer project management training online, amongst other topics. The ‘all courses’ project management bundle gives you access to six courses covering PMP, Microsoft Project, and Agile Scrum. If you don’t need all these topics, you can buy the courses separately.

Title

Agile Project Management with SCRUM

Author

Bernard Szlachta, Prateek Shrivastava

Subfooter

Agile Project Management with SCRUM Bernard Szlachta, Prateek Shrivastava

• 1Waterfall ⌘
• 4Waterfall vs Agile ⌘
• 12Scrum Roles ⌘
• 13Backlogs ⌘
• 14Scrum Process ⌘
• 16Information Radiators⌘
• 22Agile Risk Management⌘
• 25Painful Transition⌘
• 29Other Agile Methodologies⌘

• Published in 1970 by Winston W. Royce
• Ironically, Royce was presenting this model as an example of a flawed, non-working model
• Ideal in construction or engineering projects
• Usually preceded by prototyping
• Requires Central Control System
• As complexity increases, central control breaks down

Waterfall Stages ⌘

Waterfall Model Problems ⌘

• Market Dynamics/Changing Requirements
• Blaming other people (Analysts blaming designers, designers developers, etc..)‏
• Lack of understanding business by lower ranks
• Long feedback
• Hit-by-a-spaceship effect (Abducted by aliens)

'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.'

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

• Requirements for the whole project vs. requirements for the iteration, overview of the bigger picture
• Clearly defined roles vs Cross-functional teams
• Long time estimation vs short time estimation
• Long-time budgeting vs short time budgeting
• Abandoning project in the middle leaves useless artifacts vs each iteration delivers business value
• Extensive out-of-synch documentation vs lean general and in-line code documentation
• Changes are expensive vs changes are expected and cheap
• Long feedback loop between customer and developer vs almost immediate feedback

Agile Inverted Triangle ⌘

• Successful project is not necessarily a project that goes exactly as expected, yielding results identical to those that were predicted.
• Scrum controls the process of software development to guide work toward the most valuable outcome possible.

_{Copyright 2012 VersionOne Inc. All Rights Reserved}

• Scrum was first defined as 'a flexible, holistic product development strategy where a development team works as a unit to reach a common goal' as opposed to a 'traditional, sequential approach' in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the 'New New Product Development Game'.
• The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries. They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team 'tries to go the distance as a unit, passing the ball back and forth'.
• In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology at the Business Object Design and Implementation Workshop held as part of Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) in Austin, Texas, its first public presentation. Schwaber and Sutherland collaborated during the following years to merge the above writings, their experiences, and industry best practices into what is now known as Scrum.

• Product Owner: The customer itself or the proxy between the customer and the team
• Scrum Master: Typically not a project manager
• Development Team

All management responsibilities in a project are divided among these three roles!!!

Project Manager ⌘

THERE IS NO PROJECT MANAGER ROLE!

What does the project manager do in SCRUM?

Potential role of 'Traditional Project Manager' in SCRUM ⌘

It depends upon!

• Organizational Set-up
• Size of Project
• Competency of Project Manager

Project Manager can either be:

• Scrum Master
• Product Owner
• Project Manager owning multiple Scrum teams

• Choosing Teams
• Budgeting
• Client Interaction
• Manage Contract
• Interface with PMO

Pigs and Chickens ⌘

• The people who fill the three Scrum roles are those who have committed to the project (Pigs)
• Others might be interested in the project, but they aren’t on the hook (Chickens)

Scrum Team ⌘

• The Team is responsible for developing functionality
• Self-managing and self-organizing
• Up to 10 people (7 optimal)
• Cross functional (db admin, web designer, tester, etc...)‏
• Bigger project = more Scrum teams
• Responsible for managing itself and has full authority to do anything to meet the Sprint goal within the guidelines, standards, and conventions of the organization and of Scrum

Scrum Master ⌘

• Responsible for the Scrum process
• Teaching Scrum to everyone involved in the project
• Implementing Scrum so that it fits within an organization’s culture and still delivers the expected benefits
• Ensuring that everyone follows Scrum rules and practices
• Manager drives the team vs Scrum Master serves the team
• Scrum Master is a facilitator

Product Owner ⌘

• Responsible for representing the interests of everyone with a stake in the project and its resulting system
• Achieves initial and ongoing funding for the project by creating:
  • project’s initial overall requirements
  • return on investment (ROI) objectives
  • release plans
• The list of requirements is called the Product Backlog
• The most valuable functionality is produced first
• Prioritize the Product Backlog to queue up the most valuable requirements for the next iteration

Quiz ⌘

• How many different roles are in SCRUM?
• How may people can be in a team?
• How long usually does a sprint last?

Exercise ⌘

Lets get up from our seats

Product Backlog⌘

• The requirements for the system or product
• Product Owner is responsible for the contents, prioritization, and availability of the Product Backlog
• It is never complete
• Is merely an initial estimate of the requirements
• Span to foreseeable future
• Made of pieces of functionality or wishlist
  • Epics
  • Stories
• Proven business value
• Testable
• Examples
  • User can browse on-line catalogue
  • Client can buy a product using a credit card

Sprint Backlogs⌘

• A subset of Product Backlog
• Specified and discussed with all the team members especially with the product owner
• Estimated by more than one person (ideally, entire team)
• If it takes longer than a couple of days, they should be split

User Story Example⌘

As a dog owner, I want to sign-up for a kennel reservation over Christmas so that I get a confirmed spotAcceptance Criteria:

• Verify individual as a registered pet owner
• Verify that preferred members get 15% discount on basic service
• Verify that preferred members get 25% discount on extended services and reservation priority over other
• members
• Verify that past Christmas customers get reservation priority
• Verify that declines get email with discount coupon for future services

Definition of 'DONE'⌘

• Definition of Done can differ
• Clarify what does it mean
• Entire Scrum Team contributes to Definition of Done
• For example:
  • functional and unit tested
  • documented
  • committed into repository
  • deployed on staging environment
  • accepted by the client (thumbs up)

Prioritization Techniques⌘

• MoSCoW Prioritization Scheme
• Monopoly Money
• 100-point method
• Kano analysis
• Value based prioritization (most important)

Agile Planning ⌘

Agile Estimation Technique⌘

• User stories
  • Business value
  • How to test it (acceptance criteria)‏
• Different schools about complexity
  • Abstract size (0,1,2,3,5,8)‏
  • Number of IDEAL days - A day in life of developer where he has everything he needs to complete the job with no disturbance.
• Planning poker
• Splitting User stories into task
• Task duration from 1 hour up to 1 day. If its gets longer, it is advisable to break it further.

Planning Poker⌘

• Everyone selects complexity from Planning Poker Card
• Two extreme people explain why they thought this way
• Discussion
• Optional re-vote
• You can play poker for estimated time and estimated business value

Precision vs Accuracy⌘

• Precise but not accurate PI number: 3.12134352343435
• Accurate but not precise number PI number: 3.14
• Try to be accurate not precise
• Precision gives false confidence about estimation

Estimation⌘

• What is the height of the highest mountain
• What is the longitude of Reykjavik
• What is the latitude of Reykjavik

Estimation Exercises⌘

1. Choose couple of user stories
2. Each person in a group should write down their estimations without communicating with each other
3. Then, each person tells their estimates and quickly explain why (the components)
4. If there are discrepancies, take another round for the same story

Iteration (Sprint)‏⌘

• Estimating and Planning (4+1)‏
  • Define clear goals
  • Everyone (not only the person who are going to develop it) MUST understand the task
  • Everyone can contribute their way they see is the best
• Daily Scrums (15min every day)‏
• Demonstration (1h)‏
• Retrospection – post-mortem (1h)‏

Exercise⌘

Put the proper names in the boxes above using words: Scrum, Retrospective, Demo, Planning, Estimating

More about User Stories, Epics, Use Cases and prioritization can be found in Product Owner Course available athttp://www.nobleprog.com/scrum-product-owner/training-course

SCRUM WALL

Product Burn-down Chart⌘

Sprint Burn-down Chart⌘

Tools⌘

Post-it vs tools⌘

• Tools can confine your choices
• Post-its are simple and always visible
• Tools are recommended when you work with an outsourced teams’ members

• Do not change the duration of an iteration!
• What if we discovered new tasks to do in order to complete user story?
• Measurement – hours or finished tasks
• What does it mean done
• Overtime
• Adjusting next iteration

• All team members are responsible
• Hit-by-the-bus factor
• Openness
• Support and knowledge exchange
• Pair programming (one keyboard)‏
• Master-lamma pair programming

• The questions must be asked:
  • What have I done since the last Daily Scrum?
  • What am I going to do between now and the next Daily Scrum?
  • What is preventing me from doing my work?
• People MUST stand
• Up to 15 min regardless of the team size
• Everyone invited, only pigs are talking

• Product Backlog Planning (PO, Managers, Application Users)
• Sprint Planning Meeting (Team, PO, SM)
• Estimation
• Iteration (Sprint) from 2 to 4 weeks - Daily Scrum (stand-up meeting)‏
• Demonstration
• Iteration review (retrospective meeting)‏

Agile Project Management Methodology

Risk Adjusted Backlog ⌘

_{©Agile Risk Management, a blog post by Mike Griffiths, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html Relates PMBOK risk management to Agile methods, contains several great ideas and graphics, including the “ risk burn down graph.”}

Risk Burndown Graph ⌘

_{©Agile Risk Management, a blog post by Mike Griffiths, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html Relates PMBOK risk management to Agile methods, contains several great ideas and graphics, including the “ risk burn down graph.”}

• documentation - You still need some sort of documentation
• budgeting
• outsourcing
• bigger projects

• If you know requirements upfront and model must be proven - Life critical projects (medical, army, etc...)‏
• Cannot change the way clients or your management thinks
• Old ways work fine ; -)‏

• What happened to Gantt?
• Time reporting?
• Documentation?
• Responsibility
• Clients involved all the times

Beware of these PITFALLS ⌘

TOP 10 REASONS AGILE PROJECTS FAIL

1. Tansistioning without proper Training/Coaching
2. Resistance To change
3. Seating Arrangement
4. Poor Communication/Collaboration
5. Lack of Transparency
6. Fear
7. Process without Principles
8. Not empowering the teams
9. No proper Retrospection
10. Still no cross-functional team

_{©Mike Cohn (http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting)}
Frequency:

As needed

Agenda:

What has your team done since we last met?

What will your team do before we meet again?

Is anything slowing your team down or getting in their way?

Are you about to put something in another team’s way?

• Redmine
• Xplanner (deprecated)‏
• Google Calc (be careful)‏
• Agilo
• Scrumy
• Spreedsheet (deprecated)‏
• Wiki

• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Crystal
• Lean Software Development
• Kanban

XP Practices⌘

XP consists of number of powerful core practices which help in succeeding with scrum. They are:

• Small Releases
• Collective Code Ownership
• Coding Standards
• Continuous Integration
• Test Driven Development (TDD)
• Continuous Refactoring
• Simple Design
• Pair Programming

• Choose roles
• Create backlog
• Start Release Planning
• Estimate the Stories (cards)‏
• Come up with Release Plan based on velocity
• Conduct Sprint Planning meeting
• Assign the stories/tasks to people
• Develop the product in iteration
• Conduct the DEMO
• Conduct Retrospective

• Accepting uncertainty
• Welcome technology changes
• Delivering early and often
• Constant estimating and planning
• Sustainable work pace
• Early feedback and learning
• Self managing work environment
• Self controlling environment
• Delegating the responsibility
• Have fun at work

From marketing departments to consulting firms, businesses are becoming increasingly agile.

As agile project management leaves the IT-only sphere and becomes popular across industries and other company departments, more leaders are wondering how this project type can apply to their own teams. From marketing departments to consulting firms, businesses are becoming increasingly agile.

While the concept of agile development seems simple, it’s not always easy to implement. If you are a business owner or department head looking to change your company with agile, follow these training tips to onboard your team.

Take Agile Out of the IT Mindset

The first step when encouraging employees to embrace agile is to separate it from the idea that it only applies to coding or IT projects. Instead, present agile as a method for overcoming change.

“The common factor in all of these initiatives is that they involve a change...and thus the need to adapt quickly,” James Scott writes at GanttPRO. “And agile is all about change, [and] dealing with the unpredictable.”

Consider a case study of emergency air transport company, Air Methods, shared by Tori Funkhouser at Udacity. The business wanted to create training materials for its 4,500 employees and 2,000 outside medical crew, but knew that was a massive undertaking and wasn’t sure about the scope and execution of the project.

Air Methods used tools like Trello to create tasks and assigned them red and green labels — red for backlog and green for projects ready to go. They met monthly to review the green tasks and move certain assignments out of the backlog. This provided clarity for employees and management to see what was in the newly organized backlog and how long they should expect to wait before something was complete.

This wasn’t an IT project, but it used agile to enact change and make the process go smoother.

You can also take agile out of the IT mindset by presenting it as a cultural change, rather than a new project management process, Nicholas Malahosky writes at visual management software company, Targetprocess.

“It’s important for Agile transformations to happen more-or-less organically,” he writes. “Nobody wants to put up with another vague strategy change that’s been mandated by management.”

Once your team realizes that agile really can help them, they will be more likely to embrace the new information and apply it.

Present Agile Project Management as a Growth Opportunity

If your team is still unsure about using agile project management, present the concept as an opportunity to grow and improve employee skill sets.

If your team is still unsure about using agile project management, present the concept as an opportunity to grow and improve employee skill sets.

Leadership expert Anne Loehr shares some interesting statistics on employee training and coaching. Essentially, engaged employees want to learn more, and employers who invest in employees typically notice higher engagement rates:

• 52 percent of millenials cite career progression as the most desirable quality in a workplace.

• Employees who have the opportunity to develop professionally are twice as likely to say they will spend their career at a company.

• The strongest engagement driver for employees is belief in senior leadership, followed by growth and development.

This focus on professional growth and development also encourages team members to come to you for agile training and use cases. They want to learn more from you to see how agile can benefit them.

“Preserving positive workplace morale means taking the time to communicate with employees about the change before and after it occurs,” career coach Tess Taylor writes. Your open communication will demonstrate your respect for your employees and their “right to know” what is going on, while giving you a platform to provide enough information to soften the change.

Even if you do have early adopters chomping at the bit to use agile, try to keep everyone at the same learning pace and knowledge level. Ron Eringa, professional scrum trainer, says your entire company should try to match pace with what they learn and apply in the agile framework.

If unaligned, with some teams immediately applying agile while others are still learning it, both parties can become frustrated. One side wants to race ahead while the other is overwhelmed with new agile material. By keeping most scrum teams and managers at the same (or at least similar) application levels, everyone can grow at the same rate.

Identify Roadblocks and Barriers to Implementation

Once you start testing projects with agile project management, look for problems slowing down adoption in your company.

Once you start testing projects with agile project management, look for problems slowing down adoption in your company.

Management trainer Marcus Blankenship says there are three types of employees likely to push back against your agile process:

• Cowboys and mavericks. These team members hate having to check in and report on a daily basis.

• Heroes and crisis managers. People who love to save the day at the last minute. The problem is, identifying issues before they become problems is a component of agile management.

• Brilliant hermits. Team members who lack social skills and have no desire to improve them.

Looking out for these employees and intervening when you find them can help you understand agile pushback and address the issues appropriately.

Look for Hierarchical Barriers

Additionally, you may need to adjust your hierarchy or corporate communication policies to implement agile project management.

“One of the key principles of Agile is not only to work with your users, but that developers will have access to key stakeholders on a daily basis,” Jory MacKay explains at online project management provider, Planio. “For some companies, this is a stretch. Is there a hard set hierarchy in place or will those at the time gladly be a part of the development process?”

The problems don’t always lie in employee adoption if upper management is creating their own barriers.

Prepare for an Agile Culture Shift

Your team also needs to be ready to embrace the culture shift that comes with agile project management.

“Agile teams are empowered to do what's right for the product,” writes Paul Rasmussen at technology consulting firm Omni Resources. “Their allegiance is more to the team than it is a manager. This notion is a shift from the traditional top-down command and control type management your company may be used to.”

Again, this is where traditional office culture and hierarchy could get in the way of successful agile productivity.

Reinforce the Company’s Dedication to Agile

Training isn’t something you do once. Even if your team seems to have a strong grasp of agile concepts as you introduce them, they may forget some of the best practices over time.

“Frequent training can help maintain skills and knowledge,” Mike Kappel founder of Patriot Software, writes. “Regular sessions are also a great way to teach more advanced skills and notify employees of any changes.”

Constant learning applies to leaders and managers as well as lower-level employees. In fact, the more leaders learn, the better off their teams are.

Business agility consultant Adam Ulery strongly encourages scrum masters to keep learning the “why” behind what they do. If your first response to any question is “because I said so,” you don’t know as much about agile as you think, he writes. Plus, your team is unlikely to follow your lead because they still have no idea why a certain step or process is important.

“Employees develop a comfort level when they see management supporting the process,” writes Patricia Lotich at Thriving Small Business writes. “If you can’t support the change 100%, don’t even think about making it. Employees will know it and will self destruct.”

Employees might ignore new processes from senior management out of loyalty to their direct reports, or fail to embrace the agile process if other teams aren’t required to use it — even if their manager wants to implement it. This is another reason to introduce it at the same pace across the board.

Tips and Resources for Successful Agile Training

Once you have a plan for introducing agile to your team, gather the best resources and training options to make the process easier.

Once you have a plan for introducing agile to your team, gather the best resources and training options to make the process easier.

• Rachel Burger, a leading voice in agile, sets out an 11-step live training process where teams can learn and apply agile best practices through a small group project. This introduces ideas in a low-stress environment instead of suddenly asking teams to do their work differently.

• Agile coach Anthony Mersino created a useful graphic you can download and give to team members. It includes the 12 agile principles, three scrum roles, four agile values, and five steps to implement the process. It’s helpful for any team using agile, regardless of their experience.

Agile Methodology

• IT expert Curtis Franklin Jr. has a guide comparing agile development to Pokémon Go. This takes a dry topic that may confuse your team and allows you to create a fun reference or activity to help your employees develop an interest in the new information.

• Bob the BA offers video training and in-person tutorials to help your employees understand agile management and how to use it.

Each team will embrace agile concepts in different ways. By using multiple training resources and developing a comprehensive onboarding process, you can make sure that no employees are left wondering what agile is and why they should use it.

Training For Agile Project Management Pdf

images: kantver/©123RF.com, goodluz/©123RF.com, rawpixel, rawpixel