Which Agile/Scrum Certificates?

[SunnyInHades]

When I read something like this:


About Nader K. Rad

14 years of experience in project planning, project management consultancy, and project board advisement in different industries and environments. Author of more than 40 books, mostly on project management topics. Speaker, instructor, and trainer of various project management topics. Holder of a Civil Engineering BSc and Philosophy of Science MSc; certified as PMP®, PRINCE2® Practitioner, PRINCE2® Trainer, MoP® Foundation, MSP® Foundation, M_o_R® Foundation, MoV® Foundation, P3O® Foundation, AgilePM® Foundation, ITIL® Foundation, PMI-ACP®, CSM®, PSM I, PSPO I, EXIN Agile Scrum Foundation, Advanced Certificate in Critical and Structured Thinking.


My immediate reaction is - so you've not actually ever delivered anything yourself. Other than gather qualifications and write about yourself, it all sounds like hot air with no real world experience of having your balls on the line for delivering something large, important and expensive to a real world client.


Meh!

Many years ago I worked for a company that had previously employed an 'ood' guru.

He had his design of a gui system he'd developed for the company published as a case study in a
well known ood design book and presented at ood conferences -
pages of diagrams, explanations, object inheritance, relationships, patterns, use of case tools etc.

Trouble was the actual system was slow and crap. Took him about a year to finish.
Huge, impenetrable, a nightmare to maintain/modify, object oriented to the atom.

A guy joined the company who'd previously used a 'code behind' visual gui designer tool
- using this it took him one day from scratch to produce a better, faster system.

[SimonMac]

Many years ago I worked for a company that had previously employed an 'ood' guru.

He had his design of a gui system he'd developed for the company published as a case study in a
well known ood design book and presented at ood conferences -
pages of diagrams, explanations, object inheritance, relationships, patterns, use of case tools etc.

Trouble was the actual system was slow and crap. Took him about a year to finish.
Huge, impenetrable, a nightmare to maintain/modify, object oriented to the atom.

A guy joined the company who'd previously used a 'code behind' visual gui designer tool
- using this it took him one day from scratch to produce a better, faster system.

A case of those who can do, those who can't teach?

[Gumbo Robot]

As a developer I don't see why it matters a jot.

I've worked in several supposedly "Agile" environments - you do the morning stand-up, do the work in sprints, err.., that's it.

I don't know why some companies make a big deal of it but I failed my last interview as a result of not knowing the minutiae of Agile - in particular who exactly should be involved, the distinctions between different types of stakeholders and the role of the business therein.

I was particularly peeved because I'd aced a somewhat grueling technical test beforehand....

[SunnyInHades]

not knowing the minutiae of Agile - in particular who exactly should be involved, the distinctions between different types of stakeholders and the role of the business therein.

'ere you go, everything yo'll ever need .. the cheat sheet from Agile Project Management For Dummies (genuine) ..

From Agile Project Management For Dummies Cheat Sheet - For Dummies (part 1)

Agile Project Management For Dummies
From Agile Project Management For Dummies by Mark C. Layton
Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management methodologies include scrum, extreme programming (XP), and lean, among others. These methodologies all adhere to the Agile Manifesto and the 12 Agile Principles, which focus on people, communications, the product, and flexibility.

A Manifesto for Agile Software Developers
The Agile Software Development Manifesto© is an intentionally streamlined expression of the core values of agile project management. Use this manifesto as a guide to implement agile methodologies in your projects.
"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."
©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
This declaration may be freely copied in any form, but only in its entirety through this notice.

The 12 Agile Principles
The 12 Agile Principles are a set of guiding concepts that support project teams in implementing agile projects. Use these concepts to implement agile methodologies in your projects.
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.
The Agile Roadmap to Value
The Roadmap to Value is a high-level view of an agile project. The stages of the Roadmap to Value are described in the list following the diagram:



• In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is, how it will support your company or organization’s strategy, and who will use the product. On longer projects, revisit the product vision at least once a year.
• In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revise the product roadmap at least twice a year.
• In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes three-to-five sprints. Create a release plan at the beginning of each release.
• In Stage 4, the product owner, the master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration.
• In Stage 5, during each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have.
• In Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product created during the sprint to the product stakeholders.
• In Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint.

Agile Project Management Roles
It takes a cooperative team of employees to complete a project. Agile project teams are made up of many people and include the following five roles:
• Development team: The group of people who do the work of creating a product. Programmers, testers, designers, writers, and anyone else who has a hands-on role in product development is a member of the development team.
• Product owner: The person responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer's needs and priorities. The product owner works with the development team daily to help clarify requirements. The product owner is sometimes called a customer representative.
• Scrum master: The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator.
• Stakeholders: Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project's outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies.
• Agile mentor: Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level.

[SunnyInHades]

From Agile Project Management For Dummies Cheat Sheet - For Dummies (part 2)

Agile Project Management Artifacts
Project progress needs to be measurable. Agile project teams often use six main artifacts, or deliverables, to develop products and track progress, as listed here:
• Product vision statement: An elevator pitch, or a quick summary, to communicate how your product supports the company's or organization's strategies. The vision statement must articulate the goals for the product.
• Product backlog: The full list of what is in the scope for your project, ordered by priority. Once you have your first requirement, you have a product backlog.
• Product roadmap: The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements.
• Release plan: A high-level timetable for the release of working software.
• Sprint backlog: The goal, user stories, and tasks associated with the current sprint.
• Increment: The working product functionality at the end of each sprint.

Agile Project Management Events
Most projects have stages. Agile projects include seven events for product development. These events are meetings and stages and are described in the following list:
• Project planning: The initial planning for your project. Project planning includes creating a product vision statement and a product roadmap, and can take place in as little time as one day.
• Release planning: Planning the next set of product features to release and identifying an imminent product launch date around which the team can mobilize. On agile projects, you plan one release at a time.
• Sprint: A short cycle of development, in which the team creates potentially shippable product functionality. Sprints, sometimes called iterations,typically last between one and four weeks. Sprints can last as little as one day, but should not be longer than four weeks. Sprints should remain the same length throughout the entire projects.
• Sprint planning: A meeting at the beginning of each sprint where the scrum team commits to a sprint goal. They also identify the requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each requirement.
• Daily scrum: A 15-minute meeting held each day in a sprint, where development team members state what they completed the day before, what they will complete on the current day, and whether they have any roadblocks.
• Sprint review: A meeting at the end of each sprint, introduced by the product owner, where the development team demonstrates the working product functionality it completed during the sprint.
• Sprint retrospective: A meeting at the end of each sprint where the scrum team discusses what went well, what could change, and how to make any changes.


Agile Project Management Organizations, Certifications, and Resources
There is a big agile project management world out there. Here are a few of the useful links to members of the agile practitioner community:
• Agile Alliance: The Agile Alliance is the original global agile community, with a mission to help advance agile principles and practices, regardless of methodology.
• Scrum Alliance: The Scrum Alliance is a nonprofit professional membership organization that promotes understanding and usage of scrum. The Scrum Alliance offers a number of professional certifications:
• Certified Scrum Master (CSM)
• Certified Scrum Product Owner (CSPO)
• Certified Scrum Developer (CSD)
• Certified Scrum Professional (CSP)
• Certified Scrum Coach (CSC)
• Certified Scrum Trainer (CST)
• XProgramming.com: Ron Jeffries, one of the originators of the extreme programming (XP) development approach, provides resources and services in support of XP's advancement on the XProgramming.com site.
• Lean Essays: Lean Essays is a blog from Mary and Tom Poppendieck, thought leaders in the use of lean concepts within the software development space.
• PMI Agile Community: The Project Management Institute (PMI) is the largest nonprofit project management membership association in the world. The agile section of PMI's website provides access to papers, books, and seminars about agile project management. PMI supports an agile community of practice and a certification, the PMI Agile Certified Practitioner (PMI-ACP).

[FatLazyContractor]

[SpontaneousOrder]

as a result of not knowing the minutiae of Agile - in particular who exactly should be involved, the distinctions between different types of stakeholders and the role of the business therein.

If that's the actual question they asked you, then they don't know what they're talking baout either.

'agile' is an adjective, and the manifesto for agile software development - and the real 'Agile' community around that - says nothing about any of those things you mentioned.

[SpontaneousOrder]

'ere you go, everything yo'll ever need .. the cheat sheet from Agile Project Management For Dummies (genuine) ..

From Agile Project Management For Dummies Cheat Sheet - For Dummies (part 1)

Agile Project Management For Dummies
From Agile Project Management For Dummies by Mark C. Layton
Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management methodologies include scrum, extreme programming (XP), and lean, among others. These methodologies all adhere to the Agile Manifesto and the 12 Agile Principles, which focus on people, communications, the product, and flexibility.

A Manifesto for Agile Software Developers
The Agile Software Development Manifesto© is an intentionally streamlined expression of the core values of agile project management. Use this manifesto as a guide to implement agile methodologies in your projects.
"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."
©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.
This declaration may be freely copied in any form, but only in its entirety through this notice.

The 12 Agile Principles
The 12 Agile Principles are a set of guiding concepts that support project teams in implementing agile projects. Use these concepts to implement agile methodologies in your projects.
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.
The Agile Roadmap to Value
The Roadmap to Value is a high-level view of an agile project. The stages of the Roadmap to Value are described in the list following the diagram:



• In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is, how it will support your company or organization’s strategy, and who will use the product. On longer projects, revisit the product vision at least once a year.
• In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revise the product roadmap at least twice a year.
• In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes three-to-five sprints. Create a release plan at the beginning of each release.
• In Stage 4, the product owner, the master, and the development team plan sprints, also called iterations, and start creating the product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines what requirements will be in the upcoming iteration.
• In Stage 5, during each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15 minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have.
• In Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product created during the sprint to the product stakeholders.
• In Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint.

Agile Project Management Roles
It takes a cooperative team of employees to complete a project. Agile project teams are made up of many people and include the following five roles:
• Development team: The group of people who do the work of creating a product. Programmers, testers, designers, writers, and anyone else who has a hands-on role in product development is a member of the development team.
• Product owner: The person responsible for bridging the gap between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer's needs and priorities. The product owner works with the development team daily to help clarify requirements. The product owner is sometimes called a customer representative.
• Scrum master: The person responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent. A scrum master is sometimes called a project facilitator.
• Stakeholders: Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they provide input and are affected by the project's outcome. The group of stakeholders is diverse and can include people from different departments, or even different companies.
• Agile mentor: Someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level.

Everything from the diagram downwards is Scrum - not anything you might call 'Agile'. I.e. to call it 'the agile roadmap' is bulltulip.

[Project Monkey]

Everything from the diagram downwards is Scrum - not anything you might call 'Agile'. I.e. to call it 'the agile roadmap' is bulltulip.

I stuck this whole lot into google translate and all it came back with was: "iterative development"

[patrickbaitsman]

Thanks OP good read.

Could you recommend which Agile certificate would be ideal for a mid-level BA?

Also I was looking into the BCS certificate for it Agile | Agile | Certifications | BCS Certifications - does this certificate hold any weight?